В первой части статьи Agile в ИТ-проектах: где-то между невозможно и неизбежно мы поговорили про Готовность к изменениям и Сотрудничество.
Здесь мы рассмотрим оставшиеся принципы и ценности Agile, которые следуют из Agile-манифеста:
- MVP - минимальный ценный продукт
- Частота и ритмичность
- Главное - это люди
- Думаем, как работать лучше
Ну, а тем, кому интересно подробнее пообщаться про практику внедрения Agile в проектах автоматизации - напоминаю, что на следующей неделе пройдет первый вебинар Продвинутого курса по управлению ИТ-проектами по гибким методологиям (Agile), подключайтесь!
III. MVP - минимальный ценный продукт
Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
Работающий продукт — основной показатель прогресса.
Простота — искусство минимизации лишней работы — крайне необходима.
Что из этого следует на практике?
В первую очередь - концепция MVP - Minimum Viable Product/Minimum Valuable Product. То есть, если переводить буквально, минимальный жизнеспособный продукт, или же минимальный продукт, обладающий ценностью. Тот самый принцип, который в проектном управлении звучит как “Дельфины вместо китов , салаки вместо дельфинов, головастики вместо салак и т. п.”
Что имеется в виду? Все внедрение мы дробим на небольшие кусочки, и реализуем их по отдельности. Если мы можем внедрить какой-то функциональный блок и запустить его в опытную эксплуатацию - мы это сразу и делаем, а не ждем, когда будет готово все, чтобы перейти на новую систему “включением рубильника”.
Плюсы:
- MVP - снижает риски!!!
- Повышает уверенность, что делаем то, что надо
- Позволяет вежливо отсечь требования заинтересованных сторон, которых нельзя явно послать, но можно отложить на конец под лозунгом “либо шах сдохнет, либо ишак…”
- Уменьшает затраты на ненужные доработки
- Призывает оценивать, “а правда ли нам нужен этот функционал” не в последний момент, а своевременно.
Минусы:
- Не всегда технически возможно. Скажем, MVP для создания ERP-системы может делаться по сути чуть ли не год. До этого реально нужного работающего продукта фактически не будет... Обходным решением будет выстраивание временной интеграции с действующими решениями, далее см. следующий пункт.
- Увеличивает объем работ (иногда незначительно, иногда сильно - если нужно интегрировать с другими решениями, которые после финального решения уже отпадут (особенно это чувствуется, когда на предприятии лоскутная автоматизация)
- С позиции подрядчика - выше риски, что не продлят контракт после первых функциональных блоков (жалуются франчайзи, работающие по 1С:Технологии быстрого результата: договаривались предварительно на один объем работ, а на деле - после первых нескольких кусочков заказчик говорит, что ему хватит, и контракт не продляет)
- "Нет ничего более постоянного, чем временное" - сделанное временное решение, которое планировалось вскоре заменить на постоянное, в условиях реальности может по разнообразным причинам остаться в эксплуатации надолго.
- На самом деле, грамотные эксперты по Agile всегда настоятельно советуют составлять "дорожную карту продукта" - то есть понимать, что мы хотим получить на выходе и согласовывать это понимание со всеми ключевыми участниками (!). Но, опять же, когда мы смотрим на внедрения в реальности, использование принципа MVP создает соблазн "сначала делать, а потом разберемся" - с результатом соотвествующего качество. По моим ощущениям, здесь дело не в технологии, а
в прослойке между рулем и сидениемв исполнителе. Что не отменяет проблемы...
IV. Частота и ритмичность
Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
Здесь мы говорим в первую очередь про те самые спринты в Scrum, когда работа бьется на одинаковые временные промежутки (одна, две, три, четыре недели и т. п.), и в конце выдается некоторый промежуточный результат.
Плюсы:
- Спринты в Scrum мобилизуют. Люди понимают, что им в конце недели предъявлять результат, и не отвлекаются на посторонние задачи (а франчайзи не могут подписать сотрудников на несколько проектов одновременно - я вот не знаю, этот пункт записывать в плюсы или в минусы?)
- Уверенность заказчика в результате (ибо заказчик видит промежуточные результаты, и понимает, что работа идет)
Минусы:
- На практике автоматизаторы, работающие по Scrum жалуются, что много остается недоделок по итогам спринта. Вообще, попытка уместить каждый логический кусочек в определенный равный временной промежуток заставляет вспомнить анекдот:
- Я изобрел универсальный автомат для стрижки головы: человек засовывает туда голову, и его стригут и бреют...
- Но ведь у всех головы разного размера!
- Первый раз - да...
- Еще одна проблема встречающаяся на практике - это жалобы от членов команды про постоянный стресс. Ибо работать в условиях постоянного дедлайна тяжело :-(((. Некоторые команды даже специально начинают следующий спринт не сразу после окончания предыдущего, а через некоторый промежуток. Чтобы можно было выдохнуть.
- Еще многие заинтересованные стороны и представители менеджмента жалуются, что ограничение “внутрь спринта нельзя добавлять задачи” очень мешает на практике, и вообще выглядит искусственно…
Поэтому честно предупреждаю: попробовав Scrum в чистом виде по моему опыту многие переходят на более гибкие в плане графика фреймворки (например, Канбан или Скрамбан).
V. Главное - это люди
Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
Самоуправление - что из этого следует?
- Выше планка по набору команды проекта (и меньше завязано непосредственно на личность РП)
- Больше уважения к решениям команды (даже когда они противоречат желаниям руководства)
Вопрос, при каких условиях возможна ли самоорганизация в реальности я уже разбирала в статье “Сами с усами”. Не буду здесь повторяться, но, на всякий случай, еще раз озвучу, чего в рамках самоуправления делать не нужно:
- Не нужно делегировать команде принятие решения, что нужно делать. Это привилегия бизнес-заказчика, менеджмента и т. п.
- Не нужно поощрять некомпетентность, лень и привычку садиться окружающим на шею. Даже под лозунгом “но мы же команда”
- Не нужно внедрять самоуправление сходу, методом забрасывания не умеющих плавать на глубину - нужно постепенно растить и готовить
- Не нужно ждать, что “вот, когда-нибудь у нас будет крутая команда, и тогда мы будем работать по Agile” - мысль соблазнительная, но так бывает только в идеальном мире, а в реальном - стоит работать с той командой, которую дали, при необходимости ее развивая и направляя.
VI. Думаем, как работать лучше
Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Что из этого следует?
- Ретроспективы - периодические встречи для обсуждения, с какими проблемами мы сталкиваемся, и что можно сделать лучше
- Хорошая морская практика - в смысле, стиль разработки сразу направленный на дальнейшее удобство использования (См. статью про Ректальное программирование на Инфостарте - это хорошая инструкция "как делать не надо".)
Резюме - работа по гибким методам расширяет возможности команды, но продолжаю настаивать, что это никоим образом не панацея.
Поделитесь вашей точкой зрения - какие принципы и инструменты применяете, в чем их плюсы и минусы?
Автор статьи: Мария Темчина. Ведущий Курсов по управлению ИТ-проектами на Инфостарте от "Базового до Продвинутого".
Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах
