Давно хотел написать на эту тему, но все случая как-то не было, а тут в Тбилиси дождь, нам нужно собирать чемоданы, чтобы завтра выдвинуться к Казбеку, ну и маленький спор в FB с бокалом саперави сделали свое дело.
В FB вышел примерно такой диалог:
Я: в современном мире гибкие методологии стали стандартом де-факто.
Петя: мы живем без этого вашего скрама и нам зашибись.
Когда речь заходит про улучшение процессов, обычно стоит задать себе вопрос «А нахрена?» или «А что вообще улучшать-то будем?». Разумных ответов на эти вопросов может быть много, неразумных еще больше, но в целом выделяют три основных направления:
- Клиентский опыт
- Производительность
- Время реакции(время от запроса до результата)
И четыре дополнительных:
- Мотивация
- Качество
- Предсказуемость
- Прозрачность
Scrum это такая штука, когда вы из коробки получаете контролируемое и настраиваемое время реакции вкупе с предсказуемостью и прозрачностью, но скорее всего теряете в производительности. Для производительности нужны четко выверенные конвейерные процессы.
Поэтому, если вы точно знаете, что хотите получить на выходе, вам не важно это получить как можно скорее, но важно максимально эффективно использовать имеющиеся ресурсы, то Scrum скорее всего не для вас.
Почему же я тогда пишу, что гибкие методологии стали стандартом де-факто? Для этого есть две причины.
Первая заключается в том, что если вам кажется, что вы точно знаете, что вам нужно на выходе, то скорее всего вы попали под эффект Даннинга — Крюгера, а это значит, что на выходе вы получите никому не нужное говно, вас выкинет с рынка, и в целом для индустрии вы не интересны.
Вторая же причина в том, что я писал не про Scrum, а про более широкое понятие гибких методологий. Действительно, бывают ситуации, когда продуктивность или клиентский опыт важнее времени реакции. И вы этих случаях Scrum будет неуместным. Но в арсенале гибких методологий есть инструменты подходящие и для таких ситуаций. Мало кто сможет упрекнуть Toyota в низкой продуктивности, а ведь Toyota Production System лежит в основе многих инструментов мира Agile. Идеи Lean и Kanban позволяет выстраивать очень эффективные и прозрачные конвейерные процессы.
Поэтому, Петя конечно же прав. Существует множество ситуаций в которых Scrum не то что не применим, но и просто вреден. Но Agile… Agile он совсем про другое. Лучшее всего мне кажется идею Agile удалось раскрыть Юре Куприянов поэтому я просто завершу пост его цитатой:
Agile — это про честность. Честность и смелость.По следам продолжающихся обсуждений выступления Грефа, сформулировал для себя следующее понимание. Возможно, несколько пафосное, но это важный пафос.Подход agile — когда он внедрен на уровне ценностей, а не как карго-культ или “еще один вариант процесса разработки” — требует от всех участников признаться и признать несколько крайне неприятных вещей. Заказчику – что он не знает в точности и в деталях, какой результат его устроит. Менеджерам — что они не знают, сколько времени потребует реализация. Всем — что никакая документация не может быть полной и исчерпывающей на сколь-нибудь протяженном отрезке времени. Что никто и никогда в реальной жизни не гарантирует полное отсутствие ошибок в коде и сбоев в инфраструктуре.Это очень страшно — признаться в том, что толком мы ничего не знаем и ничего не можем гарантировать на 100%. Это против нашего самомнения и нашей культуры. Это не то, что хотел бы услышать наш руководитель или наш заказчик. Но именно признание проблемы — это шаг к решению. Кто не признает — тот продолжает обманывать себя. Чем дольше длится проект, чем больше людей в нем задействовано — тем больше возможностей отыскать причины и оправдания для любых задержек, ошибок и неудач. Только не дать усомниться в своем абсолютном знании!Agile — это про то, как посмотреть в лицо реальности, и не сойти с ума. Сказать себе — ок, я признаю, что все обстоит именно так. Что мы можем с этим сделать? И тогда выясняется, что — можем. Что можно не знать, сколько времени понадобится — но давать предсказуемый результат. Делать сотни и тысячи изменений в продакшене в день — и не обрушивать всю систему. Не вести документацию по ГОСТу — но эффективно обмениваться знаниями внутри и между командами.Главное — не б-бояться.
