Почему, когда команды переходят на Scrum, короткие циклы планирования и реализации часто воспринимаются ими как что-то враждебное, хотя должно быть наоборот — люди исторически учились действовать небольшими шагами, пробуя, ошибаясь и корректируя свои шаги.
Не сложно представить, как работал мастер, который точил каменное оружие — он обрабатывал заготовку, смотрел, что получилось, потом продолжал вытачивать, корректируя форму. И так шаг за шагом он придавал заготовке нужную форму — такую, чтобы инструмент удобно лежал в руке и хорошо выполнял свою задачу. То есть каждый раз он понемногу корректировал свои действия в зависимости от результатов предыдущего удара. Это и есть итеративный подход, заложенный в методике Scrum, просто на очень примитивном уровне.
Итеративное мышление в науке
В 1620 году английский философ Фрэнсис Бэкон в своей работе «Новый Органон» выступил против старого метода познания,
будто бы истина уже известна, а наша задача — лишь обосновать её.
Бэкон предложил сначала собирать факты, наблюдать, как объект ведёт себя в разных условиях, и проводить опыты — а только потом делать обобщения. Именно Бэкон одним из первых сформулировал идею итеративного подхода. Он показал, что:
Путь от гипотезы к выводу похож на цикл — сначала мы собираем факты, потом делаем выводы, проверяем их на практике, пересматриваем, и так по кругу.
Делить процесс на небольшие шаги — это вполне естественный способ понимать и улучшать мир вокруг.
Повторяющиеся циклы в производстве
Спустя несколько столетий тот же цикл — сначала собирать данные, наблюдать, потом делать выводы и вносить корректировки — начинает применяться не только к познанию, но и к реальным процессам в промышленности.
В 1939 году инженер и статистик Уолтер Шухарт предложил посмотреть на производство не как на линейную цепочку действий, а как на повторяющийся цикл, где каждый новый виток — это возможность для улучшения. Его идею подхватил и развил Эдвардс Деминг, его ученик.
После Второй мировой Деминг привёз в Японию цикл своего учителя и представил его как «колесо Деминга» — «проектируй — производи — продавай — испытывай в эксплуатации». Но японские инженеры обобщили эту схему до дошедшего до нас PDCA — «планируй — делай — проверяй — адаптируйся», сделав цикл пригодным для любой деятельности, а не только для разработки продукта. И объединили её с философией kaizen («кай – изменение», zen – к лучшему) — идеей, что настоящие улучшения происходят через небольшие, но постоянные изменения в работе. Именно эти принципы впоследствии станут основой методологии Lean.
Позднее Деминг переосмыслит колесо и оформит его в виде цикла PDSA, где заменит «изучай» на «проверяй», и подчеркнёт, что надо не просто проверять, а извлекать уроки.
Инкрементальный подход в написании кода
Идея разбивать работу на короткие циклы постепенно проникла и в программирование. Писать код по частям и сразу проверять небольшие участки стали ещё в 60-х, когда компьютеры занимали целые залы, а код загружали не с флешек, а с перфокарт. Одна карта — одна строка кода. Когда колода из сотен карточек была готова, программист вставал в очередь к считывателю, но иногда ждать результата компиляции приходилось часами. Могло случиться так, что из 300 карт опечатка была на 289-й, и это означало, что нужно её вытащить, сделать новую, снова вставить всю колоду и ждать ещё несколько часов.
Поэтому программисты стали делить свои стопки на небольшие колоды по 30-40 штук — чтобы сначала прогнать одну небольшую часть, убедиться, что она работает, а потом уже добавлять следующую. Так постепенно собиралась вся программа.
Тогда никто не называл этот подход итерациями или инкрементальной сборкой (incremental build), при которой пересобирается только то, что изменилось, а не вся кодовая база. Но когда одна ошибка могла стоить человеку целого вечера, естественно было идти маленькими шагами, каждый раз убеждаясь, что сборка работает.
Почему нам до сих пор непривычно думать, что любой проект можно делать частями, а не целиком
За тысячи лет управления проектами мы привыкли думать, что наличие плана гарантирует контроль над рисками. Подход к работе, когда мы сначала прописываем требования и шаги, а потом начинаем делать, — льстит нашему внутреннему желанию всё заранее знать и помогает объяснить заказчикам, что происходит.
А итеративный подход сразу признаёт, что неопределённость — это нормально. И именно это многих пугает. Ведь если мы соглашаемся, что ситуация может меняться каждую неделю, значит мы признаём собственную уязвимость. Но на самом деле итеративный подход также, как в целом и Agile, снижает цену ошибки.
Новая, незнакомая модель всегда пугает сильнее, чем привычные, пусть и давно известные проблемы старой. А если добавить к этому страх показать сырой промежуточный результат — ведь вдруг начнут критиковать, — то команда до последнего будет оттягивать момент и стараться допилить фичу, вместо того чтобы показать её пораньше и понять, что на самом деле нужно было исправить.
Scrum может повысить шансы на успешное завершение проекта и помочь быстрее поставлять работающее решение. Это работает при одном важном условии — если организация поддерживает короткие итерации, и технически, и организационно. Но когда выясняется, что Scrum не устраняет проблемы, а делает их видимыми, у руководства возникает ощущение, что их обманули. И тогда всё может вернуться к традиционной модели управления, где, по крайней мере, все недостатки можно было скрыть в отчётах.
Но, как показывает история, от камня до кода, мы постепенно приходили к одной простой мысли — сложные задачи проще и безопаснее решать поэтапно. На тренинге Certified Agile Professional мы учим, как можно применить итеративный подход в вашем проекте и как использовать для этого Scrum-фреймворк.
Интересно узнать подробнее?
Приходите на один из наших тренингов, где вы в деталях разберете эту тему и сможете задать тренеру свои вопросы.
