Agile-манифест разработки программного обеспечения
Мы постоянно открываем для себя более совершенные методы разработки
программного обеспечения, занимаясь разработкой непосредственно и помогая
в этом другим. Благодаря проделанной работе мы смогли осознать, что:
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
То есть, не отрицая важности того, что справа,
мы всё-таки больше ценим то, что слева.
| Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler | James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick | Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas |
© 2001, вышеперечисленные авторы
Текст манифеста может свободно копироваться в любой форме,
но только полностью, включая это уведомление.
дизайн сайта и оформление © 2001, Ward Cunningham
Перевод выполнили: Алексей Солцнев, Сергей Мовчан, Сергей Евтушенко,
Андрей Мудрый, Тим Евграшин, Роман Кононов, Лина Шишкина, Антон Марюхненко и Алек Козлов,
при поддерже сообщества Agile Ukraine
Что такое Agile и подойдет ли он вашей компании
Что такое Agile
Agile, или Agile software development — гибкий подход к разработке программного обеспечения (ПО), который часто применяют в небольших командах.
Весь процесс работы над проектом делится на итерации — короткие циклы по две-три недели. Каждая итерация решает серию задач: анализ требований, проектирование, программирование, тестирование и документирование. По итогам каждой итерации команда анализирует результаты и меняет приоритеты для следующего цикла. В итоге за каждый цикл создается мини-продукт или отдельная часть, которая готова к самостоятельному запуску.
Термин Agile употребляют в двух основных значениях:
Как правило, agile-команды включают разработчиков, тестировщиков, менеджеров проектов, дизайнеров интерфейсов, технических (UX) писателей. Все они равноценны в иерархии и работают в одном офисе или коворкинге. За счет личного общения они экономят время на обсуждении текущих процессов. Сторону заказчика представляет менеджер или руководитель — product owner, от которого команда регулярно получает обратную связь.
Agile возник в противовес устаревшим подходам и излишней бюрократии в сфере ИТ. Резиденты Кремниевой долины (и не только) поняли, что невозможно создавать инновационные продукты в консервативной среде. Поэтому в феврале 2001 года в штате Юта (США) 17 разработчиков из разных стран мира создали свой манифест, в котором объединили самые передовые подходы и принципы.
«Манифест Agile» и основные принципы
Agile-манифест базируется на четырех главных ценностях:
1. Люди и их взаимодействие важнее процессов и инструментов.
Нужно создать такие условия, чтобы инструменты и процессы не ограничивали команду, а позволяли ей работать как можно эффективнее. Каждый может сам решать, какие инструменты и процессы ему подходят.
В процессе работы все общаются друг с другом и заказчиком лично и напрямую, минуя бюрократические процедуры и регламенты. Если без онлайн-связи не обойтись, то предпочтение отдают видеочатам и интерактивным доскам, а не рабочей почте и мессенджерам.
2. Работающий продукт важнее документации и отчетности.
Клиенту, в первую очередь, нужен рабочий продукт, а не красивые презентации. Поэтому в рамках Agile фокусируются на том, чтобы продукт как можно быстрее был готов к использованию, пренебрегая технической документацией и отчетностью.
3. Сотрудничество с заказчиком важнее соблюдения формальных условий.
Даже если перед проектом подписан договор с жесткими условиями и характеристиками, в процессе работы они могут меняться. Например, если некоторые детали окажутся не такими значимыми, и задачу можно решить гораздо проще и эффективнее. Это делается в интересах клиента, которому важен рабочий продукт, а не формальные требования. При этом важно постоянно быть на связи и обсуждать каждое изменение, принимая решение совместно.
4. Готовность к изменениям важнее, чем следование плану.
Изменения можно и нужно вносить на каждой стадии — или итерации, — чтобы не откладывать их на конец, когда сроки и ресурсы уже поджимают. Ради этого вполне можно пожертвовать чем-то из запланированного, если основные задачи будут решены.
Agile не исчерпывается четырьмя ценностями [1]. В манифесте есть также 12 принципов, которые уточняют и дополняют их. Их можно свести к следующему:
Agile, таким образом, — это система ценностей или даже философия ведения бизнеса. Она помогает сосредоточиться на главном, избавиться от ненужных формальностей и создавать рабочий продукт быстрее и эффективнее. Чтобы воплотить эти ценности на практике, используют конкретные методы. Согласно исследованию Agile в России [2], самые популярные из них — Scrum и Kanban.
Что такое Scrum и Kanban
Scrum, или «подход структуры» — метод на основе Agile, при котором работа над проектами разбивается на спринты — короткие, одинаковые по времени итерации. Команда тоже небольшая — до десяти человек. В нее входят разработчики, product owner (владелец продукта) и scrum-мастер. Product owner — куратор группы, который следит за тем, чтобы конечный продукт отвечал его целям и задачам. Scrum-мастер — человек, который отвечает за правильное применение scrum-метода: организует встречи и обмен сообщениями между всеми участниками. В процессе работы все участники ежедневно обсуждают каждое решение, планы и приоритеты, а также распределяют задачи.
Kanban, или «подход баланса» — метод, который нацелен на повышение качества сервиса: когда все усилия направлены на то, чтобы сделать продукт лучше и удобнее для пользователей, с помощью равномерного распределения задач между всеми участниками. Здесь команда представляет собой единой целое, без кураторов и неформальных лидеров. Процесс делится не на спринты, а на стадии проекта: планирование, разработка, тестирование, запуск. Главный показатель эффективности — максимально быстрое завершение каждого из этапов, без простоев и переработок. Если они все же возникают, команда совместно решает, как оптимизировать процесс.
В отличие от scrum, kanban:
В kanban принято визуализировать все детали процесса. Обычно это доска со стикерами, надписями или task-менеджер вроде Trello, где указаны все задачи, этапы и их статус. Часто задачи помечают разными цветами, чтобы обозначить, к какому этапу они относятся или на какой стадии исполнения находятся. Это помогает каждому участнику проекта видеть всю картину целиком, вовремя замечая, если что-то провисает или кому-то нужна помощь.
Пример доски Trello, созданной по принципам agile.
Если вы только подступаетесь к философии Agile и хотите попробовать отдельные элементы, проще начать с kanban. Небольшим стартапам и командам, которые только планируют запуск проекта, подойдет scrum.
В каких компаниях используют Agile
Когда Agile только появился, его использовали, в основном, разработчики ПО, игр и интерфейсов. Среди них — Google, Netflix, Microsoft, Spotify, Ericsson, Dell, Adobe, Accenture, WordPress, Riot Games, CH Robinson, Magna International, Scrum Alliance, Intronis.
Теперь же сфера применения расширилась: Agile используют, например, Saab для производства новых истребителей, General Electric и John Deere — ведущий американский производитель сельхозтехники.
Существует ли Agile в России
В Россию Agile пришел на несколько лет позже, но уже сегодня его активно используют в ИТ-секторе, ретейле, банках, онлайн-сервисах, промышленных предприятиях. Среди них — ПО-разработчик First Line Software, гипермаркет электроники «М.Видео», служба доставки Dostаевский, онлайн-кинотеатр ivi, бренд одежды 12 Storeez, металлургический концерн НМЛК.
ScrumTrek проводит ежегодное исследование Agile в России. В прошлом году в нем приняло участие более 1 тыс. компаний из 80 городов. Вот главные цифры за 2020 год [3]:
Нужен ли вашей команде Agile
Сегодня принципы Agile распространяются во многих сферах, хотя на первом месте по-прежнему остается ИТ-разработка. Однако гибкие подходы применимы далеко не везде. Эффективнее всего они работают там, где:
Другими словами, Agile идеален для инновационных стартапов, но мало подходит корпорациям с отлаженными процессами и сложной структурой. Для таких компаний лучше работают методы с отдельными элементами Agile, которые проще масштабировать — SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum).
Но и в ИТ-сфере Agile — далеко не единственный способ сделать процесс эффективнее. Здесь хорошо работают такие инженерные практики, как DevOps — метод работы, при котором все участники активно взаимодействуют друг с другом, а рабочие процессы взаимно интегрированы.
Чтобы протестировать новую идею, не проходя все этапы разработки, подойдут Customer Development, Design Thinking и другие продуктовые методики.
Наконец, есть более широкий подход, который включает в себя agile-методики — Business Agility («гибкость в бизнесе»). Он распространился позже — два-три года назад — и включает не только ускорение разработки и выпуска продукта, но и быструю реакцию на внешние изменения, гибкое целеполагание и распределение ресурсов.
В Чем Секрет Популярности и Эффективности Методологии Agile
Сегодня в мире управления проектами существует множество инструментов и методологий, которые помогают улучшить качество производимого продукта.
Также участники опроса рассказали, в каких департаментах их организаций используют Agile методологии. Среди них:
В этой статье мы подробнее расскажем, что же такое Agile методология, на чем она основана и почему так популярна.
Что такое методология Agile?
Agile — это набор практик, целью которых является оперативная реакция на изменения в ходе рабочего процесса.
Такие подходы помогают командам быстро реагировать на обратную связь от клиентов и заказчиков, тем самым постоянно улучшая производимый продукт.
Стоит отметить, что Аджайл (от англ. agile — гибкий) — это не набор конкретных методов и не свод инструкций. Будет правильнее сказать, что Agile — это группа методологий, которые стремятся к улучшению производимого продукта с помощью повторяющихся рабочих циклов и постоянного фидбека от клиентов.
Философию Agile характеризуют гибкость и скорость команды, а также максимальная прозрачность рабочих процессов.
Проще говоря, Agile — это не про отчетность, документооборот и четкий план, а про постоянное общение с клиентом и готовность оперативно реагировать на изменения в ходе проекта.
Чаще Agile используется для разработки программного обеспечения. В этой сфере Аджайл базируется на итерациях фаз программирования и тестирования на протяжении полного жизненного цикла продукта. В Agile и разработка, и тестирование выполняются одновременно, в отличие от методологии Waterfall, в которой проект выполняется поэтапно.
В программировании методология Agile начинается с описания клиентом результата, которого он стремится достичь. Команде важно четко понимать, какие проблемы с помощью разработанного продукта хочет решить заказчик.
С началом работы команда циклично проходит процессы планирования, проектирования, реализации и оценки. В ходе выполнения этих процессов конечный результат может измениться, если выяснится, что он будет еще больше соответствовать целям и стремлениям клиента.
Постоянное взаимодействие команды с заказчиком и остальными заинтересованными лицами способствует оперативному обсуждению грядущих изменений. Это позволяет принимать полностью обоснованные и согласованные со всеми участниками команды решения.
Непрерывное стремление компаний улучшить производимый продукт помогает им оставаться конкурентоспособными на протяжении долгого времени.
Преимущества Agile:
Agile манифест
Публикация Agile манифеста в 2001 году знаменовала рождение Agile как методологии.
Началась эта история в американском штате Юта, где в начале 21 века 17 независимых программистов собрались для обсуждения будущего разработки программного обеспечения.
Группа сошлась во мнении, что главная проблема среди команд разработчиков заключалась в том, что они были чрезмерно сосредоточены на планировании и документировании циклов разработки ПО. И упускали из виду то, что действительно имело значение, а именно удовлетворенность заказчиков.
Манифест группы разработчиков стал новаторским и в корне изменил подход к сотрудничеству с клиентами и достижению целей команды. Agile Manifesto не являет собой свод правил, он выделяет ключевые ценности, которые ставят взаимодействие с людьми на первое место.
За последние 20 лет с момента создания манифест приняли многие команды и организации из разных профессиональных сфер. Сегодня документ доступен более чем на 50 языках, включает в себя 4 ценности и 12 принципов.
4 ценности Agile манифеста:
Авторы манифеста отметили, что не отрицают необходимость пунктов, находящихся в правом столбце. Но все же в приоритет выносят ценности, расположенные слева.
12 принципов Agile манифеста о разработке программного обеспечения:
Популярные Agile методологии
Существует множество различных методологий (или фреймворков) гибкой разработки, которые держат за основу ценности и принципы Agile манифеста. Канбан (Kanban), Скрам (Scrum), Бережливое производство (Lean) и Экстремальное программирование (XP) — часто используемые из них.
Kanban
Это визуализированный подход к управлению проектами. Используя Канбан, команды визуализируют задачи при помощи доски и стикеров либо специальных онлайн-инструментов.
Задачи перемещаются между столбцами, обозначающими их статус. Такой подход позволяет эффективно расставлять приоритеты, контролировать прогресс выполнения проекта, а также ограничивать объем незавершенной работы.
Scrum
Скрам — это методология управления проектами, в которой командой руководит Скрам-мастер. Его главная задача состоит в устранении преград на пути к завершению проекта.
Работа в команде делится на короткие повторяющиеся циклы, которые называются спринтами и обычно длятся 1-4 недели. При этом команда собирается на ежедневные митинги (стендапы), чтобы обсудить текущие задачи и препятствия, которые предстоит преодолеть.
Экстремальное программирование (XP)
Название методологии произошло от идеи использовать полезные классические методы разработки ПО, подняв их на «экстремальный» уровень.
Доступно проиллюстрирует идею XP способ «парного программирования». В этом случае один разработчик занимается написанием кода, а его коллега непрерывно просматривает и проверяет написанное, не дожидаясь окончания работы первого программиста.
Бережливое производство (Lean)
Ключевой задумкой бережливого производства является максимально экономный и разумный подход к ресурсам проекта. Методология Lean — это набор инструментов и принципов, направленных на выявление и устранение возможных потерь для ускорения процесса разработки.
В понятие потерь входят не только затраты времени, финансов и труда. Сюда же относится и нереализованный творческий потенциал команды и каждого ее участника.
Другие гибкие методологии разработки ПО
В управлении проектами существует ряд других методологий управления проектами кроме тех, что мы перечислили выше:
Каждая методология воплощает в себе принципы частых итераций, непрерывного обучения и высокого качества производимого продукта.
Что это будет, классический Скрам из учебников или смесь Канбан и XP, зависит целиком и полностью от вас. Главное, чтобы выбранный способ удовлетворял потребностям проекта. Гибкость приветствуется даже в выборе методологии этой самой гибкости.
Например, разработчики программного обеспечения чаще предпочитают Scrum и XP, в то время как Канбан — любимец команд, ориентированных на сервис (IT, маркетинг или отдел кадров).
Кому подойдет методология Agile?
Несмотря на популярность и высокие результаты при использовании методологии Agile, применять ее в работе над каждым проектом нет никакой необходимости. Все же Agile не панацея.
К примеру, простой баннер или веб-сайт можно сделать поэтапно, используя техническое задание от заказчика.
Существует несколько условий, при которых проекту наверняка потребуется гибкая методология управления:
В этом случае разумнее реализовывать проект постепенно и постоянно его тестировать. Это поможет сэкономить непредвиденные расходы.
Чем дольше будет длиться работа над проектом, тем сложнее прогнозировать и планировать его развитие в отдаленном будущем.
Так бывает, когда команда разрабатывает инновационный продукт. В этом случае невозможно заранее проработать весь его функционал. Поэтому логичнее идти к созданию продукта небольшими шагами и опять же постоянно его тестировать.
Когда идей много, внедрять их одновременно — решение рискованное и экономически нецелесообразное. Ведь заранее сложно сказать, какие из них окажутся удачными.
Идеальное условие для внедрения Agile методологий — это заинтересованность заказчика в плотном сотрудничестве с командой.
Инструменты для работы с Agile-проектами
Вовлеченность в проект нескольких команд делает рабочий процесс менее прозрачным. Кроме того, менеджеру, руководителю и заказчику становится все сложнее следить за прогрессом проекта, контролировать его реализацию и вносить изменения.
Облегчить работу с комплексными проектами и настроить взаимодействие между участниками команды помогут инструменты управления Agile-проектами. С ними вы всегда можете видеть общую картину проекта, контролировать загрузку работников, общаться с командой и держать заказчика в курсе изменений и корректировок.
Онлайн-диаграмма Ганта с легкостью выполнит все эти задачи и упростит работу с проектом всем его участникам.
Онлайн диаграмма Ганта GanttPRO
Ведите проекты, управляйте временем, ресурсами и финансами.
Какую гибкую методологию управления проектами предпочитаете вы?
Agile — незаменимый подход к управлению проектами, который держит команду в тонусе и постоянно помогает добиваться лучших результатов. Благодаря тесному сотрудничеству команды и заказчика, а также вовлеченности и обратной связи потребителей продукта, результат приносит еще большее удовлетворение каждому участнику проекта.
А какие Agile методологии управления проектами предпочитает ваша команда? Делитесь в комментариях ниже.
История создания Agile-манифеста
11–13 февраля 2021 исполнилось 20 лет Манифесту Agile-разработки ПО. Давайте вспомним, какие подходы существовали до него, почему возникла потребность в таком манифесте, как он создавался, кто в этом участвовал, как появился термин «agile», и что думают авторы о полученном результате.
Уже существовали итеративные подходы.
Весной 2000 Kent Beck (один из авторов eXtreme Programming и TDD) на встречу с названием «Extreme Programming Leadership Conference» в The Rogue River Lodge недалеко от города Медфорд в штате Орегон пригласил:
На встрече в числе других вопросов обсуждали:
Идея была холодно поддержана некоторыми участниками. Поэтому (Uncle) Bob Martin и Martin Fowler в перерыве договорились организовать встречу с представителями более широкого круга методов, включая Scrum и Crystal.
Bob Martin и Martin Fowler составили предварительный список. Примерно в то же время Alistair Cockburn собирал похожую встречу. Два списка объединили, да и вообще постарались собрать всех активных, кому может быть интересно. Рабочим названием встречи стало «Lightweight Methods Summit», а в качестве цели в приглашении указали:
Создание манифеста, описывающего общие характеристики легковесных подходов.
Организацию логистики подхватил Alistair Cockburn. Он предложил встретиться недалеко от Солт-Лейк-Сити в штате Юта. Вместе с Jim Highsmith они организовали проживание, питание и активности.
20 приглашённых приехать не смог, например, Grady Booch (один из авторов языка UML) и «Big Dave» Thomas (тёзка другого Дейва — «Pragmatic Dave» Thomas, который приехать смог).
11–13 февраля 2001 года 17 «умников» экспертов-практиков разработки ПО собрались в кондоминиуме The Lodge горнолыжного курорта Snowbird в горах Уосатч в штате Юта — это в западной части континентальных США недалеко от Солт-Лейк Cити.
Каждый практиковал какую-то альтернативу тяжеловесным процессам, основанным на документации. Они собрались, чтобы поговорить, покататься на лыжах, отдохнуть и найти то общее, что объединяет их процессы/методы, которые в то время уже называли lightweight (легковесными).
Встречу начал Боб Мартин, поделившись своим взглядом на общие моменты в существующих легковесных процессах, и предложил цель — зафиксировать эти общие характеристики во благо всей отрасли для создания полезного ПО. Далее фасилитировать встречу стали Martin Fowler & Ward Cunningham. Кстати, знаменитую фотографию, выложенную на странице Манифеста, сделал именно Уорд.
Ожидания от встречи у всех были разными, но не завышенными.
Я не ожидал, что конкретно эта группа сможет договориться о чём-то значительном.
Я надеялся, что мы сможем узнать друг друга получше, и общение приведёт к чему-то интересному. Однако мы быстро нашли много общего.
«Дядя Боб» Мартин впоследствии охарактеризовал их так:
Договорились о многих аспектах разработки ПО, и поэтому решили оформить этот общий базис в виде боевого клича для всей отрасли. Хотели показать, что отстаивают и чему сопротивляются.
Вообще-то, это я и Мартин Фаулер, рисуя на доске во время обеда, сформулировали первые 3 сравнения. Группа расширила их до 5, а затем сократила до 4.
Мы хотим восстановить баланс. Мы поддерживаем моделирование, но не ради того, чтобы диаграмма пылилась в корпоративном репозитории. Мы поддерживаем документацию, но не сотни страниц никогда неактуализируемых и редко используемых томов. Мы планируем, но признаём ограничения планирования в турбулентной среде.
Группа оформила зафиксированные 4 ценности в виде «Манифеста Agile-разработки ПО».
Надеюсь, что Манифест прояснит, что является и не является agile.
Почему именно «Манифест»? Почему именно «Agile»? Читайте в статье «Почему Agile так называется?»
Черновик 12 принципов группа записала во второй части встречи.
Группа назвала себя «The Agile Alliance».
После встречи группа ещё пару месяцев дорабатывала формулировки 12 принципов. Ward Cunningham (изобретатель технологии wiki) позднее создал страницу AgileManifesto.org.
Почти все авторы снова встретились в октябре 2001 на конференции OOPSLA, где объявили, что не хотят какой-то выделенной роли в распространении ценностей и принципов Agile-разработки, и это могут делать не только они.
В конце 2001 они организовали НКО Agile Alliance для развития Agile-методов.
Я очень доволен результатом.
Думаю, я никогда не участвовал во встрече, на которой группа так сохраняла фокус и достигла целей с лёгкостью и минимумом конфликтов.
Лично я в восторге от итоговой формулировки Манифеста. Я был удивлён, что и другие так же довольны итоговыми фразами. Так что, мы всё же договорились о чём-то значительном.
Были попытки докрутить манифест 2001 года, и есть несколько вариаций от других авторов, но сам оригинал остался неизменным.
Статистика применения Agile-подходов собирается по большей части с компаний, их использующих: «по результатам онлайн-опроса 100% россиян пользуются интернетом». Поэтому скажу из своего опыта работы с ИТ-компаниями. С каждым годом Манифест выглядит всё менее революционным:
Участники тренингов, знакомясь с Манифестом, отвечают: «Ну, так это логично. У нас почти так и есть.» И это хорошо! Значит, движемся в хорошем направлении: от формализма и бюрократии к людям и крутым продуктам!
Мастер-класс Бориса Вольфсона. Основы Agile
Этот пост написан по мотивам мастер-класса Бориса Вольфсона (директора по развитию HeadHunter), посвященного (сюрприз!) основам Agile. Материал будет полезен всем, кто либо совсем не знаком с данной методологией разработки сложного ПО, либо имеет о ней смутное представление.
Водопадная модель
Доктор Ройс создал так называемую водопадную модель разработки программных продуктов. Она быстро завоевала популярность на Западе, и некоторое время назад по этой модели работало подавляющее большинство компаний-разработчиков. Что она собой представляет? Разработка продукта проходит через ряд этапов:
Для чего нужна методология гибкой разработки?
Итак, для чего же применяется методология Agile?
Манифест гибкой разработки
Он состоит из нескольких частей. Первая часть называется «Ценности» (Values). Это четыре «взвешивания»:
Приведу свежий пример. Мы выкатили небольшую фичу на HeadHunter, когда ваши навыки может подтверждать любой — поставил вам плюсик, и появится надпись, что столько-то человек подтвердило ваш навык. У меня Scrum подтвердило 18 человек. Мы специально запустили это в очень простом виде, чтобы посмотреть, как к этому отнесутся пользователи. Мы исходили из логики, что будет взаимодействие а-ля LinkedIn или Хабр, где пользователи друг друга плюсуют. Сняли статистику, и оказалось, что у нас эти плюсики ставят, вероятно, после собеседований HR. То есть дальше мы можем развивать эту фичу в сторону HR, либо как-то ее модифицировать, чтобы она была более полезна соискателям. Таким образом, в Agile существует четыре ценности:
12 принципов Agile
Ценности влекут за собой 12 принципов Agile:
Итак, у нас получается пирамида, состоящая из четырех ценностей, на которых выстроено 12 принципов. Теперь появляются конкретные практики.
Практики
Одна из ценностей Agile гласит: мы должны выстраивать рабочий процесс, налаживая взаимодействие и коммуникации между людьми. Это выливается в практические шаги. Например, в утренние стендапы, когда команда устно синхронизирует свою деятельность на предстоящий день. Можно вместо стендапов каждому писать отчет о проделанном вчера, но это уже будет не Agile, потому что возникает поток малозначимой документации. Какие же практики чаще всего используются в компаниях, практикующих гибкую разработку?
Нам надо дойти из точки А в точку Б. «Дойти» — означает «получить обратную связь». Допустим, у меня есть GPS, я могу дойти до какой-то точки и свериться, правильно ли я дошел. Водопадная модель — фактически, один большой шаг. То есть я куда-то пришел, выпустил на рынок продукт, и только после этого могу понять, то ли я сделал. Итеративная модель — это серия шагов. Я делаю первый шаг, снимаю метрики, что у меня используется в продукте, затем корректирую дальнейшие шаги. Пусть я приду не в точку Б, но окажусь в ее окрестностях.
При коммерческой разработке у нас постоянно меняются условия: выходят новые законы, изменяются бизнес-требования, конкуренты вдруг выпускают что-то, что мы должны сделать лучше, чем они. В итоге получается, что мы из точки А должны дойти не в точку Б, а в точку В. Итеративная модель подразумевает, что после выпуска первого релиза мы снимаем метрики, что-то переделываем, делаем следующий релиз, и т.д. И на каком-то этапе понимаем, что конкурент выпустил какую-то фичу, и нам нужно идти не туда. В этот момент мы можем остановиться, принять другие требования и начать двигаться в точку В. При высокой изменчивости условий в процессе создания продукта вы все время будете узнавать что-то новое. И в этом одно из преимуществ итеративной модели.
Еще важный момент: когда менеджеры (и даже разработчики) не очень глубоко погружены в техническую часть, им кажется, что можно итеративно сделать программу, собрать по кусочкам, как паззл. Это заблуждение. Разработчик должен представлять целиком и в деталях каждый элемент картины, и начать его делать за пять шагов. При этом надо иметь в виду, что условия могут поменяться. Это называется инкрементальным подходом («инкремент» — добавление чего-то).
Чтобы работать итеративно и инкрементально, нужно действовать немного иначе. У разработчика в голове должна быть какая-то концепция, которую он постепенно прорабатывает.
Если вы работаете по «водопаду», то обычно у вас фиксировано содержание проекта. Вам говорят: «Хочу, чтобы вы сделали это. Я точно знаю, чего хочу я и мои пользователи. Оцените, сколько человек вам для этого нужно и сколько времени на это уйдет». В Agile мы действуем по-другому: у нас есть команда и фиксированные отрезки времени (я говорю про Scrum), например, двухнедельные итерации. Исходя из этого, мы планируем объем работ, который мы можем выполнить за это время.
Если взять классический подход и спросить: «Вы сделали этот проект успешно или нет? Как это понять?». Я должен его сделать вовремя, не превысив бюджет, и полностью сделать содержание. Если мы смотрим с позиции Agile, то наш проект тем успешнее, чем больше мы поставили ценностей заказчику.
Scrum
У Хенрика Книберга есть такая метафора — Agile-зонтик. Это те методологии, которые являются гибкими. Самая большая — Scrum, экстремальное программирование (XP), DSDM, Crystal, FDD, Kanban. Более половины компаний, применяющих Agile, используют Scrum. На втором месте комбинация Scrum и XP, когда берутся управленческие практики из Scrum и добавляются инженерные. Отдельно отмечу, что комбинация Scrum и Kanban используется примерно в 8% компаний. Сейчас это один из трендов, мода. Название Scrum пришло из регби и переводится как «схватка». Проще говоря, при возникновении спорной ситуации команды выстраиваются, вбрасывается мячик, и нужно друг друга перетолкать. К разработке продукции этот термин впервые применили в 1980-х годах два японца — Хиротака Такэути и Икудзиро Нонака. Это хорошие исследователи в области менеджмента. В частности, они написали документ «The New New Product Development Game». Здесь употребление слова «new» 2 раза не является ошибкой. Просто название переводится как «Новая игра для разработки новых продуктов». Что сделали эти два японца? Они проанализировали, как различные компании создают свои продукты. Причем даже не ПО, а всевозможную технику и электронику. Авторы разделили выявленные подходы на три типа.
Тип C двое японцев сравнили с ситуацией в регби. Почему? Смысл игры в том, чтобы взять мяч и донести его до линии поля противника, преодолевая сопротивление. Но в регби нельзя кидать мяч вперед. Когда ты бежишь и понимаешь, что сейчас тебя положат наземь, то мяч можно отдать назад члену своей команды. Он его ловит и бежит дальше. Если не может преодолеть сопротивление, то бежит назад.
Современный Scrum создан двумя айтишниками — Кеном Швабером и Джефом Сазерлендом. На официальном сайте www.scrumguides.org вы можете ознакомиться с официальным описанием Scrum. Так выглядит общая схема Scrum:
Итак, мы хотим делать какой-то продукт. Он разрезан на отдельные кусочки, которые называются бэклогом (backlog) продукта. Это требование. То есть у нас нет технического задания или какого-то обширного документа, который все заранее описывает. Обычно чем важнее какие-то требования, тем качественнее они разбиты и описаны. Этим занимается владелец продукта (product owner).
Среднестатистическая команда состоит из семи человек (плюс-минус два человека). Если сильно меньше, то, скорее всего, в команде не хватает каких-то специалистов, потому что подразумевается, что Scrum-команда может самостоятельно сделать из бэклога готовый продукт с новой функциональностью. Например, в команде может не быть фронтэнд-программиста. Если вы используете Scrum и проект подразумевает фронтэнд-разработку, то этого специалиста нужно включить в команду.
Компоненты Scrum
Роли
Scrum-команда состоит из команды разработки, владельца продукта и Scrum-мастера.
Бэклог спринта — верхняя часть бэклога. Количество элементов обычно определяется скоростью команды на мероприятии, которое называется «планирование спринта», и проводится перед началом самого этапа спринта. Спринт длится 1—4 недели (чаще всего 2 недели). Чем быстрее и дешевле можно релизить, тем меньше продолжительность данного этапа.
Каждый день команда проводит 15-минутный стендап, Scrum-митинг, на котором все члены команды синхронизируют свои действия. Зачастую эти встречи называют просто «скрамами».
После завершения спринта проводится демонстрация — «Обзор», смысл которой заключается в том, что команда показывает сделанную работу владельцу продукта или кому-то еще. Затем проводится ретроспектива, на которой команда обсуждает, что получилось, а что нет, происходит разбор рабочих процессов, атмосферы в коллективе, предпринимаются попытки что-то улучшить. После этого запускается следующий спринт. В итоге работу Scrum-команды можно представить как цепочку множества спринтов.
Артефакты
Это могут быть карточки на доске с кратким описанием, что собой представляет конкретный функционал. При этом содержание карточки может представлять собой обсуждения с владельцем продукта. Обычно это выливается в тикеты в трекере, который вы используйте — JIRA, Redmine и т.д.
Примеры Scrum-практик: оценки
Здесь не будет канонического/кошерного/ванильного Scrum’а, который описан Швабером и Сазерлендом, и про который можно почитать здесь: www.scrumguides.org. Расскажу о реальных практиках, используемых командами. Есть тяжеловесные, якобы точные методы все «правильно» посчитать и сделать. Но практически все большие проекты выбиваются из сроков. И это касается не только IT. Например, был случай, когда аэропорт не могли запустить в эксплуатацию из-за того, что не был готов софт, отвечающий за автоматическое распределение багажа. Если вы используете гибкие методологии, а также то, о чем я сейчас расскажу, то можете спокойно запускать проекты, без геройства. Один из наших больших проектов, который закончился в сентябре, фактически был готов на production за две недели до официального запуска. Я много наблюдал, как команда, тимлиды и менеджеры пытаются предсказать, когда у них будет готов проект. Это примерно то же самое, что подойти к команде и попросить назвать случайное число.
Agile и Scrum предлагают использовать такую практику: делать относительные оценки, то есть «измерять в попугаях». Это значит, что я оцениваю время, которое у меня уйдет на решение задачи, и сколько она займет попугаев. Их обычно называют story point. Эти story point лучше не привязывать ни к каким временным промежуткам. Каким образом делать такую оценку, почему она называется относительной? Обычно берут какую-то задачу, небольшую, стандартную и понятную всем, и объявляют ее мерой, эталоном — она занимает 1 попугай, 1 story point. Берется следующая задача, сравнивается с первой — она оказывается в 2 раза больше. Сколько она занимает? 2 story point. И таким образом мы раскладываем все задачи. В итоге мы не оцениваем каждую задачу по времени, а сравниваем их между собой. Если где-то ошибаемся, то это нормально. Главное, чтобы во всех задачах ошибались одинаково. Оценка делается командой и в рамках команды.
Что мы можем сделать после этого? Например, запустить двухнедельный спринт и взять верхние задачи без каких-то оценок. Когда спринт закончится, на выходе получим инкремент продукта, в который будет включено какое-то количество задач. Посчитаем, сколько story point мы сделали, и на следующий спринт просто можем планировать такое же количество story point. Подобная оценка получается относительной и эмпирической. Мы не предполагаем, как любят делать управленцы, что программист Вася работает 8 часов и с одинаковой эффективностью, а реально измеряем, сколько команда может проживать story point за спринт. Шкала оценок обычно подбирается так, чтобы различать задачи разных классов.
Если приглядеться, то похоже на числа Фибоначчи, либо на степени двойки. При этом оцениваются обычно действительно большие задачи, которые дальше разбиваются на более мелкие. Для формирования оценок обычно используется покер-планирование. Это модификация метода Delphi. Каждому члену команды дается колода карточек с числами от 0 до 100. Есть еще карточка с надписью «Я не понимаю, что это за задача» и карточка с кофе («Давайте сделаем перерыв, я уже замучился заниматься этой оценкой»). После этого берем задачу номер такой-то, читаем и обсуждаем, что она собой представляет: «Пользователь вводит логин-пароль для того, чтобы авторизоваться на сайте». Обсуждаем, как эта авторизация происходит, где мы храним пользователей. Затем каждый член команды рубашкой вверх кладет карту с оценкой, которую считает нужной. При этом разные члены команды друг на друга никак не влияют, потому что обычно в команде есть тимлид, ведущий, старший разработчик, на которого равняется большинство. После этого происходит вскрытие карт и обсуждение.
Согласно методу Delphi, обсуждение происходит между теми, кто поставил наибольшую и наименьшую оценки. Поставивший наибольшую обычно видит какие-то риски, которые не заметили другие члены команды. Он скажет: «Вы знаете, в эту базу, где у нас хранятся логины и пароли, мы давно не заходили. Там надо что-то отрефакторить, добавить колонку, применить другой хэш» и т.д. А человек, поставивший наименьшую оценку, либо не понимает задачу, либо видит способ сделать быстрее, либо уже делал что-то подобное. После этого происходит второй этап обсуждения: опять все кладут карточки рубашками вверх, потом вскрывают их. Обычно оценки более-менее сглаживаются. Снова проходит этап обсуждения, приходят к консенсусу. В результате записывается в трекер, в тикет-систему, либо прямо на карточку, что у нас эта задача на 3 story point.
Почему это очень хороший Agile-подход? Мы беседовали, обсуждали содержание задачи, основывали наши действия на взаимодействии людей, а не на каких-то формальных процессах. Если кому-то интересны процессные вещи — обратитесь к методу оценки Кокома. Чем еще хорош данный метод? Здесь получается некая командная ответственность за размер задачи. Все берут на себя ответственность за то, что задача действительно такого «размера». Если же вы будете измерять трудоемкость задач, скажем, в днях, то будут ситуации, когда кто-то в команде оценит ее в 8 дней и она попадет к нему, то он ее и будет делать 8 дней.
Что делать в том случае, если заказчик хочет понять, сколько времени займет реализация проекта и просит сразу дать ему оценку? Идеальный вариант — работать с заказчиком по системе «время — материалы». Если заказчик новый, то можно один проект сделать по Fixed Price, убедиться, что заказчик адекватный, и дальше придерживаться системы «время — материалы». Если заказчик не соглашается сразу на данную систему, то можно ее скорректировать: например, если вы заканчиваете проект к определенной дате, то получаете какой-то бонус. На эту тему в сети тоже есть презентации.
Примеры Scrum-практик: скорость команды
Мы берем каждый спринт, измеряем, сколько story point сделали. И если нам надо спланировать девятый спринт, то просто берем среднее значение из предыдущих спринтов. Это называется «принцип вчерашней погоды». Здесь важно то, что мы набираем наиболее важные или ценные задачи исходя из скорости команды.
Если какая-то задача не помещается по размеру, то ее можно разбить на более мелкие, либо пометить, что она не войдет, либо отказаться от ее решения. Надо понимать, что скорость не будет равномерной. Люди работают с переменной интенсивностью, кто-то заболевает, кто-то работает медленнее из-за проблем дома, кому-то надо срочно пообщаться в соцсети, кто-то взял отпуск. Всегда нужно прямо и однозначно говорить владельцу продукта: «У нас есть задачи A, B, C, мы их точно успеем сделать, они попадают в нашу самую низкую скорость. Есть также задача D, которую мы, скорее всего, успеем сделать. Но есть и задача F, которая может выпасть». Кажется, что это неточность, и владелец скажет: «Вы что? Надо все успеть». На самом деле, когда вы ему говорите точно, что самые важные задачи будут сделаны, то это увеличивает доверие между вами и владельцем продукта или заказчиком, и он для каждого спринта сможет выбирать самые важные задачи и гарантированно их получать.
Примеры Scrum-практик: путевой контроль
Как во время спринта контролировать, что у нас все идет хорошо? Мы спланировали спринт и начали его реализацию. Для контроля используется диаграмма сгорания Burn Down Charts.
По горизонтали отмечаем дни — это двухнедельный спринт, 10 рабочих дней. По вертикали с одной стороны отложены story point, с другой — истории пользователей или элементы бэклога. Если бы мы с вами были роботами, а задачи маленькими и разбитыми на кусочки, то мы шли бы по пунктирной линии — это линия идеального Burn Down Charts. Что эти линии означают? Верхняя — сколько мы сделали историй пользователей, нижняя — количество story point. Такие графики автоматически строятся во многих системах для трекинга задач.
Как их читать? Если ваш график находится над линией идеального Burn Down, то вы отстаете, медленно работаете. Тогда к концу спринта будет не ноль задачек или story point, а где-то 20—25. Можно в Excel построить тренд или регрессию и посмотреть, сколько у вас получится задач с такой скоростью — очень просто и наглядно. Если команда видит, что она идет поверх идеального Burn Down, то надо принимать меры. На практике обычно получается вот так.
Идут небольшие отставания, но это у хорошей команды. Другой вариант встречается реже, когда Burn Down ниже диагональной линии. Это означает, что вы идете с опережением, то есть, скорее всего, вы просто взяли мало задач.
Очевидно, что надо увеличить объем работ. В крайнем случае, здесь можно еще снять задачки, но это повод обсудить на ретроспективе, почему у вас так получилось. Этот график — артефакт, который можно в конце двухнедельной итерации проанализировать и сделать выводы.
Примеры Scrum-практик: доски задач
Обычно в Scrum используют доски задач, хотя они не являются обязательным элементом. Команда распределяет задачи по отдельным этапам и размещает на доске в виде отдельных карточек. Есть электронные реализации досок задач, плагины для JIRA и т.д. Задачи упорядочиваются по степени важности. Когда команда собирается с утра, обновляются статусы задач, их переносят на другие этапы, смотрят, есть ли где-то затыки.
Примеры Scrum-практик: обзор спринта
На этой встрече по мере возможности участвуют все заинтересованные стороны: разработчики, пользователи, служба поддержки, системные администраторы и т.д. Обзор спринта нужен для того, чтобы запустить цикл обратной связи. Вы показываете владельцу продукта разработанный инкремент. Он смотрит, делает замечания, вносит предложения, отдает их вам обратно в бэклог. Вы берете в работу, создаете новый инкремент, через одну-четыре недели показываете и снова получаете дополнительные изменения в требованиях. То есть запускаете цикл, который в итоге приведет вас к продукту, который хочет получить его владелец.
Примеры Scrum-практик: ретроспектива
Ретроспектива нужна для постоянных улучшений. Гуру менеджмента Эдвард Деминг когда-то сказал, что совершенствоваться необязательно, выживание — дело добровольное. Ретроспектива — как раз тот этап, на котором вы можете заняться совершенствованием. Как это происходит? Вся команда собирается и обсуждает все ступени до самой ретроспективы. Обычно это длится от часа до четырех, может длиться даже день. Если вы посмотрите олдскульные книжки, там есть ретроспектива даже на несколько дней.
Начинается ретроспектива с открытия. Обычно она занимает 5% времени. Задача — растормошить всех присутствующих на ретроспективе, потому что очень часто в командах, особенно айтишных, присутствуют не очень общительные люди, но порой имеющие блестящие мысли. Задача ведущего заключается в том, чтобы разговорить этих людей. Второй этап — сбор данных, он занимает до половины времени. Команда ищет какие-то факты. Их можно вспомнить, достать из трекера, распечатать. Также можно собрать статистику по багам, кто репортил, каков их статус — вариантов множество. После сбора фактов начинается мозговой штурм: нужно понять, в чем проблема, проникнуть в суть, сгенерить идеи, которые помогут ее решить. На это уходит до трети времени. Например, если у нас много мелких багов, возникающих не на уровне интеграции системы, а в коде разработчиков, то можно предложить использовать модульное тестирование. Если у нас очень плохое качество, как его улучшить? Можно попробовать парное программирование, какие-то инструменты, которые делают автоматизированную проверку кода, еще что-то. Обычно набирается 5—10 идей. Далее нужно воплотить эти идеи в жизнь. Мы не можем сразу внедрить code review, разработать какие-то инструменты. Поэтому выбирается максимум одна-две идеи, реализацию которых надо запланировать на следующий спринт. После этого благодарим всех и закрываем ретроспективу. А еще через две недели можно оценить, получилось у нас это или нет, изучить другие проблемы.
На ретроспективе можно также понять моральный дух команды — для этого тоже есть инструменты. Можно просто начертить временную линию спринта, чтобы каждый член команды вспомнил, что происходило в этот день, наклеил стикер с фактом «закончил разрабатывать задачу», «исправлял быдло-код», «применил новую технологию Machine learning». После этого по каждому факту можно внизу нарисовать, насколько этот факт был для человека интересным, или, наоборот, отстойным. После этого построить медиану, которая отразит состояние и динамику морального духа команды.
Есть такое понятие, как «Цикл Деминга». Он состоит из четырех этапов: Plan — Do — Check (Study) — Act.
После этого можем вносить изменения: например, хотели сделать покрытие 50% — сделали, количество багов уменьшилось, но они еще остались — давайте поднимем до 70%. Или сделали 70%, цикл прокрутили второй раз, проверяем — улучшилось. Давайте сделаем 90%. Еще раз прокрутили: количество багов не уменьшилось, а затрат на написание и поддержку тестов получается много. Давайте сделаем более слабую границу. Благодаря этому циклу команда постепенно улучшает какую-то часть процессов. Самый простой вариант ретроспективы — Real-Time Board Service.
Команда вешает стикеры, что ей понравилось, что нет, а что нужно улучшить. Здесь могут быть как мысли вслух: «Все сделали. Это очень круто», «Самостоятельная команда», «Команда маленькая — не нравится», так и технические вещи. На основе этого можно выдвинуть идеи и некоторые из них отобрать на реализацию.
Напоследок о Scrum
Надо сказать, что Scrum, как и все гибкие методологии, лучше работает в командах, которые сидят в одной комнате. Тем не менее в сети можно найти сотни презентаций о том, как применять гибкие методологии в распределенных командах, когда люди работают на удаленке. Здесь идея такая: вместо реального общения максимально использовать программные и аппаратные инструменты. Что обычно используют? Во-первых, общий трекер, что-то типа JIRA. Это действительно помогает. Популярны программистские чаты, например, HipChat. Для общения — Skype, Hangout. Главное, чтобы была видеосвязь, и чтобы можно было демонстрировать экраны своих компьютеров.
Kanban
Это вторая по популярности методика. Ряд компаний работают одновременно по Scrum и Kanban, получается Scrumban. Наверное, это один из будущих трендов. Историческая справка: Kanban появился в Японии. Этим словом называлась бумажка с пул-запросом на какие-то действия. Например, мне нужна какая-то деталь, на нее делается отдельный канбан. Но в IT это все-таки применяется немножко в другом виде.
Ценности и принципы
В айтишном виде Kanban появился в 2010 г., то есть это достаточно свежая, хорошо описанная методология. Ее автор — Дэвид Андерсон. В следующем году, скорее всего, выйдет обновленная версия методологии. Если Scrum подразумевает жестко предписанные процессы, которые должны сломать то, что было в организации до этого, то есть «Так, все мы теперь работаем по спринтам, с утра приходим, стендапимся, в конце спринта показываем демонстрацию», то Kanban подразумевает более эволюционные изменения.
Визуализация
Обычно используется та же самая доска, что и в Scrum. Самый простой вариант — прото-Kanban. Поток задач разбивается на отдельные этапы. Что-то находится в плане, что-то в аналитике, что-то в разработке, что-то в тестировании, что-то мы уже сделали. При этом реализуется принцип ограничения количества одновременно находящихся в работе задач — WIP (Work in Progress). Есть формула Литтла, которая связывает скорость прохождения задачи в такой системе и количество одновременных задач. Чем меньше WIP, тем быстрее задачи проходят цепочку. Допустим, у нас завал в тестировании, а разработчик сделал следующую задачу. Он видит, что у тестировщиков проблема. Тогда разработчик помогает им что-то сделать, или они идут к руководителю и говорят: «Нам нужен еще тестировщик».
Обычно команда начинает с большого ограничения задач в работе, например, не более двух задач на человека. Если у меня один тестировщик — две задачи для разработки, если четыре тестировщика — восемь задач. Постепенно общее количество задач уменьшается, скорость работы возрастает. И доска уже выглядит примерно так.
Здесь есть те же самые WIP, внизу — критерии готовности (Definition of Done). Столбец делят на две части: «в работе» и «выполненное». Иногда доску делят на дорожки и размещают WIP по горизонтали. Это уже более продвинутая, полноценная Kanban-система. Каждая дорожка соответствует определенному классу обслуживания. Например, есть горячие задачи, когда к вам прибегает начальник и говорит: «Надо сделать это быстрее». Это отдельный класс обслуживания, под него стоит забронировать WIP.
Как и в Scrum, здесь тоже можно создавать диаграммы. Обычно их называют «Диаграммы кумулятивного потока». По горизонтали отмечено время, по вертикали — количество задач. Разными цветами показаны разные этапы. Я упоминал, что улучшение нужно осуществлять на основе цифр, используя научный подход. Эти цифры можно извлечь из диаграмм. Самые важные из них — WIP, то есть количество задач за исключением запланированных и выполненных. Мы его должны сокращать.
Вторые важные критерии — Cycle Time и Lead Time. Определения бывают разными, нужно очень внимательно смотреть. Эти два числа показывают, насколько быстро задачи проходят через вашу Kanban-систему.
В данном случае Lead Time включает в себя ожидание, то есть как воспринимают вашу Kanban-систему заказчики. Cycle Time — насколько быстро задача проходит через Kanban-систему без ожидания, в общем бэклоге. Оба параметра нужно уменьшать, тогда ваша система будет работать быстрее.
Kanban очень хорошо приживается в компаниях с корпоративной командной культурой, когда есть какая-то иерархия. Scrum удобен для команд, которые уже хорошо общаются, в компаниях с плоской структурой, где мало начальников.