К основному контенту

Взгляд сквозь линзу Agile

Автор: Браян Барр (Brian Barr)
Переведено с английского проектом Agile Translations 


Существует множество заблуждений о том, что означает Agile. Вот несколько из наиболее распространенных мнений:

  • Agile является методологией разработки. Вообще-то, это не совсем так, но есть группа методов, которые можно отнести к Agile-методологиям (гибким методологиям). 
  • Agile – это то же самое, что и Скрам. Это не одно и то же. Scrum является одним из самых известных и широко используемых. Agile подходов. Однако существуют и другие подходы, которые также считаются Agile.
  • Agile – открытый путь разработки ПО. Это самое глубокое заблуждение. Когда Agile применяется правильно, он становится основой самой дисциплинированной практики разработки программного обеспечения из всех существующих.

Итак, что же такое Agile?

Когда вы рассматриваете процесс разработки или фреймворк для поставки ПО, думаете о расстановке приоритетов для нужд бизнеса, о том, как построить привлекательный продукт, как организовать его выпуски, как создать и мотивировать команды или финансировать инициативы, просто посмотрите на все это через линзу Agile. И тогда решения и действия, которые вы предпримите, будут направлены на создание максимальной бизнес-ценности.



Давайте рассмотрим несколько примеров так, будто мы на приеме у окулиста. Вспомните, как окулист переставляет разные линзы и неоднократно спрашивает: "С или без?"

Пример № 1: Новая версия продукта выпущена, но важное требование не было включено.
  • Без линзы Agile: Вы тщательно анализируете весь жизненный цикл разработки ПО; определяете каждый случай, где требования могли быть не должным образом задокументированы, реализованы или протестированы. И добавляете многошаговый процесс проверки, чтобы трижды убедиться, что каждое требование отслеживается.
  • С линзой Agile: Вы проводите ретроспективу релиза с командой и принимаете решение, что вам нужны более частые встречи между бизнесом и ИТ-командами во время спринта. Теперь вся команда, бизнес и ИТ, заинтересованы реализовать продукт таким, как задумывалось.

Agile-линзы позволяют увидеть, что принцип "сотрудничество с клиентами приоритетней контрактных переговоров" (Agile-манифест) является более верным для создания бизнес-ценности.

Пример № 2: За четыре недели до запланированного релиза появляется новое, относительно небольшое требование.
  • Без Agile-линзы: Соберется комитет управления изменениями, чтобы рассмотреть новое требование и определить, следует ли задержать релиз или продолжить его, не включая новое требование. Учитывая все последствия на столь поздней стадии цикла выпуска, никто не знает, как успеть реализовать это новое требование до релиза.
  • С Agile-линзой: Владелец Продукта и команда встретятся с клиентом, чтобы рассмотреть новое требование. Потом быстро разработают Пользовательскую Историю с соответствующими приемочными критериями. Эта история оценивается и принимается в следующий спринт (потому что это относительно небольшое изменение), который начинается через несколько дней. Команда готова к новым изменениям и постоянно работает, чтобы сделать бизнес успешным.

Agile-линза позволяет увидеть, что принцип “реагирование на изменения важнее, чем следование плану” (Agile Manifesto) является более правильным для создания бизнес-ценности.

Пример № 3: Сейчас апрель, и отдел маркетинга хочет знать, какая функциональность будет готова к релизу поздней осенью (т.е. через 6 месяцев).

  • Без линзы Agile: Команда сделает детальный анализ всей функциональности, которая запланирована на этот релиз, пытаясь понять, что может быть в него включено. Ранее команда уже обещала сделать слишком много и обожглась. Следовательно, чтобы обезопасить себя от еще одного провала, люди запланируют меньше, чем реально могли бы сделать. И так как задач запланировано меньше, время будет заполнено маловажными вещами, хотя можно было бы активно работать, чтобы сделать больше. Скорость разработки будет увеличиваться по мере приближения релиза.
  • С Agile-линзой: Команда плотно поработает с маркетингом и объяснит, почему небольшие последовательные релизы позволят раньше получить некоторую функциональность. Кроме того, они обсудят, какие маркетинговые процессы требуют больше времени и какая функциональность критична для рынка. После этого они будут работать вместе над сокращение время разработки посредством взаимодействия, бережливого планирования и расстановки приоритетов ключевой функциональности. Команда дает прогноз о том, что они сделают за следующие две недели. Каждые две недели команда показывает маркетингу новую рабочую версию продукта. Члены команды знают, сколько они могут сделать за две недели, эффективно работая без овертаймов и работы по выходным.

Agile-линза позволяет увидеть, что “Agile-процессы стимулируют устойчивую разработку” (Принципы Agile), и это более ясный путь для создания бизнес-ценности. Поэтому когда в следующий раз вы спросите себя: “Agile ли это?”, посмотрите на ваше решение или действие через линзу Agile. Проверьте, не противоречит ли оно Agile-манифесту, Agile принципам и Lean принципам, а также сфокусировано ли оно на увеличении бизнес-ценности. На самом деле, я очень рекомендую, чтобы у каждого в вашей организации была линза Agile.


Переведено с английского проектом Agile Translations  
Дарья Ершова, Светлана Каща, Алина Проскурина, Сергей Сидоренко

Оригинальная статья: "Seeing the World Through Agile-Colored Glasses"  by Brian Barr

ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence Переведено с английского проектом Agile Translations   Хорошие Пользовательские Истории следуют INVEST модели , предложенной Биллом Вейком (Bill Wake). Они независимые ( I ndependent), обсуждаемые ( N egotiable), ценные ( V aluable), поддающиеся оценке ( E stimable), небольшие ( S mall) и тестируемые ( T estable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели. Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Все о Скрам от Майка Кона

На сегодняшний день многие уже знают основы Scrum. Однако я часто сталкиваюсь с разночтениями, и даже спорами по некоторым моментам. Поэтому считаю, что нужно обратиться к истокам. Как, наверняка, многие знают Майк Кон – один из наиболее популярных Scrum-тренеров, он работает с этой методологией более 10 лет, написал 2 концептуальные книги по практикам Agile, а также множество интересных и ценных статей, является одним из основателей Scrum-альянса и Agile-альянса. По праву его можно считать тем специалистом, определениям которого можно доверять. Читать дальше...

Скрамбан - собираем лучшее

Автор: Илья Павличенко . Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности. Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь ): « Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы

Планирование релиза: уходим от термина, но не от практики

Автор: Майк Кон (Mike Cohn) Перевод с английского. Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности. В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается. Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.

Диаграммы Ганта и Agile проекты. Так уж они несовместимы?

Автор: Алексей Кривицкий. "Планы бесполезны, планирование необходимо". Ейзенхауэр Диаграммы Ганта – это традиционный механизм визуального планирования, который получил свою популярность благодаря артефакту традиционных проектов, который назывался Work Breakdown Structure (WBS), и продуктам Microsoft Project и Microsoft Project Server, которые позволяли конструировать и хранить WBS. Пропоненты Agile принципов много внимания уделяют визуализации и открытости планирования. Так почему же так часто в контексте Agile мы слышим критику в адрес диаграмм Ганта? Давайте разберёмся. Пару слов о терминологии. В данной статье " традиционными подходами " к управлению проектами (или просто традиционными проектами) называются те подходы или проекты, которые противопоставляются Agile проектам. Я не использовал термин «водопадных проектов», так как во-первых на практике настоящих водопадных проектов не так много, а во-вторых по мимо водопадных и Agile проектов есть ещё мн