Каталог решений - Agile в ИТ-проектах: где-то между невозможно и неизбежно

"У нас Agile". В эти слова говорящие их вкладывают самое разное. Многие делятся, что "у нас в компании слово Agile — модное, но никому непонятно, что оно значит". В ходе своей профессиональной деятельности я волею судеб неплохо изучила как матчасть, так и практический опыт реализации проектов по самым разным методологиям. И здесь я хочу попробовать поговорить про то, использование каких инструментов, мероприятий и технологий следует из решения работать по гибким методам. И с какими сложностями/подводными камнями можно столкнуться при их использовании. 

Немного на эту тему я уже говорила в статьях Можно ли объять необъятное или чем Agile отличается от водопада? и Почему Agile превращается в Тяп-ляп. Кто виноват и что делать?, а здесь попробую тему развить дальше. 

Очевидно, что общие принципы гибких методологий записаны на имеющихся в открытом доступе скрижалях — в Agile манифесте. Честно скажу, при первом же прочтении Agile манифеста его тезисы лично мне захотелось поделить на две категории: "Спасибо, капитан Очевидность" (например, — Работающий продукт — основной показатель прогресса) и "Ну-ну, свежо предание, но верится с трудом" (например, — Над проектом должны работать мотивированные профессионалы)…
 
Поэтому интересен, на мой взгляд, не сам манифест, а те конкретные предложения по организации работы, которые из него следуют — в плане внедрения ценностей, инструментов, ролей, мероприятий и прочая… Давайте я попробую здесь обобщить конкретные выводы из Agile-манифеста.  И приглашаю начинающих и опытных РП продолжить дискуссию, которую мы начали вчера на вебинаре, посвященном сопоставлению гибких и классических подходов к управлению проектами. А именно —

В чем сильные и слабые стороны тех или иных инструментов/ценностей/подходов Aglie?

Как многие читатели уже знают, я увлекаюсь парусным яхтингом (не путать с яхтингом Романа Абрамовича), поэтому, наверное, люблю морские образы и метафоры. И в ходе вебинара мы попробовали рассмотреть разные инструменты через призму метафоры парусной яхты:

• Парус: Что является движущей силой для выбранного инструмента? Что мы выигрываем, когда у нас получается применить тот или иной инструмент?
• Ветер: Что наполняет наши паруса? За счет чего у нас получается работать с тем или иным инструментом?
• Якорь: Что тянет нас на дно? Какие недостатки стоит иметь в виду?
• Рифы: Какие риски нам надо учесть, когда мы работаем с теми или иными инструментами?

Итак. Давайте устроимся поудобнее и почитаем, что же предлагают принципы Agile-манифеста? Лично я нашла в нём 6 основных тезисов:

I. Готовность к изменениям

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

II.  Сотрудничество

• На протяжении всего проекта разработчики и представители бизнеса должны  ежедневно работать вместе.
• Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как представителей бизнеса с командой, так и внутри команды.

III. Частота и ритмичность

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

IV. Ценный продукт

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

V. Главное — это люди

• Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
• Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

VI. Думаем, как работать лучше

• Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
• Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

А теперь давайте посмотрим, что же из этих тезисов следует на практике.

I. Готовность к изменениям

Читаем манифест:

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

 

Что из этого следует на практике?

• Гибкие контракты — потому что когда мы формулируем требования в процессе работы, мы не можем на старте знать весь объем работ.  (как из этого выкручиваться — я уже писала в статье Контракты Agile: как заключать договора в условиях расползания содержания). 
• Бэклог в виде "хотелок" бизнес-заказчика, изменяемый на протяжении всего проекта — вместо ТЗ, написанного на старте
• Готовность к переделкам — они сразу закладываются в стоимость контракта (хотите без переделок — работайте по водопаду, только тогда не грустите, что получили на выходе совершенно не то, что хотели)
• Планирование по кусочкам — вместо планирования всего на старте

На вебинаре мы рассмотрели тему планирования по кусочкам — в чем плюсы и минусы когда мы реализуем его на практике?

II.  Сотрудничество

Читаем Agile-манифест дальше: 

На протяжении всего проекта разработчики и представители бизнеса должны  ежедневно работать вместе.

И

Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как представителей бизнеса с командой, так и внутри команды.

Что из этого следует?
Мероприятия Agile: Stand-Up совещания и Демонстрации
Инструменты: Канбан-доски (кому интересно про Канбан — см. мою статью Канбан в условиях российской действительности)

Мы успели рассмотреть только три принципа из 12. Продолжение разбора принципов Agile-манифеста следует в дальнейших статьях — сегодня мы не затронули темы “Частота и ритмичность”, “Ценный продукт”, “Главное — это люди”, “Как работать лучше”… 
 

Подключайтесь к дискуссии — пишите в комментариях — по вашему опыту применения — в чем сильные/слабые стороны и подводные камни инструментов/мероприятий Agile?
 

Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах 

Продолжение: Agile в проектах 1С: где-то между невозможно и неизбежно. Часть вторая.