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

Публикация № 1119056

Методология - Управление проектом

16
Некоторое время назад я публиковала статью, где начала разбираться, что следует из Agile-манифеста на практике, и каковы сильные и слабые стороны происходящего. В одну статью всё не поместилось, и сегодня попробую закончить эту тему. 

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

 

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

 

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

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

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

 

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

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

 

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

16

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. Yashazz 2522 06.09.19 18:26 Сейчас в теме
а знаете, что самое забавное? Такую писанину я, практически интуитивно, накатал 15 лет назад в качестве манифеста принципов работы айти-1С-отдела моей тогдашней фирмы.
Вот ровно те же фразы, формулировки и принципы.

Я гений? Нет. Просто всё изложенное - банальщина. Но когда её подают красивые бизнес-вруны под глянцевым вип-рекламным-соусом, то пипл хавает.

Возьмите любую фразу, например: "Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта." - это что, откровение свыше? Да это ещё древние ассирийцы и египтяне знали. Но в этом и суть психологически грамотно построенного охмурёжа от всяких коучей, эйджилоносцев и прочей швали. Пара очевидных, умно звучащих банальностей, немножко НЛП, бац-бац, и вам уже втюхали бессмысленный и бесполезный, зато дорогущий, "продукт".

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

Аж противно. Понимаю, что деньги не пахнут, но видеть это на ИС - противно.
Diversus; user1274438; mrdc; Yakud3a; EliasShy; Summer_13; leonidt84; rpgshnik; +8 1 Ответить
2. MariaTemchina 826 07.09.19 16:17 Сейчас в теме
(1) Яков, я не устаю повторять, что авторы Agile манифеста не открыли Америку.
Эти или сходные принципы активно используются многими командами довольно давно. Я очень рада, им если команда интуитивно работает разумно, и это ей помогает делать проекты.
В чём же тогда заслуга авторов манифеста и создателей разных Agile фреймворков? В том, что создаётся именно технология, которую можно перенимать и использовать для решения возникающих проблем.
Суть в том, что как вы правильно пишете, эти принципы - работают. Ну, а то что кто-то продает красивые слова в блестящей обёртке за неразумные деньги - это, простите, не недостаток технологии, а нюансы реализации...
7. itriot11 71 11.09.19 12:20 Сейчас в теме
(1)
в качестве манифеста принципов работы айти-1С-отдела моей тогдашней фирмы

Я правильно понимаю, что речь идет о работе в качестве фикси? В таком случае, соглашусь, что некоторые ключевые принципы могут выкристаллизовываются самостоятельно. Другая ситуация обстоит при использовании внешних исполнителей. Обычно их процесс взаимодействия с заказчиком похож на некоторое подобие классических подходов к управлению проектами, что далеко, на мой взгляд, не всегда уместно.
8. MariaTemchina 826 11.09.19 15:46 Сейчас в теме
(7)
Другая ситуация обстоит при использовании внешних исполнителей. Обычно их процесс взаимодействия с заказчиком похож на некоторое подобие классических подходов к управлению проектами, что далеко, на мой взгляд, не всегда уместно.

По моим наблюдениям, чтобы с внешними проектами могла зайти речь про применение Agile, должно соблюдаться, как минимум два условия: во-первых, достаточно высокий уровень доверия между исполнителем и заказчиком, во-вторых, негативный опыт работы "по водопаду"...
3. Rustig 1189 09.09.19 09:52 Сейчас в теме
(0) спасибо за статью!
есть понимание, в чем кроется проблема внедрения ПО 1С, например, возьму 1С:Документооборот 8.
В системе Заказчик - Исполнитель появляется третий невидимый "игрок" - разработчик программы. Заказчик говорит, вот в рекламной листовке есть мобильная программа ДО, компания-разработчик декларирует что эта функциональность имеется. В итоге на внедрении выясняется, что не удобно работать в мобильной версии, и что надо дорабатывать.
И если Исполнитель не знает заранее по сути "чужой" программный продукт, то ни одни сроки и бюджеты не будут выполняться...
Вот, если обозначить эту проблему заранее, что продукт "чужой" и требует доработки каждой функциональности, и "Внедрение" после продажи лицензий должно сразу перейти в "Сопровождение" программного продукта, то будет легче перейти на спринты и минимальный жизнеспособный продукт.
вот такое мое мнение....
MariaTemchina; +1 Ответить
4. MariaTemchina 826 09.09.19 10:03 Сейчас в теме
(3)

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

Вообще, оговаривание возможных проблем "на берегу" всегда упрощает взаимодействие и уменьшает недопонимание. Беда только в том, что продажники в этом часто не заинтересованы - и мы имеем вилку между теми золотыми горами, которые наобещали продажники, чтобы подписать контракт, и теми реальными возможностями, которые предстоит реализовывать команде внедрения, хватающейся за голову при виде того, чего же наобещали бизнес-заказчику... (в крупных компаниях эта проблема иногда встает и при внутренних проектах, не только при внешних).
5. user1274438 09.09.19 11:17 Сейчас в теме
Неужто никто анекдот про стадо коров, овцу и догоняшки еще не постил? Эх инфостарт уже не торт...
6. MariaTemchina 826 09.09.19 11:17 Сейчас в теме
(5) Его к одной из предыдущих статей запостили в комментариях. Жизненно, да...
Оставьте свое сообщение