За что отвечает Scrum команда?

Была Ретроспектива на спринт 1.0.6.
Говорили про "Прозрачность".

Проблема - Команда определяет Scope Спринта. Далее пишет фичи как может и на Демо мы все узнаем что успели. Burndwon chart показывает что дела плохи. Но команда ему не верит так как несколько задач в прогрессе, и после их закрытия все будет хорошо. Обычно куча задач закрывается за день-два до Демо. Или не закрываются. 

1) Более мелкие Stories не хотим - утраивают

2) WIP уже ограничивали - устраивает

3) Не суть

При закрытии задачи я генерирую различные замечания/улучшения которые становятся видны лишь после реализации. Команда уверена что это увеличивает Scope фич и роняет спринт. 

На Демо решили улучшить Burndown chart чтобы он работал у нас. Все согласились. Думаю и правда будет лучше - проверим.

Под конец заговорили о том почему chart не работает сейчас и вскрыли расхождение в мнениях. Пусть будут варианты А и Б.

Вариант А.

Команда на планировании сама оценивает все задачи и определяет Scope на Спринт. Если все пойдет хорошо, то именно этот объем будет выполнен через 2 недели. Команда коммитится (ну, предсказывает) что сделает все что в их силах чтобы так случилось.



Далее во время Спринта что-то случается. При возникновении проблем команда вообще и каждый разработчик принимают различные решения. Наша стратегия направлена на распространении информации чтобы каждый принимал решения чуть лучше чем раньше. При принятии решений возникает треугольник, но он не много отличается от того что есть у менеджеров. Я выделил 3 критерия - Время, Scope и качество кода.

1) Сейчас команда решает проблемы через критерий "Время" - мы обеспечивает нужное качество кода и тот Scope что хочет РО за счет времени. В результате коммитмент на Scope Спринта редко когда сбывается.
2) Балансировать за счет качества кода мы не готовы - это дорого.
3) В результате я предлагаю команде балансировать за счет Scope. 

У команды есть возможность отклонять тем замечания/улучшения что я генерирую (кроме того что в АС явно указаны). Команда отвечает за Scope Спринта - она решает что успеет сделать и что нет.

Более точный Burndwon chart должен позволить принимать решения "Успеваем/Как сильно не успеваем" не экспертно, а более формально. 

Вариант В.

Все так НО. Команда отвечает только за качество кода и продукта. Обрезать Scope во время Спринта должен РО. То есть он или не делает замечаний/улучшений или пусть не рассчитывает на успех Спринта.

Далее моя риторика.

Почему Я должен принимать решения по Scope каждой задачи? Кто принимает решения - тот и несет ответственность.
1) Команда закомитилась на некоторый Scope - я отвечаю чтобы команда его реализовала. Не хочу.
2) Этих решений слишком много - они мелкие. Не хочу.

Самое простое, наверное - это спросить у РО что ему важнее. Красиво или функционально.
Я говорю что функционально. Первый релиз, снижаем риски, нужен MMF на балансировку консолидированной модели и сценарный анализ.

А вы что думаете?

Создание презентаций для тренингов

Смена подхода по созданию слайдов для презентаций за последние 2 недели. Последние презентации доступны здесь - Slideshare.net

Как результат - уверенно "черчу" на графическом планшете. 

А вы проводите ретроспективы для своей жизни?

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

В Scrum есть отличная практика делать ретроспективу в конце каждого спринта. Я делаю ретроспективу в конце каждой недели в пятницу утром пока голова соображает.

Это выглядит как запись в дневнике в формате

1. Мои победы/успехи за неделю
2. Мои неудачи
3. Что изменить

Анализирую относительно того, что случилось за неделю (это обычно про победы) и того, как достигнуты недельные цели (это обычно неудачи).

Главное признать что

1. что проблемы есть (здесь важна техника ставить корректные цели)
2. что результаты не достаточны
3. что это твоя вина

Из моих побед следует решение что я должен продолжать делать. Из неудач следует что нужно изменить или начать делать. Здесь нужно потратить минут 5-10 на анализ (см. всадник, слон + окружение) и сразу принять решения/действия на следующую неделю.

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

Половина изменений по результатам ретроспективы оказываются мусором - не работают для меня, не толкают к цели. Но value от остальных 50% достаточно для прогресса.

Итак, что дает личная ретроспектива:

1. Рефлексия на стеройдах. Не случайная, постоянная, плановая.
2. Анализ текущих проблем, которые самые Важные сейчас, так как не дают достигать самых Важных для вас целей.
3. Ведет к изменениям, которые проще внедрить с использованием "остывающей", но еще "живой" мотивации.
4. Возможность найти простое решение, и не использовать Heroic mode. Когда вы решаете что нельзя быть тряпкой и тратите на цель больше усилий чем могли бы.

Планирование и визуализация

Размышлял над проблемой достижения целей.
Есть 10 целей на ноябрь-декабрь.
Стратегия №1:

• Нужно каждый день делать небольшой шаг к каждой цели и в результате ты придешь к ней. Например, Бизнес-Молодость или подобное на Smartprogress.ru 

В результате по истечению времени ты оказываешься в какой-то точке на ПУТИ достижения цели, не достигнув ее. Это походит - как мы спринты исполняем. Мы просто делаем что успеем, и в конце спринта смотрим что получилось. "Burndown chart" у нас не работает.

Стратегия №2

• Запланируй как будешь достигать цель и только после этого начни что-то делать.

Это лучше, но планирование 1-2 часа в самом начале для цели на 2 месяца недостаточно. Все слишком сильно меняется.

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

Так же решил перенять burndown chart из Scrum и визуализировать проблему. В результате есть такое.

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

Книги "Leadership Agility: Five Levels of Mastery for Anticipating and Initiating Change" и "Visualize This: The FlowingData Guide to Design, Visualization, and Statistics"

Первая книга - Leadership Agility: Five Levels of Mastery for Anticipating and Initiating Change. Крутая вещь, мне очень понравилось. Она специфична, слишком теоритична, и потому скучна. Но по смыслу очень крута. О том что главное для развития - это рефлексия. И смысл в постепенном развитии системного мышления (как я это называю, в книге не так) до высокого уровня. 

Я даже решил сделать mindmap, выделить цели и пути достижения след уровня лидерства, и внести это в 10 целей до НГ. 

Не важно чего я смогу достичь, главное что после этого я буду знать чуть больше.    

Вторая книга - Visualize This: The FlowingData Guide to Design, Visualization, and Statistics

Я ее советовал ранее - я ошибся. Ничего полезного. Пролистал за несколько часов, зато до конца. Там нет теории, там практика для статистиков как программировать в программе R, и потом обрабатывать картинки в Adobe Illustration.
Не открывайте ее.

Внедряем Power Engagement

Одна из 10 моих новых целей на ноябрь-декабрь - это более полное внедрение принципов Power Engagement (как я называю). То о чем рассказывают в книге "The Power of Full Engagement: Managing Energy, Not Time, Is the Key to High Performance and Personal Renewal".

Зачем это все? Я применил ряд рекомендаций, и есть стойкое ощущение что стало лучше. Меньше устаю на работе, лучше соображаю, больше хороших идей возникает, меньше ошибаюсь. В общем - это отличный подход.
Наверное походит на псевдо-науку, но я воспринимаю это как рекомендации.

Цель - не сильно SMART, но я решил по ходу дела метрики выработать и пытаться их достичь.

Vision - это больше счастья в настоящем и больше здоровье в будущем. Думаю любые вложения здесь вполне оправданы.

В процессе исполнения с понял что зря не сделал mindmap на книгу, когда читал, потому приходятся пролистывать ее снова с начала, и фиксировать.

В сети есть чужие mindmap, но они не кажутся мне полезными.

В общем, вот. Предлагаю посмотреть на mindmap первой 1/3 книги, по которому я планирую внедрять изменения в жизнь.   

Ссылка на картинку

Теория ограничений или как измерить качество?

Я не люблю Теорию ограничений - скука смертная. Если бы не художественное изложение ряда книг - ничего бы не осилил. У меня все еще теплится надежда попробовать эти диаграммы для решения проблем, но пока не могу найти случая и команды для этого. Наверное нужны желающие чтобы можно было это делать совместно - просто впихивать это своим сотрудникам можно их сразу отпугнуть от ТОС и они даже не захотят потом читать про него.

Из ВСЕХ этих книг про ТОС я взял лишь небольшую часть небольшой идеи и пытаюсь применить это в своей работе.

Опишу то малое что я взял и хочу использовать.
В производстве есть 3 показателя, которыми можно описать нашу деятельность

• Выпуск - то что мы выпускаем и продаем, то есть наш доход от продажи продукции
• Операционные расходы - наши затраты на осуществление деятельности, которые нельзя вернуть
• Инвестиции - наши инвестиции в производство, которые мы можем в будущем обналичить и вернуть

В результате все НАША деятельность направлена на достижение простой Цели

• Увеличивать выпуск
• Уменьшать операционные расходы и инвестиции

Теперь что это относится к ИТ.

• Выпуск - это тот продукт что мы разрабатываем. Чтобы его померить не хочется оперировать деньгами, сделаем упрощение и будем измерять его в кол-ве фич, которые мы выпускаем, или Velocity (да, это неправильно. Я знаю. Это упрощение). То есть мы выпускаем фичи - нам за них ПЛАТЯТ. При этом мне сразу хочется здесь выделить из всего Выпуска его часть и назвать его Value. Это те фичи, которые реально нужны заказчика. То есть платит он нам за все фичи, но его реально нужны лишь ЧАСТЬ из них
• Трудозатраты - все трудозатраты, которые списываются на проект. В часах. Легко переводится в деньги.
• Инвестиции - тут сложнее. Нет у меня станков или роботов, которые потом можно будет продать. Можно попробовать переделать это в знания, которые в дальнейшем помогают нам выпускать лучше, и тогда стратегия меняется на их увеличение. НО лучше упростить - инвестиций нет.

То есть вся моя деятельность как менеджера направлена на увеличение выпуска и уменьшение трудозатрат. Это было интуитивно понятно и до ТОС.

Но далее появляется следующее утверждение. Любое улучшение должно быть измерено относительно этих показателей. И мы делаем переход в нашу реальность.

Ко мне приходят аналитики Маша и Катя и говорят что они сильно постарались и перевели процесс поставки требований в Use Cases на User Stories. И теперь этот процесс занимает в 2 раза меньше времени. Я узнаю увеличилась ли скорость разработки, то есть Выпуск. Он не увеличился (предположим).  Я увольняю Машу. Так как Выпуск не увеличился, то для Общей Цели это ничего не дает. Зато теперь я могу снизить трудозатраты. После этого никто никаких "инноваций" мне не предлагает.

Конечно же я считаю что практика User Story полезна. Она должна заставить команду меньше общаться через документы и больше общаться в живую. В результате процесс передачи знаний должен улучшится, снизится время на переработку фич в результате непонимания, и должен увеличится Выпуск.
А снижение трудозатрат аналитиков мы используем чтобы перенести часть работ со Спринта на предспринтовую деятельность. Например, более детальную проработку UI прототипов, что так же должно увеличить Выпуск. Используйте User Stories.

Потому можно утверждать что любая практика, которую вы решите внедрить, должна увеличивать Выпуск. То есть TDD, BDD, CI, Code Review и тп должны "драйвить” разработку вперед. Если новая практики оптимизирует только какую-то ЧАСТЬ процессов и не увеличивает Выпуск, то это Wastes. Можно выкидывать.

Давай поставим новую Jira. Выпуск увеличится? Waste.
Давай перейдем на Jenkins. Waste.
Давай будем описывать в Confluence How-To, которые нам возможно потом помогут. Waste.

Трудозатраты чаще всего мы не можем уменьшить. На практике мы не увольняем людей из команды. Если аналитики стали работать меньше, а вы не можете никак это превратить в Выпуск - Вам это ничего не дает.

Как измерить Качество?

Мы пишем unit-тесты - мы увеличели Качество. Хм, а как проверить?
Фактически Качество так же заложено в вашем Выпуске и Трудозатратах.

Вы используете CI чтобы быстро находить баги и исправлять их. В результате баг исправляется за 2 минуты сейчас, а не за N часов или M дней завтра с использованием поддержки 1, 2 и 3 уровней. Это не стопает разработку, значит “драйвит” Выпуск.

Или качество это увеличение соотношения Value / Выпуск, то есть больше поставки того что бизнесу надо, а не то что написано в ТЗ. НО вам еще нужно постараться превратить это деньги. Если вы не можете превратить это в деньги, то такое качество Вам не нужно. Именно так и происходит в заказной разработке. Платят за фичи в ТЗ, а не за то что процент ПОЛЕЗНЫХ для бизнеса фич будет выше.