Сущность Гибкой Разработки: Что меняется при применении Agile?
| June 16, 2007 | Posted by Denis under Методологии, Статьи |
Перевод главы из книги Dean Leffingwell “Scaling Software Agility. Best practices for Large Enterprises”. Глава написана с участием Райана Мартенса (Ryan Martens).
Мы прошлись по основным гибким методологиям, а также тем итеративным и инкрементальным, которые могут использоваться в сравнительно «гибкой» манере. По мере того, как мы будем анализировать их, мы найдем много общих черт, которые сформируют основу для частей II и III книги.
И все же, сравнивая гибкие методологии с традиционными водопадными, мы найдем гораздо больше различий, чем общих черт. Не будет большим преувеличением сказать, что когда речь заходит о разработке или управлении проектами разработки, гибкие методологии меняют все (рис. 7-1).
Изменение парадигмы является и сильной и слабой стороной Agile –иметь дело с такими серьезными изменениями для организации не так уж просто. И все же, организации команда за командой трансформируются, и позволяет им получить преимущество от использования гибких методологий. Давайте рассмотрим все изменения, чтобы выяснить, что именно меняет Agile.
Рис.7.1. Изменение парадигмы в Agile
Новые критерии успеха
Критерии успеха в Agile другие. Команды и организации изменяются от «соответсвия плану» к «способности реагировать на изменения».
Превращение означает и переход от парадигмы задач и управления с использованием традиционной структурной декомпозиции работ (work breakdown structure) к парадигме «ценности для заказчика» и использованию историй (stories) и их приоритетов в качестве требований. Теперь мерилом успеха вместо процедурных и документационных «ворот» (stage gates) становится работающий, протестированный продукт, пригодный к демонстрации заказчику. «План» становится гибким и изменяемым, «факт» – это лучшее, что можно получить с учетом имеющихся ресурсов и времени. Более того, факт потенциально можно поставить заказчику.
Различие в культурах управления
Обычно менеджмент фиксирует объем работ (scope), даты, ресурсы и дает технические указания команде. Менеджмент также отвечает за продуктивность команд. В Agile картина меняется. Менеджмент устанавливает лишь направления, команда дает обязателсьтва по выполнению и придумывает, как выполнить как можно больше работы в указанный период. Для достижения своих целей команда самоорганизовывается. Команда принимает технические решения и меняет их по ходу проекта по мере необходимости.
Задача менеджмента состоит в том, чтобы устранять препятствия с пути команды и доверять команде. Это доверие поддерживается благодаря тому, что менеджмент ежедневно видит прогресс команды, а также тому, что в Agile всегда есть готовый интегрированный код. В свою очередь, команда полностью отвечает за поставку кода, его качество и сроки. Самоорганизация команды и ее ответственность – две стороны одной и той же монеты.
Различные подходы к сбору требований, архитектуре и дизайну
Наши представления о сборе требований, архитектуре и дизайне также меняются.
Вместо того чтобы тратить месяцы и месяцы на построение детализированных требований, архитектурных моделей и даже прототипов, команда фокусируется на предоставлении заказчику результата по историям, который имеет реальное значение для его бизнеса. Ранняя поставка заказчику снижает риски, позволяя своевременно проверить требования и архитектурные решения, подтвердить/опровергнуть допущения об интеграции компонентов и функциональности. Если что-то вдруг ломается, команда занимается рефакторингом кода до тех пор, пока код не заработает, что способствует постоянной обратной связи с пользователями и обеспечивает полную видимость происходящего.
Менеджмент и пользователи больше не ждут месяцами затаив дыхание, надеясь, что команда делает все правильно. В худшем случае следующая точка проверки всего лишь через неделю или около того. С некоторой долей удачи и предусмотрительности пользователи смогут развернуть или, по крайней мере, оценить результат работы команды даже в начальных итерациях.
Пересмотр практик кодирования
Кодирование тоже меняется. Вместо параллельной работы над всей функциональностью одновременно (с большим взрывом в конце), вся команда концентрируется только на задачах с высоким приоритетом.
Интеграция непрерывна. Тестирование не откладывается, оно проводится до кода (XP или TDD) или параллельно с разработкой кода. Парная работа становится обычной практикой. Общение постоянно. Результатом является только оттестированный, работающий и интегрированный код. Обратная связь постоянна и мгновенна. Все члены команды знают где они сейчас и что им нужно делать сегодня для достижения целей итерации.
Изменения практик тестирования и контроля качества
Тестирование и контроль качества также сильно изменяются.
Влияние на тестирование также значительно. Часто вся организация тестирования и контроля качества преобразуется: некоторые инженеры качества передаются в команды разработки функциональности или формируют отдельные команды. Тестирование теперь не фаза проекта, а постоянная активность. Тестеры больше не тестируют большие блоки неоттестированного кода, вместо этого они тестируют системы, которые уже включают новый код, покрытый юнит-тестами и приемочными тестами. Автоматизация тестирования – это скорее правило, чем исключение. Навыки тестирования растут по мере того, как тестеры участвуют в принятии решений по дизайну и разработке инструментов автоматизации тестирования. Навыки программистов растут – они понимают как писать достаточно простой код, который легко тестировать. Сотрудники QA делают настоящую работу по обеспечению качества, и не занимаются управлением легионами ручных тестеров.
Новые способы планирования
Планирование и установка сроков также меняются.
Слухи об отсутствии в Agile планирования сильно преувеличены. На самом деле, оно становится интенсивнее и проявляется на двух уровнях: высокоуровневое планирование для релизов и низкоуровневое для планов итераций. Планирование не осуществляется один раз в начале проекта, а происходит каждый релиз и каждую итерацию. Планирование больше не является кусочным и спонтанным – оно систематическое и постоянное.
Планирование существенным образом упрощено, так как все даты заранее известны и команды заказчика, управляемые Product Owner, отвечают за определение приоритетов. Отслеживание хода проекта тоже несложно – ежедневные статус-митинги и частые показы демонстрируют прогресс. Теперь нет разделения на план и реальность. Менеджеры больше не беспокоятся по поводу различных связанных событий, таких как отпуска, – это делает команда.
Самое серьезное изменение – объем работ против сроков – сроки выигрывают!
Как мы поняли в DSDM, в битве даты выпуска и объема работ дата побеждает всегда. То есть длина итерации (или длина релиза на более высоком уровне) определяет объем, а не объем определяет длину цикла разработки. В традиционных методах объем определяет сроки и две переменные (объем и сроки) меняются с каждым новым циклом планирования и с каждым значительными изменением. В гибких методологиях сроки всегда фиксируются и остается только одна переменная – объем работ. Это позволяет команде организовать свою работу фокусируясь на том, что может быть закончено к указанной дате. Объем работ всегда приоритезирован, члены команды всегда уверены в том, что они предоставят лучшее решение в имеющееся ограниченное время. Эту концепцию демонстрирует пирамида DSDM на рисунке.
Рис. 7.2. Плановые методы и Agile
Если, по каким-то причинам, результат не содержит нужной функциональности, ничего страшного не произойдет – ведь следующая итерация всего лишь через неделю, и следующий релиз будет доступен в худшем случае через месяц или два после.
Пульс Agile: таймбоксинг работающего кода
Как много различий между традиционными и гибкими методами работы! Теперь настало время посмотреть, что общего у различных методологий и распознать общие практики для применения в больших масштабах.
Гибкие методологии имеют одну общую важную черту, квинтэссенцию различия методологий – разработка производится путем создания небольших кусков кода в таймбоксе (то есть к заданной фиксированной дате). Этот новый навык разработки является ключевым для Agile-команды и если команда сможет ему научиться, прочие вещи сами встанут на свои места. Рисунок 7-3 иллюстрирует эту простую «модель процесса в модели процесса».
Из бэклога сначала вынимают следующую наиболее важную для заказчика вещь. Каждый элемент затем определяется/разрабатывается/тестируется в быстрых параллельных циклах. Мы используем «глагол» определяется/разрабатывается/тестируется для того, чтобы иллюстрировать атомарность итерации; ни одна часть не может быть сделана без другой.
Рис. 7.3. Пульс Agile: работающий код в таймбоксе
Внутри таймбокса каждый элемент оценивается и после того как он проходит тестирование из бэклога достается следующая история. Если он не работает, то исправляется сразу же, до тех пор, пока не пройдет все тесты. Разумеется, для выполнения необходимо, чтобы команде были предоставлены все ресурсы для определения/разработки/тестирования.
1. Работа в таймбоксе
В дисциплинированном Agile-процессе таймбоксинг используется везде.
Механизмом для управления изменяемостью требований является таймбокс
DSDM
Таймбоксинг устанавливает ритм для организации, который подобно барабанному бою синхронизирует работу всех участников. Он повторяем, предсказуем и надежен и все производство вращается вокруг этого цикла. Наиболее ценное преимущество состоит в том, что таймбоксинг предполагает близкий майлстоун который заставляет и команду и код объединятся и поставлять рабочий продукт регулярно.
Leffingwell and Muirhead
Таймбоксинг итераций. Итерации могут быть длиной в одну неделю или, что более типично, две недели, но редко дольше.
Таймбоксинг релизов. Даты релизов заранее известны, и объем работ, а не качество, ресурсы или сроки изменятся для выполнения обязательств.
Таймбоксинг митингов. Планирование релизов и итераций, рестроспективы, демонстрации и ежедневные скрамы – все эти митинги таймбоксятся. Это дисциплинирует всех участников и дает понять каждому, что время имеет значение. Такая дисциплина помогает каждому члену команды выполнять взятые обязательства – ведь заранее известно, сколько времени уходит на все «накладные» затраты.
Когда мы начали работать по Agile, я опасался, что это может оказаться менее дисциплинированным подходом к разработке. В действительности оказалось, что Agile более дисциплинирован и обеспечивает больше ответственности.
2. Разрабатывать малыми кусочками
Фича (история) должна быть достаточно мала, чтобы ее можно было сделать за несколько дней
Я предпочитаю разбивать истории на задачи, которые может оценить и взять на себя человек. Мне кажется, что собственность на задачи восходит к человеческой необходимости в собственности.
Agile вообще и XP в частности доводит инкрементальность до экстремальной. Работа разделяется на истории и задачи. Истории представляют собой «мягкие» требования (или, по крайней мере, обозначают необходимость их обсуждения), задачи определяют конкретную работу, которую команде необходимо сделать, чтобы выполнить историю. Гранулярность историй обычно не более чем несколько дней на каждую. Длительность задач обычно менее одного дня. Если применяются сценарии использования (use cases), то они должны быть настолько гранулярными, чтобы их можно было сделать за один раз. Можно выделить какую-нибудь логическую и связанную часть сценария, которая может быть сделана за одну итерацию. Есть несколько причин работать таким образом, и каждая представляет собой ключевой элемент методологии.
Небольшие задачи могут быть оценены и отслежены. Размер задачи оказывает огромное влияние на видимость ее статуса. Если задача крупная и запланирована на итерацию целиком, то вся итерация будет посвящена ее окончанию. Эта работа не может быть закончена до самого конца итерации. В этом случае измерение прогресса – вопрос оценки процента сделанной работы монолитного куска. Тестерам тоже трудно включится в работу заранее если вся работа оказывается законченной только к концу итерации.
Разбив монолитную задачу на небольшие части мы сможем оценивать статус каждой части отдельно и нам не придется ждать конца итерации, чтобы увидеть окончание работы. На протяжении всей итерации небольшие части работ меняют свой статус с “planned” через “in progress” в “complete”.
Такое разделение дает нам средства для отслеживания прогресса итерации. Мы понимаем, что происходит с каждым из таких кусков работ: блокирован, готов к тестированию, завершен раньше срока или с ним никто вообще работать не будет. Мы можем передавать небольшие части работ на тестирование внутри итерации.
Маленькие куски облегчают собственность и ответственность. В конце концов, если часть работы может быть сделана менее чем за неделю, команда может быть весьма уверена, кто из членов команды будет определять/разрабатывать/тестировать ее!
Маленькие куски работ разделяют большую работу на куски, которые реально завершить. На больших системах все вершит сложность. Вообразите насколько тяжело управлять 300 разработчиками системы, похожей на которую на рынке еще не было. В традиционной разработке задача может оказаться непосильной и никакое планирование не способно конкретизировать все детали. К тому же для большой задачи удовлетворение от ее результатов можно получить только в самом конце. И, как мы видели при анализе того, что не работает, даже окончание работ может оказаться не такой уж приятной вещью. В этом случае удовлетворение от работы вообще выпадает из уравнения!
В Agile прогресс и удовлетворение от работы являются постоянными, частыми и происходят в реальном времени. Показ ваших успехов заказчику, коллеге или заинтересованным лицам произойдет в крайнем случае через неделю или около того.
Маленькие куски работ вскрывают риски раньше. Для Agile команды вполне типично сделать 25 – 30 процентов работ из запланированного ими плана на первую итерацию. Причины могут быть разными, как мы увидим в следующих главах. Причины провала могут быть разными (команда ли была не способна хорошо оценивать или может быть какие-то истории вскрыли непредвиденные заранее технические сложности), результаты первой итерации немедленно продемонстрируют риски, какими бы ни были их причины. У менеджмента будет ощутимая картина прогресса сразу после одной или двух недель работы.
-
Ice
