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

06.09.19

Управление проектом - Agile

Некоторое время назад я публиковала статью, где начала разбираться, что следует из 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. Думаем, как работать лучше

 

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

 

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

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

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

 

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

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

 

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

 

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

См. также

Разработка в 1С [Часть 1 - Agile]

Agile Бесплатно (free)

В статье рассмотрены практики, применяемые при разработке по методологии Agile.

13.05.2024    3086    0    Dimbayyyy    9    

10

Радио "Аналитик", 17 выпуск 2 сезона. Про модель Кеневин с Андреем Путиным

Лидерство Личная эффективность Agile Анализ потребностей и поиск решений Бесплатно (free)

В семнадцатом выпуске второго сезона подкаста Радио “Аналитик“ обсудили, что из себя представляет модель Кеневин, чем и в каких ситуациях она может быть полезна тем, кто работает в сфере ИТ и не только.

19.04.2024    512    0    Radio_Analyst    0    

5

Проекты 1С по Scrum глазами Scrum-мастера

Agile Бесплатно (free)

Agile в ИТ встречается все чаще, и об адаптации гибких технологий под проекты 1С задумываются многие. Расскажем о ключевых инструментах и точках приложения усилий для успешного внедрения Scrum при разработке в 1С.

28.07.2023    2444    0    olegminkov    4    

7

Календарь Agile на 2024 год

Agile Руководитель проекта Россия Бесплатно (free)

Продукт команды №7, 6 поток (курс Марии Темчиной «Управление ИТ-проектами. Agile. Практический курс Agile-лидера»)

13.06.2023    1462    8    dimbasbear    1    

2

Формула успешного внедрения DevOps и Agile в 1С: от неудачи к неудаче без потери энтузиазма

Agile Бесплатно (free)

На конференции Infostart Event 2021 Post-Apocalypse выступил директор практики БИТ:ERP компании Первый БИТ Глеб Стальной. В ходе доклада он рассмотрел трансформацию проектного подхода в продуктовый, рассказал про имплементацию «современных» практик DevOps и продемонстрировал инструменты для разработки, взаимодействия с бизнесом и клиентами, применяемые в его команде.

27.02.2023    2499    0    glebushka    2    

13

Бывает ли Agile в проектах 1С?

Agile Бизнес-аналитик Руководитель проекта Бесплатно (free)

Это один из вопросов, которые мне задают довольно часто. Ну да, Эджайл, Скрам, технологии, методологии,  красивые слова. Но где вы видели это в реальности в 1С внедрениях????

06.12.2021    4270    0    MariaTemchina    49    

13

Самые честные истории про внедрение Agile на практике

Agile Бесплатно (free)

Есть сообщество в Facebook'е и Инстаграм, которое публикует жизненные комиксы про внедрение гибких технологий на практике - Comic Agile.

01.04.2021    3817    0    MariaTemchina    18    

16

Пришиваем хвост: нужен ли Эджайл в 1С или глупости это всё?..

Agile Руководитель проекта Бесплатно (free)

Коллеги, приглашаем поучаствовать в опросе - Agile в проектах внедрения 1С: реально работает или это миф? Интересен практический опыт!..

12.03.2021    8423    0    MariaTemchina    86    

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

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

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

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

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

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

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

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

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

Причем это такая область знаний и умений, которую нельзя до конца осмыслить логически, многие вещи приходят только из опыта. Здесь как нельзя кстати подходит фраза что "для приобретения навыка теоретических знаний недостаточно, необходима уверенность происходящая из собственного опыта".

Хотите чтобы у вас заработали эти супер техники? Тогда включите фанатизм, хотя бы на несколько спринтов. Сделайте несколько спринтов соблюдая все правила с особым фанатизмом... и увидите результат. Настоящий результат.
10. MariaTemchina 1618 27.04.20 14:50 Сейчас в теме
(9)
Признать что что-то надо делать и начать это делать, это огромная разница.

Плюс сто! Мы очень часто прекрасно понимаем, что нужно делать, но...
11. пользователь 24.06.20 12:08
Сообщение было скрыто модератором.
...
Оставьте свое сообщение