Wallride

Начнём с того, что я — руководитель интернет проектов по части разработки. Всем привет! Хочу поделиться с коллегами наработанным опытом в области построения процесса разработки и в частности в области применения гибких методологий. Про них много умного написано в интернете и армия евангелистов постоянно проводит доклады на конференциях, организует всевозможные семинары (спросите Google). Сильно вдаваться в теорию не буду, а расскажу про свой реальный опыт применения.

Пару лет назад я столкнулся с принципами Agile в относительно крупной разработческой компании. Там декларировались все ценности и номинально практиковались релизы, итерации, скрам-митинги, бек-логи (функциональные требования), демонстрации и т.д. Сейчас я работаю в небольшом стартапе с командой из 4-6 человек, и, опять же, используем принципы Agile.

Сначала кратко расскажу о тех практиках, которые использую и считаю эффективными:

1. Бек-лог (функциональные требования). Проекты бывают большие. Очень большие. Они могут тянуться годами, а обилие функционала способно затмить небо. Как же подступиться к такой мега-задаче? Как оценить трудозатраты на разработку?
   Мы дробим функционал системы на модули, компоненты, группы страниц и т.д. Для каждой компоненты составляем список функциональных требований. Причём требования должен составлять не заказчик, а менеджер от разработки, чтобы эти требования отражали бизнес-логику и были исчерпывающими для разработчиков. Все требования оценивается в условных единицах трудоёмкости, например, в человеко-днях. Таким образом весь проект покрывается списком оценённых требований, и становится приблизительно ясным масштаб «бедствия».
2. Релизы. Требования и компоненты группируются в этапы поставки продукта — релизы.
   Я предпочитаю соотносить релизы с этапами развития продукта:
   1 — Альфа-версия, опытный образец или прототип. Реализует минимально необходимый функционал, отвечающий целям проекта;
   2 — Закрытая бета для внутреннего использования и тестирования
   3 — Открытая бета, доступная для внешнего тестирования, отладки процессов и получения фидбека от первых клиентов;
   4 - Выход в коммерческую эксплуатацию;
   5 и далее — развитие продукта.
3. Итерации. Я предпочитаю недельные итерации, поскольку за неделю бывает реализовано довольно много нового функционала, требующего обсуждения на демонстрациях.
4. Демонстрации. Это очень важный момент в гибких методологиях. Особенность этого мероприятия в том, что заказчик постоянно видит результат работы команды, а команда имеет возможность получать обратную связь — что было сделано хорошо, а что нужно переделать.
   Как правило в ходе этих демонстраций всплывают ошибочные требования, и в режиме мозгового штурма приходят более удачные идеи, чем те, которые планировались в самом начале проекта. Таким образом бек-лог пополняется свежими требованиями, основанными не на предположениях, а на реальном опыте использования ПО.
5. Ретроспективы. В каждой ключевой точке проекта (планирование итерации, демонстрация, релиз) необходимо проводить разбор полётов. Редко когда разработка идёт гладко и все сроки соблюдаются. Так или иначе возникают ошибки, всевозможные проволочки и бестолковая трата времени. И именно регулярное проведение ретроспектив позволяет анализировать ход работы в предыдущем периоде, выявлять проблемы и своевременно их устранять. Важно не превращать этот процесс в порку подчинённых. Разработчики сами должны выявлять факторы, мешающие их работе. А я как руководитель должен устранить эти факторы со всеми своими административными полномочиями.
6. Ежедневные летучки (SCRUM-meetings). Каждое утро команда разработчиков собирается вокруг доски с задачами и каждый обозначает, что было сделано вчера, что будет сделано сегодня, какие есть вопросы и проблемы. Регламент — 15 минут, стоя. Такие короткие митинги позволяют разработчикам постоянно быть в курсе событий, кто чем занимается и получить дельные советы. Ну а у руководителя, таким образом, всё под контролем!

Это тот набор инструментов из арсенала Agile, которыми я пользуюсь. Разумеется, эти практики не могут подойти абсолютно всем ввиду ряда причин, о которых ниже. Сейчас гибкие методологии у меня применяются в небольшой команде и работают из рук вон хорошо! Разработка продукта прозрачна для заказчика. Он всегда видит результат и может своевременно внести коррективы.

Однако в крупной компании все они фатально не работали в 90% случаев! И вот какие факторы препятствовали:

• Внешние заказчики диктовали одновременно сроки и объём работ. Подозреваю, что бюджет тоже. Это были очень крупные и несговорчивые заказчики, имя которых все знают, но я не назову
• Менеджеры продуктов оказывали на разработчиков давление по всем фронтам, используя всю иерархию оргструктуры. В сущности, они не были частью команды, поскольку преследовали другие цели (собственные бизнес-задачи и «прикрыть свой зад»)
• Проектов было очень много, от чего фокус внимания у команды рассеивался. Сложно сконцентрировать внимание и творческий потенциал на разработке нового проекта, когда 50% времени тратится на рутину в виде поддержки старого барахла.
• Бюрократия и неработающие регламенты.  Говорит само за себя.

Такие условия подобно напалму уничтожают почву для открытого обсуждения, новаторства, творчества и производства высококачественных продуктов с удовольствием от работы. Ценность под названием «прикрыть свой зад» начинает доминировать.

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

Не смотря на негативный и даже провальный опыт внедрения Agile, перечисленный набор практик в любом случае очень полезен и в большинстве случаев жизнеспособен. Причём не только в кругах разработчиков, но и во всех смежных областях с разработкой ПО. Важно выбирать с умом те практики, которые БУДУТ эффективны в Вашей компании. По крайней мере они будут полезны Вам как руководителю и Вашей команде, поскольку эти практики способствуют поддержанию тонуса и здоровых отношений.

А используете ли Вы Agile и с каким успехом?