Берегитесь, ScrumBut (СкрамНО)

Перевод (литературно-вольный) оригинальной статьи http://www.scrum.org/scrumbut

Берегитесь, ScrumBut (СкрамНО).

ScrumButs – это то, почему команды не могут в полной мере воспользоваться Scrum, чтобы решать свои проблемы и в полной мере реализовать преимущества его разработки. Роли, правила, ограничения по времени (timebox) были не просто так выдуманы, а предназначены для получения желаемых результатов и решения повторяющихся проблем. 

ScrumButs означает, что Scrum выявил проблему, но ее оказалось слишком трудно исправить.  ScrumBut изменяет и извращает Scrum (примерно так как показано на картинке :-))), скрывая назойливую, как бельмо на глазу, проблему.

ScrumBut имеет особый синтаксис: (ScrumBut) (Причина) (Решение/Оправдание)

ScrumBut Примеры:

ScrumBut	Причина	Решение/Оправдание
Мы используем Scrum, НО	Делать Daily Scrum каждый день для нас слишком накладно	DailyScrum будет только один раз в неделю
Мы используем Scrum, НО	Ретроспективы для нас пустая трата времени	Мы решили их не проводить
Мы используем Scrum, НО	Мы не можем доставить инкремент продукта за месяц	Устанавливаем спринт длиной в 6 недель
Мы используем Scrum, НО	Иногда наши менеджеры дают специальные таски	Готовые таски не всегда соответствуют Definition Of Done

Иногда организации делают краткосрочные изменения в Scrum, чтобы получить время для исправления недостатков. Например, "done" может изначально не включать регрессию и тестирование производительности, потому что автоматизация может занять несколько месяцев. В течение этого времени прозрачность ставится под угрозу, но восстанавливается в кратчайшие сроки.

Привет, Канбан!

Японский в Киеве?

Не знаю как вы, но я знаю только одну фразу на японском: "おなまえは(なんですか)", что в переводе значит "как тебя зовут". При чем тут японский и что это все значит? )) Очень просто – я поехал на тренинг по Kanban, который проводил Николай Алименков 16 июня, хотя неожиданно заболел за день до отъезда. Ночной переезд в Киев, высокая температура сделали свое дело, и я с трудом волочил ноги по утренним улицам столицы, жонглируя в голове японской фразой. Я надеялся как можно быстрее добраться до пункта назначения.

Kanban, тренинг, что я там услышал и узнал?
Прежде всего, хочу сказать, что компания собралась на удивление небольшая. Это порадовало, ведь позволило нам максимально эффективно использовать время тренинга и задать кучу вопросов Коле, поспорить, разложить все по полочкам. Также мне представилась возможность заразить меньше людей :-).

Что нового я узнал?
            Хочу остановиться на двух основных для меня находках.

1.      Теперь я понимаю, что Cycle time и Lead Time - разные метрики. Lead Time начинает отсчет тогда, когда делается запрос, и заканчивается доставкой элемента. Cycle Time начинается, когда стартует непосредственная работа, и заканчивается, когда элемент готов к поставке. Грубо говоря, Lead Time - то, что видит заказчик, Cycle Time – то, что видим мы, разработчики.        

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

Что после?

Автор этих строк остался доволен тренингом и тренером. Спасибо Коле Алименкову за возможность досконально обсудить Kanban. Несколькими часами позже, проболтавшись на вокзале вместе с организованными группами немецких фанатов футбола, я сел в поезд на Днепропетровск.  Теперь пью чай с малиной, сбиваю температуру фервексом и желаю всем не болеть, а читать про Kanban )).

Пока.

Планирование вашей рестроспективы на лету!

Что я нашел?
Совершенно случайно наткнулся на замечательный ресурс http://www.plans-for-retrospectives.com

Что можно делать?
С помощью этого инструмента вы можете генерировать план ретроспективы на лету, буквально за секунду! Разве это не замечательно? Для каждого из этапов ретроспективы в произвольном порядке выбирается активность и предлагается вам на выбор.

Зачем? 
Для меня это очень актуально, ведь я стараюсь сделать ретроспективы более разнообразными и  интересными для своей команды. Считаю, что нужно постоянно менять активности, не повторяться. Иначе ретроспектива приедается и становится чем-то рутинным.
Теперь с помощью этого нехитрого, но эффективного инструмента вы можете превратить ретроспективы в увлекательные встречи.

Agile намного эффективнее Waterfall

     В июне 2012 года уважаемая во всем мире независимая аналитическая компания Standish Group выпустит очередной годовой отчет об эффективности IT проектов. Все отчеты, начиная с первого в 1994 году, демонстрируют неутешительную статистику проектного менеджмента в нашей индустрии.
     По состоянию на 2009 год только треть проектов стали успешными. Следует упомянуть, что Standish Group использует классическое определение успешности проекта - on Time, Scope, Budget (треугольник менеджера).

     Еще в 2006 году Standish Group в числе 10 факторов успешности назвал Agile. Тут вы можете найти интересное интервью с Джимом Джонсоном (основателем и руководителем Standish Group), где он много говорит об Agile и изменениях в индустрии после появления гибких методологий.

     По моему мнению, статистику портят Waterfall проекты. В выборке они смешаны со своими более везучими собратьями, созданными при помощи гибких процессов. Февральский пост Майка Кона подтвердил мою догадку и поднял настроение.
"Думайте сами, решайте сами", но Agile проекты оказались в ТРИ раза эффективнее.

С нетерпением жду финального отчета.
Вы еще не верите в Agile? :-)

Все. Конец.