Browse Tag

Agile

Зачем нарезать пользовательские истории?

Для чего мы нарезаем крупные пользовательские истории на более мелкие? С виду может показаться, что мы выполняем лишнюю и никому не нужную работу, но так ли это? В этой статье я постараюсь дать ответ на этот в одном из множества контекстов — контексте ценности, поставляемой клиенту и бизнесу.

Keep Reading

Share

«Неработающий 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.

Какие практики и какой процесс использовать — зависит от целей, принципов и контекста. Как они будут развиваться, что оставить, а что убрать — зависит от новых знаний, получаемых от потребителей продукта, командами в процессе рефлексии, компанией через анализ собственных показателей.

screen-shot-2016-09-14-at-11-59-32

В настоящий момент существует великое множество проверенных временем практик и инструментов: Impact Mapping, Story Mapping, C4, Specification By Example, Behaviour-Driven Development, ….
Равно как и подходов, в которые эти практики органично встраиваются, например Scrum, KanbanSAFe, LeSS.

 

XP Practices

 И что это значит?

Это означает, что Agile не может работать или не работать. Это набор ценностей и принципов. Они просто есть. А дальше компания, руководствуясь ценностями, принципами и контекстом выстраивает собственную модель или берет существующую, которую вполне может адаптировать под себя.

После чего подбирает практики и связывает их через процессы. При этом компания как живой организм — постоянно развивается и ищет пути повышения своей эффективности через процесс непрерывного обучения (цикл PDCA).  В этом сочетаются простота и красота подхода: оставлять только то, что эффективно и очень быстро, пока оно еще не успело дать корни, избавляться от всего лишнего и мешающего выпускать действительно классные продукты!

Share

Цикл Деминга, Scrum и Toyota Production System

Нередко про цикл Деминга, Scrum и Toyota Production System рассказывают дискретно, будто несколько историй в одном фильме под эгидой одной идеи. И как они между собой связаны — не всем и не всегда очевидно.

Выгдядит это примерно так. Долгий рассказ о PDCA. Затем долгий рассказ о Тойоте и MURI, MURA, MUDA. После чего долгий рассказ про скрам: плаирование, спринты, ретро и т.д.

Попробуем разобраться, как эти три модели между собой соотносятся.
Keep Reading

Share