Thursday, 6 March 2014

Доказательный Менеджмент



Перевод оригинального блог-поста Кена Швабера.

Scrum.org and Controlchaos.com
* Co-creator of Scrum
* Signatory of the Agile Manifesto
* Founder of the Scrum Alliance and the Certified Scrum Master program
* Founder of Scrum.org


Очень многие клиенты спрашивают меня, хорошо ли у них идут дела, насколько они стали лучше работать, чем год назад. Выход на рынок SAFe, IPO Ралли  и наводнение рынка "just in time" экспертами и тренинговыми компаниями делают ответ на этот вопрос еще более важным. Если организации продолжат инвестировать значительные средства в так называемые "серебрянные пули", то доверие к Аджайлу оказывается под ударом.

Wednesday, 5 March 2014

3 Шага к Эффективной Ретроспективе


Перевод оригинального гайда 3 Steps to Effective Retrospective Джеффа Сазерленда.


ОБНОВЛЕНИЕ ВАШЕЙ РЕТРОСПЕКТИВЫ 

Скрам - простой фреймворк, который состоит из определенных Ролей, Артефактов и Событий. Скрам команды часто используют Ежедневный Скрам, Планирование Спринта и Обзор Спринта, но когда дело доходит до Ретроспективы, то у многих часто возникает вопрос -  а зачем это нужно? Что получит команда от Ретроспективы? Возможно, Ваша Ретроспектива стала неэффективной, поверхностной или скучной. Вместо того, чтобы оставить эту практику, обновите ее. И вот почему.

ПОЧЕМУ РЕСТРОСПЕКТИВА ТАК ВАЖНА?

Как?

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

Кто украл мой Скрам?


Перевод оригинального блог поста Эдвина Дандо.

Наверное, вы слышали об этой статистике – команды Джеффа Сазерленда стабильно получают 500%-700% увеличение в производительности. Огранизации, с которыми он работает, утраивают продуктивность в считанные месяцы. Итак, вы внедрили Скрам. Почему же у вас нет подобной  продуктивности? Кто украл ваш Скрам и вашу продуктивность?

Когда вы работаете с высокопроизводительной Аджайл командой, то замечаете, что происходят, на первый взгляд, незаметные, но глубокие по своей сути изменения. Вы замечаете в первую очередь не то как команда четко придерживается правил фреймворка, с которым работает, а то как она фокусируется на том, чтобы доставить бизнес ценность. В своей практике я встречал два ключевых патерна:
  1.  Команда фокусируется на том, чтобы доставлять бизнес ценность.
  2.  Команда делает это с использованием высококачественных инженерных практик.

Давайте подробнее поговорим об этом.

Что будет после Скрама?


Перевод оригинального поста Кена Швабера.

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



Заходим на посадку - жизнь и смерть Пользовательской Истории


Перевод оригинального поста Чарльза Бредли

Пользовательские Истории НЕ являются частью Скрама. Они являются лишь одной из возможных техник (User CasesProse requirements, Test Scenarios и т.д.) для описания Элементов Беклога Продукта (PBI).

Ниже я привожу диаграмму, которую создал для иллюстрации возможного жизненного цикла Пользовательской Истории. Эта диаграмма также хорошо демонстрирует связь с горизонтами Аджайл Планирования.

Метафора самолета, заходящего на посадку, хорошо показывает эту связь. На самом верхнем уровне вы едва можете разглядеть аэропорт из иллюминатора, а в конце пути вы приземляетесь и самолет останавливается. Пользовательская История готова, Автоматизированные Приемочные Тесты пройдены.  Все метафоры становятся вдруг непригодными в один момент, поэтому я прошу вас не трактовать «смерть и легаси» уровень как смерть экипажа самолета со всеми пассажирами на его борту. Здесь уместнее говорить о том, что жизненный цикл Пользовательской Истории окончен и она умирает.

Худшая практика Ревью - прием функционала Владельцем Продукта


Перевод оригинального поста Чарльза Бредли (PST)


Одна из самых худших практик, которые я часто наблюдаю в Скрам командах во время Ревью Спринта – использование этой встречи в качестве официальной приемки (sign-off) функционала Владельцем Продукта. Получение обратной связи и подтверждения от Владельца Продукта, конечно же, необходимо. Но считать именно Ревью (многие ошибочно называют эту встречу «Демо») встречей, на которой это должно происходит, является большим заблуждением.
Давайте посмотрим на эту «худшую практику» под следующими углами:
  • Возможные симптомы
  • Возможные причины
  • Возможные последствия
  • Возможные решения

Скрам Фреймворк и Шахматы



Перевод оригинального поста Кена Швабера (2010).



Сейчас много говорят о «Scrum Guide»,  который мы написали в соавторстве с Джеффом Сазерлендом. Каждый может скачать этот документ в формате PDF. В нем содержится четкое описание того, что такое Скрам.
В мире появляется много версий Скрама. Я хотел бы четко высказать свою позицию по этому вопросу.
Я часто говорил о том, что Скрам является лишь Фреймворком. С помощью этого Фреймворка, созданного мной и Джеффом, вы можете создавать сложные комплексные (complex) продукты. Если фреймворк использовать должным образом, то продукт будет иметь высокое качество и продуктивность. Он будет радовать как разработчиков, так и заказчиков.