Современный подход к разработке программного обеспечения

Современные подходы к разработке программного обеспечения требуют все большей гибкости в вопросах принятия решений. Во многом это обусловлено высокой динамикой рынка, диктующего свои условия практически всем игрокам. Чтобы избежать типичных методологических ошибок, специалисты предложили концепцию Agile (англ. “ловкий”) - идею гибкого подхода к разработке.

Что такое Agile? Это наука о том, как сразу сделать годный продукт, минуя промежуточные стадии (исправления ошибок, клиентского тестирования и так далее). Это попытка срезать углы на поворотах - те, которые вообще можно срезать. Такой результат достигается в первую очередь за счет активной коммуникации с заказчиком: регулярный обмен сведениями позволяет корректировать процесс разработки ПО в нужную сторону по ходу движения проекта.

Манифест Agile содержит ряд основных принципов гибкого подхода:

  1.  люди и взаимодействия важнее процессов и инструментов

  2.  работающий код важнее идеальной документации

  3.  сотрудничество с заказчиком важнее контрактных обязательств

  4.  реакция на изменения важнее следования плану

При этом пункт 3, например, не означает, что кто-то должен ущемлять себя в правах: речь о том, что правильно составленный контракт должен обеспечить эффективное сотрудничество, а не препятствовать ему. Таким образом, каждый принцип нацелен на повышение продуктивности и своевременную корректировку курса разработки. 

Какие гибкие подходы существуют на данный момент?

Итеративный подход предполагает разбиение всего цикла разработки на короткие итерации по 2-3 недели. По итогам периода проводятся встречи с обсуждением результатов и согласованием бэклога (списка функций, которые должны войти в релиз). 

Инкрементальный подразумевает как можно более раннее “выкатывание” программы в релиз, даже с минимальным количеством приоритетных фич. Постепенно можно пополнять ПО, добавляя в нее новые функции в новых релизах. Не факт, что проект будет завершен, но за счет раннего релиза он может достигнуть промежуточных бизнес-целей.

Scrum

Сам по себе Agile - это всего лишь набор правильно расставленных приоритетов и не диктует ролей в команде, не навязывает способы решения задач. Для этого есть так называемый фреймворк - готовая система взаимодействий разработчиков между собой. Самый популярный фреймворк на ИТ-рынке - Scrum (англ. “схватка, толкотня”).

Что такое Scrum? Это попытка научить айтишников дисциплине. Кроме того, что он описывает роли в команде, scrum также учит людей на регулярной основе общаться друг с другом. Ежедневные стендапы, регулярные ретроспективы и демонстрации - все это призвано не только научить людей говорить о своих проблемах, но и заставить их делиться информацией, которая может оказаться важной для других членов команды. Это наука о том, как работать в команде так, чтобы эффективность разработки не только не падала, но и постоянно росла.

Роли

В Scrum есть три основные роли: product owner (владелец продукта), команда и scrum-мастер. 

Продакт оунер является основным звеном между клиентом и командой. Он располагает всей информацией, понимает нужды заказчика, порождает основную концепцию продукта и выдает бэклог - список фич, которые должны войти в конечный продукт. 

Команда рассматривает этот список, обсуждает его и принимает решения о приоритетных задачах и способах их выполнения, оценивает сложность фич и сроки их реализации. Все решения по дизайну и имплементации принимает именно команда, а не продакт оунер.

Scrum-мастер же фокусируется не на продукте, а на самой команде. Он занимается поддержанием эффективной слаженной работы, обеспечивает поддержание доверия членов группы друг другу, устраняет внешние препятствия (например, бюрократические). В функции мастера входит, например, проведение ежедневного утреннего стендапа. В ходе этого митинга члены команды отчитываются об успехах, делятся планами и докладывают о проблемах. Любое предметное обсуждение проблем, выходящее за рамки 15 минут, scrum-мастер обязан вынести за пределы стендапа.

Нужно понимать, что изначально, пока команда еще не является цельной, работоспособной единицей, роль скрам-мастера в урегулировании рабочих конфликтов может быть довольно высока. Но довольно быстро коллеги обучаются работать по scrum и роль мастера снижается. После “притирки” (как правило, процесс занимает 3-4 итерации) эффективность команды возрастает в разы.

Взаимозаменяемость и T-образные люди

Зачастую в рамках беседы о Scrum говорят о взаимозаменяемости членов команды. Здесь нужно подчеркнуть, что в таких случаях не имеется в виду полная взаимозаменяемость (а-ля “все умеют всё”). Речь о так называемых T-shaped people: людях, которые знают немного всего, “по верхам” (как верхняя перекладина T), но в какой-то одной области обладают специальным, углубленным знанием (вертикальная черта в Т). Если команда подобрана без совпадения “специальностей”, но она покрывает очень широкий информационный пласт и способна реализовать практически любой проект.

Одной из важных предпосылок scrum является то, что любая команда способна самоорганизовываться. Люди начинают понимать сильные стороны друг друга и доверяют коллегам в определенных областях. Таким образом, они могут в нужный момент беспрекословно передать лидерство тому, чей опыт наиболее уместен. Под грамотным руководством даже не очень опытные в вопросе сотрудники могут быть крайне эффективны. 

Инструменты

Теперь я немного расскажу о инструментах, которые применяются в Scrum для координации производственного процесса: task board и burndown chart. Доска задач чаще всего представляет из себя физическую доску с разноцветными стикерами, ранжированными по приоритету - сверху вниз. Она разделена на три секции: to do, in progress, done. Когда член команды берет на себя задачу, он переносит соответствующий стикер из колонки “to do” в графу “in progress” и подписывает на нем свое имя. Таким образом, в любой момент времени любой член команды может видеть, кто занимается задачей. 

Task board может быть также реализована и в виде электронной системы тикетов, если так удобнее команде. Однако прозрачность такой системы будет ниже, так как для доступа к ней нужно предпринять определенные действия - например, открыть сайт и ввести пароль/логин.

Что же касается burndown chart (он же график “сгорания” работ) - это инструмент отслеживания прогресса по проекту. Он может быть привязан к конкретной итерации (краткосрочный), так и к общим срокам проекта (долгосрочный). Каждый день на протяжении итерации вы ставите одну точку в зависимости от количества оставшихся до конца периода задач. Измерять прогресс можно как в человеко-днях, так и условных единицах (1=простая пользовательская история, 2=средняя и т.д.). Таким образом, вы сможете более-менее точно спрогнозировать, какое количество фич вы не успеете внедрить до конца итерации и перенести их на следующий период.

Всегда есть соблазн продлить итерацию еще на один-два дня… В результате велик риск получить итерацию длиной в месяц, которая все равно не будет заканчиваться полным успехом. Важно своевременно завершить итерацию, а недоделанное перенести на будущий период. Подведите итоги и спросите команду, сделайте соответствующие выводы. Возможно, это проблема планирования? Учтите негативный опыт и ставьте реалистичные цели.

Оценка сроков проекта

Сроки проекта - бич всякого разработчика, потому что предсказать их объективно практически невозможно. Редкий проект завершается в сроки, названные заказчику в начале работы. Человеку свойственен оптимизм, и когда вы думаете о проекте, вы часто предполагаете, что всё будет идти ровно и без проблем. Но по факту проблемы возникают. Там чуть-чуть затянули, здесь времени не хватило… и вот - выполнение каждой из 100 задач заняла на 10-20% времени, чем вы ожидали. То есть, вы уже никак не укладываетесь в намеченные сроки. Что же делать, чтобы этого избежать?

Во-первых, уяснить самому, что сроки окончания проекта - это вопрос вероятности. Оптимист назовет один срок, не накидывая ничего сверху, и вероятность попадания в этот срок будет равна 0. Большинство сколь-либо опытных разработчиков назовут другой срок, и смогут в него попасть с вероятностью 20-30%. Но чтобы увеличить свои шансы на попадание в цель, нужно называть адекватные сроки - умножая свою оценку хотя бы на 3. Вероятность успеха при таком раскладе существенно выше, а у разработчиков есть шансы написать качественный код, провести code review и отловить баги. 

Во-вторых, пользуйтесь долгосрочной burndown chart, в которой шаг равен одной итерации, а не одному дню. Некоторые виды этого графика позволяет в том числе регистрировать, как растет бэклог по результатам взаимодействия с заказчиком. Исходя из ретроспективных данных, вы сможете предположить, в какой момент пересекутся линия вашей работы и линия постоянно растущего бэклога. Как правило, там и располагается отметка “конец проекта”.

Definition of Done

Определение готовности (Definition of Done, DoD) - это набор критериев, по которым команда определяет, что задача была завершена успешно. Эти критерии необходимо иметь с самого начала работы, однако они не обязаны оставаться фиксированными. Их можно корректировать на ретроспективах - митингах, посвященных обсуждению работы, проделанной за итерацию. Все должны сойтись во мнении - иначе возникает угроза саботажа.

DoD задается для каждого уровня: требования, задачи, фичи, итерации. Примером успешного прохождения итерации может, например, являться прохождение системой регрессионного тестирования.

© 2018 Kanishev. Все права защищены.