Agile-методология: 4 примера 5 смертельных грехов

Extreme programming

Особенность Scrum заключается в том, что этот фреймворк уделяет мало внимания практикам разработки. Поэтому некоторые agile-компании (порядка 10%)

его с экстремальным программированием (XP).

Экстремальное программирование привлекло к себе внимание в конце 90-х. Концепция зародилась в сообществе Smalltalk, а её авторами считаются разработчики Кент Бек (Kent Beck) и Уорд Каннингем (Ward Cunningham), которые хотели сформировать новые практики в разработке ПО, сделанные для людей.

Первым проектом, созданным по методологии Extreme Programming, стала система контроля платежей Chrysler Comprehensive Compensation (C3) в середине девяностых. Сам термин «экстремальное программирование» появился в 1997 году.

Концепция строится на основании двенадцати приёмов:

  1. Разработка через тестирование (Test-driven development)
  2. Игра в планирование (Planning game)
  3. Заказчик всегда рядом (Onsite customer)
  4. Парное программирование (Pair programming)
  5. Непрерывная интеграция (Continuous integration)
  6. Рефакторинг (Design improvement)
  7. Частые небольшие релизы (Small releases)
  8. Простота проектирования (Simple design)
  9. Метафора системы
  10. Коллективное владение кодом (Collective code ownership)
  11. Стандарт оформления кода (Coding standard)
  12. 40-часовая рабочая неделя (Sustainable pace)

XP сильно напоминает Scrum и предполагает, что заказчик плотно

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

Однако Extreme Programming делает сильный упор на тестирование, что отличает её от Scrum. Методология гласит, что разработчик не может сказать, что код написан правильно до тех пор, пока не пройдут все модульные тесты. Поэтому часто XP идет рука об руку с техникой разработки Test Driven Development (TDD), когда сперва пишется тест, а затем логика для его прохождения.

Но такая «тестоориентированность» одновременно и недостаток подхода. Чтобы адаптировать XP, нужно инвестировать в создание инфраструктуры автоматизированных тестов и непрерывного развертывания ПО.

При этом, если в случае Scrum компания может послать менеджеров проектов на двухдневные курсы, то в случае с экстремальным программированием приходится тренировать всю команду разработчиков. Что гораздо более затратно. Нужно менять культуру в организации, объединяя несколько отделов: XP требует, чтобы тестировщики, UI-дизайнеры, программисты, архитекторы и пользователи работали сообща.

Agile-методология: 4 примера   5 смертельных грехов
/ Flickr / U.S. Army / CC

Где используется agile

Изначально Agile использовался больше для разработки ПО, компьютерных игр, программных интерфейсов. Это были Google, Netflix, Microsoft, WordPress, Magna International, Spotify, Intronis, Ericsson, Dell, Adobe, Accenture, Riot Games, CH Robinson, Scrum Alliance.

На сегодняшний день Agile применяется уже значительно шире. К примеру, в производстве истребителей (Saab), сельскохозяйственной техники (General Electric и John Deere).

В России Agile стал востребован лишь спустя несколько лет (после появления на Западе), но его популярность здесь, пожалуй, ничуть не меньше, чем за рубежом. Данный подход к планированию успешно задействуется в сфере IT, на производственных предприятиях, в банках, ритейл-компаниях, во всевозможных онлайн-службах.

В частности, это: First Line Software (сфера деятельности – разработка ПО), «М.Видео» (торговля электронной техникой), Dostаевский (компания по организации доставок), IVI (онлайн-кинотеатр), 12 Storeez (модный бренд одежды), НМЛК (сталелитейная компания).

ScrumTrek каждый год анализирует использование Agile в России. Результаты за 2020 год (были собраны данные по тысяче участников из 80 российских городов) следующие:

  • Географически: 41 % исследованных команд работают в Москве, 14 % в Санкт-Петербурге, далее, в Перми – 6,4 %, в Казани и Иннополисе (специализированный научный IT-кластер) – 5,5 %, в Новосибирске – 5,4 %.
  • По отраслям: сфера деятельность 42 % участников, использующих Agile – это IT, далее 18 % приходится на финансовые учреждения, 8 % — на промышленные предприятия, 7 % — на ритейл, 4,8 % — на телекоммуникации, 3,2 % — на энергетическую отрасль и 2,8 % — на консалтинг.
  • 33 % команд применяют Agile при планировании проектов внутри собственной компании и при организации услуг для своих клиентов.
  • 41 % применяют в качестве фреймворка от Agile систему Scrum. Это на 7 % меньше, чем в прошлом году, и на 9 % меньше, чем в 2022. Далее, Kanban в рамках Agile-подхода используют 23 % опрошенных. Это на 8 % больше, чем в 2022 и на 13 % больше, чем в 2022. Получается, что популярность Kanban постепенно растет, приближаясь к показателям к Scrum. А вот в мире рост использования Scrum составил с 54 % до 58 %, а Kanban – с 5 % до 7 % (что, кстати, втрое ниже, чем в России).
  • 60 % предпочитают совмещать разные подходы, а 30 % имеют собственные методики или комбинированные варианты;
  • 22 % считают себя высококомпетентными в применении Agile. В сравнении с прошлым годом это на 9 % больше. Многие пару лет назад были едва знакомы с принципами Agile, а теперь свободно ими владеют, задействуют разные подходы, разрабатывают собственные. Впрочем, данные исследования ведутся всего лишь в течение трех лет, и тут еще рано делать выводы о ценности и результативности Agile.

Когда работает agile

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

Под этим имеется в виду не талант менеджера по продажам (умение продать за дорого то, что стоит дешево), а то что результирующий продукт распространяется в виде копии, и прибыль зависит напрямую от количества продаж и цены. Напротив, продукт сделанный под индивидуального заказчика, проданный один раз, должен управляться обычным менеджментом — водопадом.

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

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

Образование производства виртуального товара содержит в себе ещё одну важную особенность. Для товарного производства решение о производимом товаре находится в руках капиталиста или государства — то есть юридического лица, производящего кооперацию работников на основе капитала.

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

Ещё одним важным отличием менеджмента товара и виртуального товара становится финансирование проекта. Разработка по водопаду требует авансирования капитала сразу во все стадии проекта, и подразумевает что на рынок нужно выйти с готовым продуктом. Гибкие практики финансируются венчурным капиталом, и принять решение о продолжении проекта или закрытии можно сильно раньше, что снижает риски.

Нужен ли вашей команде agile

IT – основная сфера, где сейчас находит применение Agile. Постепенно он проникает и в другие области, однако далеко не везде гибкий подход целесообразен. Он эффективен, если:

  • небольшая команда работает над созданием или улучшением продукта, не имея достаточной ясности в постановке задачи;
  • необходимо непременно раньше конкурентов успеть выпустить первую версию продукта;
  • ведется разработка уникальной инновации, свойства которой заранее неизвестны.

По сути, Agile отличный инструмент для стартапов, но не для крупных компаний с множеством процессов, работа которых уже давно отлажена. Тут эффективнее себя показывают доступные для масштабирования элементы Agile вроде SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum).

Кстати, и для IT-сфеы Agile-подход – не панацея, тут отлично работает, например, DevOps. Это когда налаживается интеграция всех рабочих процессов и тесное взаимодействие между исполнителями.

А для тестирования новых идей (без многократного повторения всех этапов разработки) отлично годятся методики типа Customer Development, Design Thinking и др.

Нужен ли вашей команде Agile
Нужен ли вашей команде Agile

Есть еще более обобщенный метод Business Agility (ему буквально 2-3 года, переводится как «гибкость в бизнесе»). В его основе – тоже принципы Agile (подразумевающие быструю разработку продукта), плюс еще быстрое реагирование на изменение внешних условий, гибкий подход к постановке целей и задействию ресурсов.

О принципах agile четко и ясно

Все основные принципы гибкой разработки изложены в одном документе – Манифесте (Agile Manifesto, 2001). Выше я уже несколько раз упоминал отдельные принципы, лежащие в методологиях объединяемых Agile.

Основные постулаты:

  1. Люди и взаимодействие важнее процессов и инструментов – акцент на людях и отношениях между ними, как основном факторе успешности проекта. Люди руководят и применяют необходимые им процессы и инструменты, а не работают под управлением заранее принятого регламента. Именно поэтому agile-методики предполагают отбор в команду мотивированных профессионалов, с универсальными навыками. Тогда не потребуется внедрять изощренные методы поощрений и штрафов, люди смогут подменять другу друга, участвовать в дискуссии о продукте осознанно и эффективно. Взаимодействие между членами команды может строиться с помощью любых удобных инструментов, но не документов, регламентов и инструкций.
  2. Работающий продукт важнее исчерпывающей документации – менять, адаптировать, корректировать легче то, что уже существует и работает, а не то, что подробно и исчерпывающе описано в бумагах. Сначала надо сделать что-то простое и работающее, чтобы затем, оценив и апробировав сделанное, внести коррективы или отказаться от реализованного в пользу иного варианта исполнения. Но в итоге либо продукт есть и работает (пусть и требует корректировок, дополнений и доработки), либо есть проверенная гипотеза, от которой надо отказаться. В противном случае в большинстве случаев будет реализован проект, точно соответствующий описанию на бумаге, но не соответствующий рынку, производству, и главное реальным нуждам клиента.
  3. Сотрудничество с заказчиком важнее согласований условий контракта – в сложившейся реальности заказчик – а им может быть и соответствующее подразделение внутри компании – не всегда может четко сформулировать требования к продукту, зачастую у него есть только профиль клиента и проблема, с которой тот сталкивается. Заказчик может оценить реализованный продукт с точки зрения соответствия его ожиданиям, но не формализовать их. Ему легче потратить время и деньги на версии продукта, чем на всестороннее и исчерпывающее описание, причем такое описание может оказаться более дорогим, трудоемким и затратным по времени, чем гибкая разработка. Методом оптимизации в данном случае как раз и будет сотрудничество с заказчиком, вовлечение его в работу проектной команды.
  4. Готовность к изменениям важнее следованию первоначальному плану – это, наверное, самый противоречивый постулат. С одной стороны легче и проще менять все по ходу реализации, с другой – процесс такой разработки может затянуться на неконтролируемое время и привести к неожидаемым результатам.

Ключевые принципы гибкой разработки, изложенные в Манифесте:

  1. Удовлетворение клиента за счет ранней и бесперебойной поставки ценного программного обеспечения. Данный принцип относится не только к программному обеспечению. Согласно этому принципу работу над продуктом следует разделить так, чтобы по завершении каждого цикла (спринта клиент получал рабочую версию продукта.

    На примере калькулятора для анализа проекта:

  2. Изменения требований приветствуются. Разработка продукта ведется в быстроменяющейся конкурентной среде, когда по завершении цикла разработки уже может измениться рынок, например, вышел аналог. Тогда, чтобы не выкинуть в мусорную корзину реализованный проект, его дорабатывают, кстати, можно использовать опыт уже вышедшего на рынок конкурента. Поэтому в рамках гибкого подхода изменения требований продуктов даже в конце разработки – приемлемы и приветствуется.
  3. Частая поставка рабочего программного продукта. Важность этого принципа все в том же – мир быстро меняется и чем короче цикл поставки, тем точнее финальный продукт будет соответствовать ожиданиям.
  4. Погружение заказчика в работу над проектом на протяжении всего времени его реализации. Заказчик в этом случае является единственным участником команды, носителем знания, «как надо», соответственно его заключение о соответствии продукта ожиданиям и его удовлетворение от результата – ключевой критерий. Чем чаще ожидания заказчика сопоставляются с работой команды проекта, тем, естественно, выше соответствие ожиданий и результата.
  5. Проектом занимаются мотивированные личности, которые обеспечены соответствующими условиями работы, поддержкой и доверием. Этим принципом проблемы мотивации выводятся за рамки работы над проектом. Предполагается, что на этапе формирования команды, необходимо отбирать только мотивированных профессионалов, самодостаточных личностей, которых не надо подгонять, уговаривать и т.п. Задача сведется только к созданию условий, не препятствующих реализации их потенциала в этом проекте: инструменты связи, возможности для взаимодействия, оборудование и материалы и др.
  6. Рекомендуемый метод коммуникации – лицом к лицу. Это спорный принцип в цифровую эпоху, когда многие компании развивают сетевое взаимодействие и внедряют удаленную работу в свои процессы. При этом личное взаимодействие имеет ряд преимуществ, которых нет у других видов коммуникации: например, скорость решения вопросов, невербальные сигналы (эмоции, жесты), мотивация (можно похвалить, выделить, поставить «на место»). В любом случае манифест акцентирует на этом внимание и заявляет, как один из ключевых принципов.
  7. Работающее программное обеспечение – лучший измеритель прогресса. Перенося этот принцип на более общую систему координат, работающая версия продукта – лучший критерий успешности и прогресса проекта. В большом числе случаев этот принцип реализуем и понятен, а там, где не применим Agile.
  8. Разработчики, а также их куратор и заказчик должны быть готовы сохранять заданный темп в разработке в течение не определенного (читай – неограниченного) времени. Надо понимать, что в такой парадигме срок разработки финальной версии продукта не известен, более того, финальной версии может и не быть, что мы видим на примере постоянно шлифуемых и дорабатываемых версий десктопного программного обеспечения и мобильных приложений.
  9. Краеугольным камнем Agile-разработки заявляется стремление к техническому совершенству и качеству планирования спринтов. Этот принцип призван сбалансировать возможный негативный эффект на качество разработки от других принципов, например, частой поставки рабочего продукта. Можно разными методами добиваться частой поставки в условиях отсутствия или недостатка спецификаций продукта, например, использовать готовый, но некачественный код разработанный «индийскими программистами» и пренебречь тестированием. Личные качества, профессионализм разработчиков и коллективная ответственность – заложенные в принципе «стремления к техническому совершенству» требуют более высокого уровня ответственности.
  10. Простота и минимизация лишней работы. Этот принцип надо бы применять во всех проектах, но в качестве ключевого принципа он заложен только в Agile-методиках. Приоритет отдается тому, что делается быстро с минимальными затратами. Отказываемся от ненужных работ как в процессах, так и в отношении продукта, например, консалтинговая компания обычно готовит многостраничную презентацию по выполненным работам и предполагаемым шагам, но если клиент интегрирован в команду, то ему формальная бумага не нужна, ему важнее то, что уже идет в работу – те самые два-три слайда, которые уже готовы для финальной презентации. В отношении продукта – можно стремиться реализовать все задумки в отношении функционала сразу до первого релиза, однако так уже никто не делает, в каждой итерации продукт совершенствует в соответствии с требованиями рынка, что может подразумевать как добавление нового функционала, так и удаление каких-то фич, не «принятых» клиентами.
  11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. Речь идет не об анархии, а о высокой внутренней дисциплине в команде, четком распределении ролей и высоком уровне профессионализма каждого участника. Если вы не можете самоорганизовываться – не работайте в концепции Agile.
  12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы. Этот принцип подчеркивает, что вся полнота ответственности за проект и его продукт лежит на всех членах команды, никто со стороны не вносит корректив и не анализирует эффективность – все делают участники внутри своего коллектива в интересах проекта и результата.

Agile строится на предпосылке, что проект реализуется высокопрофессиональной мотивированной самоорганизующейся командой, принимающей и понимающей все принципы гибкой разработки. В противном случае – фокус не сработает

Гибкие материалы:  Что такое Agile и подойдет ли он вашей компании | РБК Тренды

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *