Некоторое время назад заинтересовался почему же получается так, что под видом "гибких" внедряются процессы/методы с жесткими церемониалами, от которых нельзя отходить ни на шаг. И как/почему вокруг применения "гибких" процессов образовался настоящий бизнес по продаже услуг по организации этого самого "гибкого" процесса.
Поэтому время от времени смотрю и читаю всякое на тему SCRUM и Канбан. По ходу этого занятия что-то цепляет и хочется сделать "заметку на полях". Вот решил делать эти заметки в блоге, дабы затем проще было разыскать их.
Первая вещь, которую хочется зафиксировать, это осознание того, что в Agile сам термин "agile" относится не легкости изменения процессов, правил и практик, применяемых командой разработки. А легкости и скорости прогибания в отношениях с заказчиком.
А если сказать более грубо, но более точно, то "agile" -- это про гибкость в удовлетворении заказчика.
Образно выражаясь, до появления Agile исполнитель с заказчиком договаривались, после чего исполнитель исчезал с радаров и принимался делать то, о чем договорился. А заказчик остался в одиночестве ждать, пока ему принесут результат. Время от времени заказчика кормили завтраками и ему оставалось только надеяться, что все будет хорошо.
При этом заказчик не мог просто так по ходу дела попросить "такое же, но с перламутровыми пуговицами". Сперва нужно было дождаться тех пуговиц, о которых уже договорились, а потом передоговариваться об их замене на перламутровые.
И вот в конце-концов заказчику доставляют результат и наступает одно большое удовлетворение. Или не большое. Или неудовлетворение. Но одно. И сразу.
Этого мало. А ждать этого приходится слишком долго.
И вот тут весь такой в белом Agile позволяет сделать удовлетворение растянутым во времени. Сегодня удовлетворили чуть-чуть, через неделю еще чуть-чуть, через две недели еще чуть-чуть. Клиент ощущает постоянно внимание к своей персоне.
Результаты показываются по чуть-чуть. Более того, по другому-то и нельзя. Ибо что будет в финале толком никто не знает, т.к. изначально договаривались только о том, что конкретика будет определяться по мере следования.
Так вот, поскольку конечного результата никто толком не представляет, а промежуточные результаты демонстрируются регулярно, то появляется возможность менять планы по ходу дела. Нужны перламутровые пуговицы? Да без проблем. Даже если уже успели пришить другие, то срежем и присобачим новые.
Именно это и подразумевается под "гибкостью" в Agile. Если вдруг заказчик решил, что удовлетворить его могут только перламутровые пуговицы, то мы гибко к этому приспособимся и удовлетворим заказчика по-новому.
Признаться, до сих пор я находился в заблуждении. Думал, что "гибкость" -- это именно гибкость в работе самой проектной команды. Захотели, стали проводить коллективные митинги каждый день. Захотели, свели общие митинги к одному в неделю. Захотели, сделали обязательными ежедневные коммуникации в режиме 1-к-1.
Ну а раз "гибкость" относится только к реакции на хотелки заказчика, то становится понятным, почему отход от канонического SCRUM-а объявляется ересью, предается анафеме и выжигается каленым железом.
Прошу простить мне мою отсталость в отношении Agile. В последний раз плотно с этой темой приходилось сталкиваться где-то в 2013-ом. Затем работать можно было так, как удобно, а не как модно-молодежно. Так что приход церкви святого Agile со SCRUM-ом в виде пророка остался за кадром :)
1 комментарий:
Согласен, в этом вся суть Agile. Если нужна гибкость именно самого процесса разработки, то есть OpenUP, в рамках которого можно подбирать конкретные методологии по-вкусу.
Отправить комментарий