Для чего мы нарезаем крупные пользовательские истории на более мелкие? С виду может показаться, что мы выполняем лишнюю и никому не нужную работу, но так ли это? В этой статье я постараюсь дать ответ на этот в одном из множества контекстов — контексте ценности, поставляемой клиенту и бизнесу.
Browse Category
Agile
Метафора системы и архитектура
У архитектуры множество определений. Одно из наиболее емких — представление о компонентах системы и их взаимосвязях между собой. В качестве компонентов могут выступать как достаточно крупные куски системы, например, интернет-банк, мобильный банк, смс-банк, процессинг, так и более мелкие, — компонент по работе с карточными лимитами, модуль конвертации валют, компонент уведомлений.
Разработчикам, явно или неявно, приходится проводить анализ архитектуры для того, чтобы понять, в каком месте системы необходимо добавить новую функциональность, с чем будем взаимодействовать новый компонент или на работу каких компонентов может повлиять тот, в который мы вынуждены внести изменения.
Водопадный подход максимально пытался обеспечить целостность архитектуры за счет BDUF/BRUF (Big Design Upfront/Big Requirement Upfront). Это были два грандиозных по своим масштабам этапа — сбор требований и проектирование, плавно перетекающее в детальный дизайн. Выхлопом этапов были железобетонные требования и нерушимый, крепкий как скала дизайн.
В Agile все несколько иначе — мы работаем короткими итерациями, каждая из которых включает в себя и уточнение требований и дизайн и тестирование. BDUF/BRUF не подходит ни под каким углом.
Как же при таком подходе обеспечить целостность архитектуры системы?
«Неработающий Agile»
Навеяно множественными утверждениями «[У нас] 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). В этом сочетаются простота и красота подхода: оставлять только то, что эффективно и очень быстро, пока оно еще не успело дать корни, избавляться от всего лишнего и мешающего выпускать действительно классные продукты!
Цикл Деминга, Scrum и Toyota Production System
Нередко про цикл Деминга, Scrum и Toyota Production System рассказывают дискретно, будто несколько историй в одном фильме под эгидой одной идеи. И как они между собой связаны — не всем и не всегда очевидно.
Выгдядит это примерно так. Долгий рассказ о PDCA. Затем долгий рассказ о Тойоте и MURI, MURA, MUDA. После чего долгий рассказ про скрам: плаирование, спринты, ретро и т.д.