В предыдущих статьях мы рассказали о возможных подходах к проектированию жизненного цикла ПО: Waterfall, Scrum и Kanban. У каждого из них есть свои особенности, которые стоит учитывать, выбирая ту или иную методологию для управления вашим проектом. Однако, в реальных проектах для достижения наилучшего результата различные методологии могут использоваться совместно. Для того, чтобы понять, каким образом можно совместить разные подходы, давайте обратим внимание на их отличительные черты, а затем рассмотрим, как эти подходы применялись при работе над реальным проектом.
Основные особенности Waterfall
Начнем с краткого обзора особенностей Waterfall. Эта модель разработки ПО стоит особняком от двух других, рассматриваемых в этой статье. В отличие от Scrum и Kanban, Waterfall не является итеративной моделью. На практике это означает, что каждый этап проекта выполняется только единожды. Проект реализуется пошагово в соответствии с заранее определенной последовательностью действий. Вот типичная последовательность фаз разработки, характерная для каскадной модели:
1. Анализ требований
2. Проектирование
3. Разработка
4. Тестирование и отладка
5. Инсталляция
6. Поддержка
В реальных проектах эти фазы могут отличаться от приведенного выше списка, но в целом они должны соответствовать этим ключевым этапам.
Каскадной модели присущи свои недостатки. Так, например, если на одном из ранних этапов будет допущена ошибка, вероятнее всего, обнаружить ее удастся только на этапе разработки или тестирования. Таким образом, рекомендуется применять данную модель только в том случае, если все требования, предъявляемые к конечному продукту точно установлены с самого начала работы и не изменяются во время разработки.
Scrum и Kanban. Основные различия
В отличие от Waterfall, методологии Scrum и Kanban имеют много общего:
- обе следуют принципам Бережливой (Lean) и Гибкой (Agile) разработки
- обе используют вытягивающие (pull) системы планирования
- при использовании как Scrum, так и Kanban центральное место занимает минимизация используемой документации и нацеленность на коммуникацию внутри команды и непрерывное обсуждение текущего проекта. Как следствие этого — важная роль визуализации процесса разработки посредством доски с учетными карточками, каждая из которых соответствует определенной задаче
- оба подхода стремятся к ограничению работы, выполняющейся в текущий момент
- и Scrum, и Kanban ориентированы на как можно более частый релиз готового продукта
Для того, чтобы лучше разобраться в особенностях этих подходов, давайте обратим внимание на существующие между ними различия.
Подход к ограничению количества выполняемых задач
Важным для обеих методологий является практика ограничения задач, которые выполняются в текущий момент (Work In Progress, или WIP). Однако, критерии, согласно которым выбирается количество таких задач для каждой методологии разные.
Вот пример того, как может быть визуализирован процесс разработки ПО:
Каждой фазе разработки соответствует определенное количество выполняемых в данный момент задач.
Согласно методологии Kanban для каждого этапа разработки еще на стадии проектирования выбирается максимальное число задач, которые могут выполняться одновременно. Четкого руководства по выбору того или иного числа задач для определенного этапа нет и оптимальное значение чаще всего определяется по завершении нескольких итераций.
Scrum, в свою очередь, не ограничивает вас количеством задач, которые могут выполняться на определенном этапе. Можно говорить только об определенном количестве задач, запланированном для спринта в целом. Это количество выбирается исходя из времени, которое предположительно будет затрачено на выполнение той или иной задачи. Это время измеряется в story point’ах. По завершении нескольких итераций команда разработчиков знает свою среднюю производительность и ей, соответственно, может быть назначено определенное количество задач.
Различные подходы к организации Scrum и Kanban досок
На начальных этапах работы над проектом создается бэклог проекта, который представляет из себя список требований, предъявляемых к конечному продукту. В случае обоих подходов на этапе визуализации рабочего процесса задачи из бэклога продукта помещаются на доску. А вот их перемещение между этапами проекта отличается для разных методик.
В случае Scrum каждая итерация называется спринтом. На основе бэклога продукта в начале каждого спринта создается бэклог спринта — список задач, которые необходимо реализовать за время работы над текущим спринтом. Таким образом, все задачи, располагающиеся на той или иной стадии проекта являются частью бэклога спринта. Владелец продукта может наблюдать за бэклогом спринта, но вмешиваться в очередность задач, из которого он состоит, нельзя. Можно вносить изменения только в бэклог продукта, но они вступят в силу только после начала очередного спринта. Результатом работы над каждым спринтом является готовый продукт. После ретроспективы и демонстрации его функциональности владелец проекта принимает решение о том, стоит выпускать продукт или нет. Эти решающие стадии каждого спринта обычно не входят в бэклог и никак не отображаются на доске.
В случае же с Kanban доской дело обстоит несколько иначе. Srum доска очищается от карточек по завершении каждого стрима. На Kanban доске отображается весь процесс разработки целиком, а не только задачи одной команды, запланированные на одну итерацию. Таким образом, Kanban доска остается неизменной. Также стоит отметить, что на Kanban доске обычно отображаются финальные фазы разработки, например, установка готового продукта.
Использование разных подходов на примере одного проекта
Проект: Онлайн-приложение для хранения данных
Разработанный проект представляет собой веб-систему, предоставляющую мгновенный доступ к обширному источнику информации и статистических данных по развитым и развивающимся рынкам мира. Система предназначена для аналитиков, консультантов, научных учреждений, корпораций, экономистов, руководителей организаций, инвестиционных банков, и всех тех, кому необходимо оперативно проводить исследования и выполнять анализ данных. Главной задачей при работе над проектом было обеспечение возможности обработки около 15 миллионов записей, поступающих в разное время из различных стран. Система должна была давать доступ к данным 500 000 пользователей одновременно.
Итак, давайте рассмотрим как могут применяться различные подходы к процессу разработки на различных этапах работы.
В реальных условиях при работе над большими проектами сложно придерживаться одной методологии на протяжении всего периода разработки. Исключение составляют, пожалуй, только те редкие случаи, когда заказчик является приверженцем какой-то определенной методологии и одним из его требований является строгое следование всем ее принципам.
В остальных же случаях имеет место совмещение разных подходов.
Использование Scrum. Разработчики придерживаются методологии Scrum большую часть так называемого «спокойного» времени: времени без релизов и презентаций.
Пример спринта в Jira
Как только процесс разработки приближается к моменту презентации или релиза, разработчики плавно переходят к использованию Kanban. На практике это выглядит примерно так. У команды есть ориентир — дата релиза или презентации. Начиная с определенного момента команда начинает реализовывать задачи, которые заказчик приоритезирует и высылает ей в виде списка ежедневно.
Waterfall применяется в тех случаях, когда требуется реализовать какой-то важный, достаточно большой и достаточно обособленный от общего проекта функционал. Например, этот подход использовался при разработке Excel add-in для приложения. Критичными в данном случае являются четко сформулированные требования. В этом случае команда разработчиков собирает все требования, документирует их и приступает в разработке.
Заключение
Для успешного управления процессом разработки программного обеспечения бывает недостаточно выбрать ту или иную методологию и следовать ей на протяжении всего процесса. В случае достаточно большого проекта, разработка которого ведется достаточно долгий период времени, важной может оказаться способность быстро менять используемую в данный момент методологию в соответствии с изменяющимися обстоятельствами. Именно поэтому, помимо четкого и ясного понимания каждой из особенностей той или иной методологии, важное значение принимает также понимание различий между теми или иными подходами и умение быстро переключаться между ними. В случае определенных проблем, появившихся вследствие непредвиденных обстоятельств, такие навыки дают дополнительную возможность их быстрого решения. Вместо того, чтобы искать возможные слабые места в применяемой в данный момент методологии производства и пытаться их устранить, можно просто выбрать другой, более подходящий к изменившимся условиям подход.
