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

В первой части статьи 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. Думаем, как работать лучше

Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

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

Что из этого следует?
 

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

Резюме — работа по гибким методам расширяет возможности команды, но продолжаю настаивать, что это никоим образом не панацея. 

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

Автор статьи: Мария Темчина. Ведущий Курсов по управлению ИТ-проектами на Инфостарте от "Базового до Продвинутого".

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