Навеяно множественными утверждениями «[У нас] Agile не работает»
С чего все начиналось?
То, что мы сейчас называем Agile, берет своё начало в 70-е годы. Еще тогда Винстон Ройс в статье «Managing the Development of Large Software Systems» указал на необходимость циклов обратной связи между различными этапами (фазами) разработки в Waterfall-модели, попытавшись представить процесс как итеративный вместо существующего на тот момент последовательного.
В 1986-м в Harvad Business Review выходит статья «The New New Product Development Game» за авторством Hirotaka Takeuchi и Ikujiro Nonaka. Анализ, проведенный авторами показал: системы, которые для внешнего наблюдателя выглядели хаотичными, оказалась эффективными и позволяли выпускать продукты в значительно быстрее. В этой статье они впервые сравнили кросс-функциональные, активно взаимодействующие, разрабатывающие продукты от начала и до конца команды с командами Регбистов.
Настал 2001-й год. 17 признанных во всем мире профессионалов в разработке собрались, проанализировали чего у них общего, но отказались описывать это общее в виде процесса, а сформулировали четкие и понятные цели и принципы, которые, по их мнению, должны лежать в основе эффективного процесса. Так появился «Manifesto for Agile Software Development». Например, Scrum — фреймворк, который построен на этих ценностях и принципах.
Как Agile работает?
Вначале следует дать несколько определений:
- Ценности — это то, что важно для отдельных людей в организации и для организации в целом
- Принципы — некоторые правила, которыми мы руководствуемся при ежедневном принятии процессных решений
- Контекст — это совокупность свойств организации, например: «сколько людей вовлечено в работу?», «насколько рискованный проект?», «насколько быстрая реакция на изменения рынка требуется и как часто необходимо поставлять новую версию продукта?», «насколько сложна решаемая с помощью продукта проблема?», «что мы понимаем под качеством?» и так далее
- Новое знание — то, что мы узнаем на основе полученного ранее опыта и что позволяет постоянно улучшать процесс
На основе ценностей, принципов и контекста можно начинать строить процесс и внедрять конкретные практики. Если важной является возможность быстрой реакции на изменения рынка (готовность к изменениям..) и следование тому, что в принципах представлено как «technical excellence», возможно следует посмотреть в сторону практики Test-Driven Development.
Процесс объединяет практики, используемые различными ролями в компании. Практики дополняющие и усиливающие эффект друг друга. То есть позволяет большому числу людей координировать действия для достижения общей цели. Крупные компании могут посмотреть в сторону Portfolio Management.
Какие практики и какой процесс использовать — зависит от целей, принципов и контекста. Как они будут развиваться, что оставить, а что убрать — зависит от новых знаний, получаемых от потребителей продукта, командами в процессе рефлексии, компанией через анализ собственных показателей.
В настоящий момент существует великое множество проверенных временем практик и инструментов: Impact Mapping, Story Mapping, C4, Specification By Example, Behaviour-Driven Development, ….
Равно как и подходов, в которые эти практики органично встраиваются, например Scrum, Kanban, SAFe, LeSS.
И что это значит?
Это означает, что Agile не может работать или не работать. Это набор ценностей и принципов. Они просто есть. А дальше компания, руководствуясь ценностями, принципами и контекстом выстраивает собственную модель или берет существующую, которую вполне может адаптировать под себя.
После чего подбирает практики и связывает их через процессы. При этом компания как живой организм — постоянно развивается и ищет пути повышения своей эффективности через процесс непрерывного обучения (цикл PDCA). В этом сочетаются простота и красота подхода: оставлять только то, что эффективно и очень быстро, пока оно еще не успело дать корни, избавляться от всего лишнего и мешающего выпускать действительно классные продукты!
