Некоторые могут подумать, что переход к Agile означает упущение из виду общей картины. Мы не могли не согласиться на большее.
Ранними приверженцами Agile разработки были небольшие, автономные команды, работавшие над небольшими, автономными проектами. Они доказали, что Agile модель может работать, к радости и совершенствованию производителей программного обеспечения по всему миру. В последнее время крупные организации расширяют Agile за пределы отдельных команд или проектов и ищут способы применить их ко всем программам.
Это не без его вызовов. Но это не значит, что это невозможно сделать!
Водопад (waterfall) против Agile
Давайте начнем с основ - как то, что делает Agile другим.
Традиционные стили управления проектами, такие как водопад, строятся поэтапно.
Ниже приведена иллюстрация стандартного проекта водопада (waterfall). Этот стиль разработки продукта объединяет все в один, «большой взрыв», релиз высокого риска. Как только проект проходит одну фазу, болезненно возвращаться к нему, потому что команды всегда стремятся к следующему этапу.
Традиционные стили управления проектами часто создают «критические пути», когда проект не может двигаться вперед, пока не будет решена проблема блокировки. Чтобы добавить оскорбление ранее, конечный клиент не может взаимодействовать с продуктом, пока он не будет полностью завершен. Таким образом, важные вопросы в дизайне и коде продукта остаются не обнаруженными до релиза.
Давайте сопоставим это с Agile стилем управления проектами, который использует итеративный подход к разработке с регулярными интервалами обратной связи. Эти итерации позволяют перенаправить команду (и продуктивнее) в другую область проекта, пока решается проблема блокировки.
Помимо удаления критических путей, итерации позволяют вам взаимодействовать с продуктом во время разработки.
Это, в свою очередь, дает команде постоянные возможности для создания, доставки, обучения и адаптации. Изменения на рынке не застигнут вас врасплох, и команды смогут быстро адаптироваться к новым требованиям.
Еще большее преимущество - это совместное использование навыков командой разработчиков. Перекрывающиеся наборы навыков команды добавляют гибкости работе во всех частях кодовой базы команды. Таким образом, работа и время не будут потеряны, если направление проекта изменится. (Подробнее об этом см. нашу статью о создании отличных Agile команд.)
Как построить отличную Agile программу
Когда программа переходит от традиционного управления проектами к Agile , команда и заинтересованные стороны должны принять две важные концепции:
- Цель владельца продукта - оптимизировать ценность результатов команды разработчиков. Команда разработчиков полагается на владельца продукта, который определяет приоритетность наиболее важной работы.
- Команда разработчиков может принимать работу только потому, что у нее есть для этого возможности. Владелец продукта не продвигает работу в команду и не назначает ее в произвольные сроки. Команда разработчиков извлекает работу из списка необходимых требований продукта (backlog) программы, поскольку она может принять новую работу.
Давайте рассмотрим механизмы, которые Agile программы используют для организации, запуска и структурирования работы итеративным способом.
Дорожные карты
Дорожная карта описывает, как продукт или решение развивается с течением времени. Дорожные карты состоят из инициатив, которые представляют собой большие области функциональности и включают в себя временные рамки, которые сообщают, когда функция будет доступна. По мере развития программы принято, что дорожная карта будет меняться - иногда незаметно, иногда широко. Цель состоит в том, чтобы сфокусировать дорожную карту на текущих рыночных условиях и долгосрочных целях.
Требования
Каждая инициатива в дорожной карте разбивается на набор требований. Agile требования - это упрощенные описания требуемой функциональности, а не 100-страничные документы, связанные с традиционными проектами. Они развиваются с течением времени и используют общее понимание команды клиента и желаемого продукта. Agile требования остаются незыблемыми, в то время как все в команде развивают общее понимание посредством непрерывного общения и сотрудничества. Только когда начнется реализация, они будут подробно изложены.
Список необходимых требований (backlog)
Список необходимых требований (backlog) устанавливает приоритеты для Agile программы. Группа включает в список необходимых требований (backlog) все рабочие элементы: новые функции, баги, усовершенствования, технические или архитектурные задачи и т. д. Владелец продукта определяет приоритет работы по списку необходимых требований (backlog) для команды разработчиков. Затем команда разработчиков использует приоритетный список необходимых требований (backlog) в качестве единственного источника правды для той работы, которую нужно сделать.
Agile средства предоставления
Agile может быть реализован с использованием различных структур (таких как scrum и kanban) для предоставления программного обеспечения. Команды Scrum используют спринты для руководства разработкой, а команды kanban часто работают без фиксированных рабочих интервалов. Оба фреймворка, однако, используют крупные средства предоставления, такие как эпики и версии, чтобы структурировать разработку для синхронизации ритма выпуска релиза в производство.
Agile метрики
Agile команды процветают на метриках. Лимиты работы в процессе (WIP) позволяют команде и бизнесу сосредоточиться на выполнении работы с наивысшим приоритетом. Графики, такие как показатели выгорания и контрольные диаграммы, помогают команде прогнозировать частоту их предоставления, а непрерывные блок-схемы помогают выявлять узкие места. Эти метрики и артефакты позволяют каждому сосредоточиться на больших целях и повышают уверенность в способности команды выполнять будущую работу.
Agile работает на доверии
Agile программа не может функционировать без высокого уровня доверия среди членов команды. Требуется искренность, чтобы иметь трудные разговоры о том, что подходит для программы и продукта. Поскольку разговоры происходят через равные промежутки времени, идеи и проблемы регулярно выражаются. Это означает, что члены команды также должны быть уверены в способности (и готовности) друг друга выполнять решения, принятые в ходе этих бесед. Таким образом, Agile разработка - это структурированный и итеративный подход к созданию программного обеспечения. Это дает вам возможность реагировать на изменения, не сходя с рельсов. И это хорошая новость для любой программы.
По материалам Agile Coach "Program"