четверг, 3 апреля 2014 г.

Как разбивать задачи и увеличить эффективность ваших процессов?

О чем статья и зачем это вам?

Все всегда разбивают задачи на более мелкие чтобы их было удобнее анализировать/разрабатывать/тестировать. Всегда были Epic задачи в беклоге, которые мы били на более мелкие User stories. Но именно формат User stories и потребность в том, чтобы любая задача давала после своей реализации бизнес-ценность Заказчику, останавливает многих от разбиения на мелкие задачи. То есть мы не видим возможности разбить задачу кроме как разделить ее на технические задачи, и решаем остановиться.

Хочу описать свой подход к разбиванию задач, которые я использую в рамках Kanban-системы (почитать можно здесь), и который предлагаю командам, которых коучу. Если вы сомневаетесь чем это может быть полезно, но в конце статьи я описал возможные результаты от внедрения подхода.  

В чем проблема больших задач?

Что дают большие задачи?
  1. Лучше видна основная проблема, которую нужно решить. Команда видит не кусок проблемы, а всю ее, что дает лучший vision и дает принимать решения лучше. (Это можно решить другими способами).
  2. Что-то еще?
Какие проблемы больших задач?
  1. Они увеличивают вариативность процессов. Меньше предсказуемость в успешном закрытии спринтов, меньше вероятность в успеть закрыть такие задачи в релиз.
  2. Они увеличивают нагрузку на команду. Разработчики "пилят" большую задачу 3 недели, тестировщики - курят. Затем тестировщики пилят, а разработка ждет.
  3. Они увеличивают очереди и время цикла. Задача 3 недели в разработке. За это время никакие "приоритетные" задачи не будут закрыты.
  4. Они уменьшают эффективность обратной связи и увеличивают риски. Только через 2 недели мы узнаем что не поняли проблему Заказчика.
  5. Они снижают качество. Мы внедряем 2-х недельный функционал разом и получаем большое количество ошибок. Они стоят "дороже" по сравнению с тем, что мы бы могли внедрять функционал раз в 2 дня и решать проблемы постепенно. 
  6. Наверное есть еще много производных проблем от тех, что описаны выше.  
На самом деле редко у кого есть большие задачи в работе. Команда легко бьет любую задачу на более мелкие, но они это делают в рамках своего понимания. И понимание у них техническое. В результате у таких мелких задач огромная связность, и проблема никуда не уходит.
  1. Сделали за 2 дня изменение в Модели в БД. РО смотреть нечего.
  2. Сделали за 1 день новые формы, которые еще не работают. РО это не интересно. 
  3. Сделали за 3 дня логику, которая еще не полная и потому не позволяет проверить весь процесс. "Эй, РО. Пока не смотри, скоро все будет".
  4. Доделали за 3 дня логику. Но нужен еще рефакторинг.
  5. Сделали за 1 день рефакторинг. "РО, все готово".
  6. В результате через 2 недели - "Но я же хотел чтобы инфляция применялась в рамках расчетов", "Мне не нужен выбор проектов, мне нужно выбрать сразу весь портфель проектов", "Расчет эффективности проектов не правильный. Зачем вы учитываете инвестиции для расчета социальной эффективности"
  7. ОК, еще +1 неделя чтобы все доделать. 

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

Почему здесь может помочь Story Map?

Ранее я использовал предложение Dan Rawsthorne, которое услышал на AgileDays'12. В любой задаче можно определить backbone (основной костяк, который необходим для закрытия задачи), beef-up (бесконечные улучшения по задаче), alters (реализация альтернативных сценариев, fail cases), UI (так же бесконечные улучшения по UI/UX). Все фичи мы нарезали на эти части (в голове) и формировали по этому пониманию User stories. Но так как это разрезание было в голове у аналитика, то часто в процессе разработки были различные споры, что входит в scope задачи, и что нет.



Так же есть - The hamburger method. Пару раз мы к нему обращались, резали задачи как предлагается, но видимо из-за того что это было мало формализовано и большей частью выполнялось в голове, так же плохо сработало для нас.

В результате я вернулся к Story map.

Story map в исходном понимании используется для формирования и ведения карты функционала по продукту. Большая и подробная карта функций/историй. Я нашел эту технику мало полезной пару лет назад. Идея чтобы собрать всех членов команды и за 1-2 дня сформировать 2 сотни историй, которые сформирует исходный беклог продукта, кажется мне не продуктивной. Уже через неделю мы узнаем о продукте гораздо больше и половину историй нужно будет выкинуть, иначе мы их сделаем и это будет никому не нужно.

Потому для ведения scope по продукту я используют Impact mapping, и функционал представляется в виде дерева. В рамках Impact map я нахожу процесс стратегического планирования более эффективным.

Но я вернулся к Story map чтобы разбивать крупные фичи, которые являются атомарными в Impact map. "Стресс-тестирование портфеля проектов", "Оценка эффективности портфеля проектов". Для Impact map это атомарные фичи, Стресс-тестирование - это отдельная фича сценарного анализа, а оценка эффективности - это часть процесса мониторинга. Но в части разработки это будет стоить нам 2-3 недели на каждую из этих задач, потому давайте бить. 

Как я разбиваю задачи?

Как инструмент я использую "Google Sheets".



Сверху слева-направо разбивают задачу на этапы/шаги/части в зависимости от типа задачи.
Сверху-вниз описываю инкремент по задачам, которые можно сделать в рамках этого шага, отсортированные по их ценности/реализуемости. Чаще всего первый шаг - это "мы ничего не делаем".
  1. Нужно позволять делать ввод данных - не делаем ввод данных. 
  2. Нужно делать расчет - не делаем расчет. 
  3. Нужно визуализировать результаты - показываем статику. 
В результате есть матрица из N x M мелких задач, которые можно сделать независимо.

Так как задачи слишком много и они слишком мелкие, то нужно сделать их объединение в рамках одной задачи Вашего беклога. Для этого можно использовать следующую логику:
  1. Задачи по самым рисковым шагам/этапам решаем первыми.
  2. Группируем задачи так, чтобы были все шаги по горизонтали, и можно было максимально быстро показать результат Бизнесу.
  3. Группируем задачи исходя из их сложности. Сколько задач можно объединить чтобы получилась задача на 2-3 дня. 
Далее цветами можно сгруппировать задачи в рамках user stories, и определиться с их приоритетом в беклоге.  



Для разбиения Story map по столбцам я использую следующие подходы:
  1. У нас есть use case на процесс, который имеет ряд шагов. Столбец == шаг процесса.
  2. У нас есть большой функционал, который независим между собой. Столбец == независимая часть задачи.

Какие есть проблемы/примеры их решения?

Какие могут быть проблемы с построением Story Map или разбиением задач?

Интеграция 2-х систем

Есть мнение что статус интеграции систем бинарен - он или есть или нет. В результате это занимает 2 месяца и проходит довольно мучительно. А именно:
  1. Разрабатываем API для интеграции и согласуем его для обоих систем. Неделя.
  2. Реализуем это API для обоих систем. Так главная наша надежда/удача: "мы делаем это параллельно и независимо, потому выйдет дешевле". 1 месяц
  3. Начинаем тестировать интеграцию и вылазят проблемы. В результате мы много раз переделаем весь API и переписываем обе реализации. Еще +1 месяц.
Как это можно сделать:
  1. Формируем Story Map по методам, которые входят в API. 
  2. Реализуем 1 метод, который передает 1 параметр, в обеих системах и начинаем тестировать. 1 день.
  3. Находим все проблемы с сетевой связностью, со различных стандартами SOAP в Java и С++ и тп. Решаем их. Пишем интеграционные тесты, чтобы можно было автоматически тестировать интеграции 100 раз в день. Пишем моки сервисов для каждой системы, чтобы можно было тестировать интеграцию локально. 1 день
  4. Реализуем 1 метод, которые передаем все параметры, в обеих системах и начинаем тестировать. 2 дня.
  5. Находим проблемы с различным представлением строк/многомерных массивов/последовательностей в реализациях SOAP для Java и С++. Решаем их и договариваемся что все дальнейшее API будет это учитывать. 1 день.
  6. Итеративно наращиваем API с постоянным тестированием интеграции. 1 месяц
  7. Остальное время мы съэкономили.        

Модернизация

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

Как это можно сделать:
  1. "Сделать изменение для 7 услуг" и "сделать изменение для 7 услуг так чтобы все услуги всегда работали" - это 2 разные задачи и вторая задача сильно дороже. 
  2. Делаем Story map по шагам услуги
  3. Делаем изменение для самых рисковых шагов для 1 услуги. Ломаем все остальные услуги.
  4. Итеративно дорабатываем 1 услугу и показываем Бизнесу. Получаем OK.
  5. Дорабатываем остальные услуг по аналогии.     

Какие результаты вы можете получить?

Какие результаты от разбивания задач на более мелкие, разработка по которым будет стоить 2-3 дня? Не скажу, что все именно из-за мелких задач, но это сильно влияет:

  1. Это СИЛЬНО сокращает время цикла по задачам, как я писал для Kanban-системы. Далее идут уже следствия сокрашения Cycle time.
  2. Это уменьшает вариативность процесса. То есть более предсказуемое и постоянное кол-во задач, закрываемых за релиз (для Kanban), и более постоянный velocity в Scrum.
  3. За счет того, что у вас более предсказуемый и постоянный поток, вы сможете уменьшить WIP и размер очередей в процессе.
  4. Это снизит переработки (когда или очень много работы или ее мало) сотрудников и повысит их загрузку.
  5. Меньше Cycle time и выше Work time -> увеличение эффективности команды
  6. Это повысит качество результатов.
  7. Это сильно ускорит обратную связь от Бизнеса, в результате снизит ваши риски и увеличит доверие Бизнеса.
Готовы попробовать?

вторник, 25 марта 2014 г.

Как внедрить Kanban для визуализации и улучшения ваших процессов?

О чем статья и зачем это вам

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

Возможно, у Вас сейчас есть свой собственный процесс разработки ПО или вы "скрамитесь", и вы найдете мои советы интересными, что сподвигнет вас на изменения. Наши результаты внедрения Kanban-системы можно найти в самом конце статьи.

Мои идеи основаны на книгах про Lean в общем и 2-х книгам в частности:
Главное, что нужно помнить. Как говорит David Anderson, Канбан это не процесс разработки, не процесс управления проектами, и точно не методология. Это система для визуализации процессов и их оптимизации. И только.

С этим знанием и начнем.

Визуализация процессов

Для визуализации процессов мы используем 2 типа досок.



Есть физическая доска в комнате, где располагается основная часть команд. На обычной доске разрисованы столбцы и строки согласно текущему процессу. При появлении задачи мы пишем на бумажной карточке название задачи от руки. Как предлагает Майк Кон, чем сложнее прочесть название User story, тем выше вероятность что член команды вчитается в ее название полностью. На гибкие магниты наклеены аватарки членов команды - и карточки держатся и люди видны. У карточки отмечаются аналитик, который ее курирует, и разработчик(и), который ее реализует.

Если карточка долго висит в разработке (долгие задачи в аналитике не дают нам проблем, потому не отслеживаем) или на текущий момент над задачей никто не работает (разработчик из Ruby Team реализовал всю логику на клиенте и сервере, и Java Team должна доделать финансовый расчет), то это Blocker и на нее вешаем красный стикер.

Так как часть Java Team не в Москве, да и хочется иметь доступ к доске в любое время, в любом месте, есть электронная копия доски в Agile Jira. Вернее, Jira это мастер-источник данных, и физическая доска - это копия данных.

В Jira для удобства создано сразу несколько досок. Единые статусы позволяют легко их вести в Agile Jira:
  1. Есть "Product Backlog" Scrum-доска, где создаются новые задачи, и в рамках беклога происходит их приоритезация. Это удобно делать в рамках плоского списка. Как Product Owner я использую ее.
  2. Есть "Research" Kanban-доска, которая содержит беклог и статусы задачи по аналитике до статуса готовности к разработке. Она удобна в аналитике, так как видны самые приоритетные задачи из беклога, понятно что брать, согласно классу и владельцу задачи. Видно сколько задач находится в аналитике, и соответствует ли WIP. Использую ее.
  3. Есть "Develop" Kanban-доска, которая содержит статусы от готовности к разработке до закрытия задачи. Это часть общей Kanban-доски по разработке. Мне в работе она не нужна. 
  4. Есть "Kanban all" Kanban-доска, которая является копией физической доски. Это все статусы задач без беклога. Так как беклог бесконечен, то он сильно влияет на отображение досок, и потому я его исключил. Для работы с ним есть "Research".   


В Jira Blocker-задачи я отмечаю приоритетом "1+" для визуальности. Увидить такие задачи можно через Quick filter - "(status changed from "Ready" to "Ask OP" before -4d) AND (status = "Ask PO" OR status = "In progress")".

В начале у нас были раздельные доски для Ruby Team и Java Team. Из-за проблем в их совместной работе мы объединили их в рамках одной доски. Зачем я разделил физическую доску на 2 части по-вертикали - чтобы визуально разделить их задачи, но оставить прозрачность их задач друг для друга.

В Jira это сделать нельзя потому я создаю для Java Team и Ruby Team разные типы задач и выделяю их различным цветом. Синие задачи для Java Team, Зеленые - для Ruby Team. Названия задач на карточках на физической доски так же различных цветов. Задача принадлежит Java Team если основной функционал должен быть разработан на их стороне. При этом очень часто там есть функционал для Ruby Team, который нужен чтобы полностью закрыть задачи. Это нормально - задачи не разбиваются на модули. Задача - это полезный Impact для Заказчика.

Устанавливаем Work-In-Progress

Чтобы убрать хаос в процессе и позволить людям уходить домой во время, ограничиваем Work-In-Progress по статусам задач. Jira не позволяет это сделать правильно, потому реализуем это на физической доске, и помним для электронной.



Есть 3 аналитика, потому ограничим до 3-х общее число задач на все статусы по аналитике. Я делаю аналитику по задачам когда аналитики перегружены по документам, потому вписываюсь в это ограничение.

Пусть "Ask Business" будет ограничен до 6 задач - странно если здесь будет большая очередь. Надо часто общаться с Бизнесом.

Мы фокусируемся на том, чтобы снизить Cycle time потому обязаны МАКСИМАЛЬНО  ограничивать очередь перед нашим "ограничением" (см. Теорию ограничений). "Ограничение" в нашем процессе это разработка, потому фокусируемся на WIP для статуса Ready, то есть "готово к разработке". David Anderson предлагает WIP на очередь = (WIP на следующий статус + размер буфера). Для нас это будет 8 = 5 + 3. Но мы еще вернемся к ограничению на Ready.

В Ruby Team и Java Team у нас 6 разработчиков. Половина задач требует совместной работы обеих команд, потому ограничим WIP на оба статуса по разработке равным 5. Это заставит команды сильнее совместно взаимодействовать и общаться.

Ограничение на "Тестирование/Code Review" в 3 задачи не делает процесс тестирования ограничением, потому проблем здесь нет.

Беклог и "Done" бесконечны, потому измеряем Cycle Time всей Системы между ними.        

Определяем политику процессов

Для примера опишу наши процессы разработки и политику на них. Нам важно определить "Definition of Done" для перехода между статусами, чтобы избежать жульничества и заставить наш WIP работать не только на благо команды, но и на благо менеджмента. 

У нас есть беклог задач (в качестве задач я использую Job Story) на разработку, которые отсортированы по приоритету. В нем назначается ответственный за задачу аналитик. В нужный момент аналитик берет задачу в работу, и задача появляется на Kanban-доске.

Наши статусы по аналитике следующие:

  1. Скетчи. Обсуди с Product Owner задачи, синхронизируй с ним vision по задаче через скетчи на бумаге или доске. Договорись про объем задачи. Тут важно чтобы vision PO, у которого есть vision на все и вся, совпал с vision аналитика, который будет вести задачу до завершения.
  2. UI/UX. Если в задаче есть новый UI или это улучшение в части UX, то нарисуй UI-прототип формы для разработки. Обсуди с РО, провалидируй UI на use cases, реши как можно больше проблем, чтобы разработчикам было проще.
  3. Спеки. Мы стараемся писать много SpecByExample, и здесь необходимо это сделать. Спеки мы пишем на финансовые расчеты, сложные расчеты или мутную логику. 
По завершению аналитики если мы не уверены с полной корректности наших результатов, мы передаем задачу на согласование с Бизнесом. Это согласование vision, так как в процессе аналитики мы нашли различные проблемы, и vision уже "поплыл". Или согласование спецификаций. Или согласование прототипов новых сложных форм, так как при визуализации задачи Бизнес может поменять vision и начать генерировать идеи.

Задачи, готовые к разработке, попадают в статус "Ready". Сложные задачи я отдельно проверяю, чтобы вернуть в аналитику при необходимости.    

Когда разработчик берет задачу, она попадает в "Ask PO". Да, мы обсуждали эту задачу на WorkShop, но все равно, подойди в владельцу задачу, уточни скетчи/прототипы, уточни scope. Сейчас это самое дешевое что можно сделать - потом это будет дороже.

Статус "In progress" - это обычная разработка. Только здесь есть более формальный "Definition of Done" - разработчик должен получить в Skype OK от владельца задачи. Сейчас так как многие говорят OK просто так (и бывает что разработчик понял что "все хорошо", а аналитик говорил что это все замечания что я нашел - исправляй и посмотрим снова), заменили его на получение определенного Skype-смайлика.

Статус "Test/CodeReview" означает что наш QA Lead делает исследовательское тестирование по задаче, а команда ревьюит код перед слитием в ветку "develop".

Из командных встреч у нас остались следующие. Мы перешли с 2-week Sprints на 1-week releases, и теперь все основные встречи проходят 1 раз в неделю:

  1. Daily - вместо 3-х скрамовских вопросов смотрим на доску и обсуждаем задачи справа налево. Стало живее и быстрее. Смогли наконец-то сделать общей daily для Java и Ruby team. Впервые увидел как после daily разработчики группами обсуждают общие задачи. 
  2. Planning - мы отменили его. Мы не оцениваем задачи - УФФ!
  3. Grooming - общаемся с аналитиками, обсуждаем задачи и проблемы, смотрим беклог.
  4. Workshop - обсуждаем задачи, которые готовы к разработке и которые грумятся в текущий момент. Цель - это обсудить задачи с командами в общем виде чтобы все понимали куда гребем. 
  5. Demo - смотрим что готово на релиз и планируем его.
  6. Retro - встречаемся реже чем раз в неделю. Скорее On-demand
  

Измеряем и оптимизируем поток

Jira рисует хорошо кумулятивную диаграмму потока и считает Cycle time за разный период. Я раз в неделю проверяю как оно идет и в какую сторону есть изменения.




Отдельно от этого я считаю в Google Drive кол-во задач, которое мы релизим каждую неделю и время ожидания для статуса "Ready". Наше время цикла скачет от 5 до 7 дней. Из них 3-5 дня - это время ожидание в Ready. Отсюда можно вычислить нашу эффективность.

И это знание времени ожидания мотивирует на изменение. Если я смогу его уменьшить, то для текущего состояния процессов снижение времени цикла в 1 день может на 10-20% увеличить нашу эффективность.
        

Управляем через числа и переходим с PUSH на PULL 

Но как можно уменьшить время ожидания?

К сожалению, я очень долго шел к понимаю принципа PULL для своих процессов. То есть как PULL работает в "Цели" у Голдрата или у Тойоты было понятно, но как мне его использовать у себя в процессе.

Оказалось, что просто. Каждое утро я проверяю свою очередь перед "ограничением", то есть статус "Ready". WIP равен 8. Пусть в Ready лежит 5 задач и в статусах по аналитике есть еще 2 задачи. Значит я могу стартовать аналитику по еще одной задаче, и если даже разработчики ничего нового не возьмут в работу, мы не превысим WIP если завершим всю аналитику. Какая 1 самая важная задача в беклоге, с учетом того, что она будет готова через 5-7 дней (зависит от текущего времени цикла) и потому попадет в ближайщим релиз. Это можно спросить у Бизнеса, но сейчас я как РО определяю приоритеты.


В результате разработка каждый день закрывает 1-2 задачи. Каждый день я могу стартовать аналитику по 1-2 задаче из беклога. В рамках такого предсказуемого и плавного потока мне уже не нужен большой буфер задач и я могу снизить WIP на "Ready" до (5+1) с буфером в 1 задачу по отношению к разработке.

Если я сделаю это, то

  • Время ожидания упадет на ~ 1 день.
  • Время цикла упадет на тот же 1 день. Мы будет "деливерить" почти за 4 дня! 
  • Эффективность процесса вырастет на 10-20%
К сожалению сейчас есть высокая загрузка аналитиков по написанию документов, что не позволяет груммить быстро и эффективно. Потому я жду изменений.  
  

Устанавливаем приоритеты задач

David Anderson предлагает устанавливать классы сервисов по типам задач чтобы иметь по ним разный Cycle time. Но есть время цикла на доработки у нас 30 дней, но зато время цикла по багам - 3 дня, например.

У нас такой проблемы нет - я фокусируюсь на снижении общего Cycle time. Но я применил классы задач в другом виде. Кроме разделения задач по типу - Java team и Ruby team, я указываю их приоритеты:


  • Приоритет +1 - это Blocker. Фокус на него - он может не попасть в релиз, а мы бы хотели.
  • Приоритет 1 - это Backbone задача. Она самая важная чтобы закрывать основной функционал релиза.
  • Приоритет 2 - это то, что Заказчик очень хочет видеть. Он уже говорил нам, что это ему нужно, но так же он понимает, что backbone-задачи важнее.
  • Приоритет 3 - это beefup, что мы нашли в рамках обратной связи. Заказчик явно не говорил про это, но все понимают что это нужно в продукте.
  • Приоритет 4 - это idea. Нам показалось, что с этой фичей будет лучше. Просто Заказчик не знает что так можно. Когда мы не успеваем в рамках нашего Road map и release map, то до этих задач мы не доходим. Но раньше случалось что писали новые фичи так быстро, что было время на эти идеи.


Визуализация этих приоритетов позволяет

  • проще планировать эти задачи в беклоге
  • видеть что у нас Ready забит beefup-ами, и из-за того что мы не успеваем сделать аналитику по backbone-задаче, разработчики возьмут их и в текущий релиз основные задачи уже не попадут.
Главное для меня это различать backbone и beefup. Это важно для следования по плану релизов.
     

Поддерживаем изменения

Для меня визуализация и цифры - лучший инструмент для поиска новых идеи по изменениям.

Для команды - пока не замечаю. Изменения все таки происходят больше после ретроспективы. Но я верю что визуализация влияет на их мышление и будет приводить к кайдзен культуре. Чтобы этому способствовать:

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

Результаты внедрения

Какие результаты перехода на систему Kanban я могу указать:

  1. Мы стали больше поставлять. Если раньше делали по 8 задач за 2 недели, и казалось что это мало. То теперь мы делаем 8 задач за 1 неделю, и все равно кажется мало.
  2. Cycle time уменьшился с 43 дней (во времена Скрама) до 5 дней. А значит мы выкинули из процесса большой WASTE.
  3. Раньше мы фокусировались на velocity, который на самом деле ничего не означает. Теперь мы фокусируемся на Cycle time, и мне понятно почему он важен. 
  4. Мы перестали оценивать. Все, нет оценок! Баста! И это в условиях заказной разработки. А это дает нам следующее
    1. Мы сильно снизили Coordination costs, которые тратили на планирование. Это был полный waste. 
    2. Избавившись от планирования, стало возможным сократить релиз с 2-х недель до 1 недели. А частая поставка - это всегда хорошо. Быстрее можно сделать прототип сложной фичи, получить feedback и доделать ее в новом релизе. 
    3. Мы перестали фокусироваться на оценках. Нет постоянных споров, что команда не может сделать этот функционал в рамках текущей оценки, так как иначе сорвет спринт.
    4. Теперь мы фокусируемся на взаимодействии участников команд между собой. 
    5. Теперь мы фокусируемся по поставке, на том чтобы была ценность, impact. Чтобы все было офигенно!
  5. Теперь нет 2-х беклогов для Java team и Ruby team, и больше не нужно искуственно бить задачи.
  6. Появилась большая гибкость в улучшении процессов. Теперь и правда можно управлять не людьми, а процессом.
  7. Полагаю, что из-за уменьшения времени релизов, увеличилась общая Ценность поставок, но пока не могу это явно посчитать.    
Что думаете?

пятница, 28 февраля 2014 г.

Книга "Гибкое сознание. Новый взгляд на психологию развития взрослых и детей"


Забавная книга. 
Автор рассказывает на первых 5 страницах идею про 2 установки в сознании, которые есть у людейю Процитирую краткую версию:

Убежденность в том, что ваши качества высечены из гранита – установка на данность – вызывает в вас потребность самоутверждаться снова и снова. Если вам даны определенные нравственные качества, определенная индивидуальность, определенное, строго фиксированное количество интеллекта, тогда остается лишь одно: доказывать, что количество всего этого добра довольно велико. Ни демонстрировать, ни даже чувствовать нехватку таких основополагающих качеств никак нельзя.
...
Существует и другая установка, согласно которой «карты», полученные при раздаче, лишь отправная точка для развития. Это установка на рост. Она зиждется на убеждении, что ваши качества, даже самые основополагающие, вполне поддаются культивированию, если приложить к этому усилия. И хотя люди могут разниться буквально по всем «статьям» – по своим изначальным талантам и способностям, по интересам, по темпераменту, – благодаря стараниям и приобретаемым знаниям каждый способен меняться и развиваться. 

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

При этом она утверждает что плохо наклеивать на людей ярлыки - люди могут меняться, учиться. Хотя сама легко это делает. CEO Enron, который рухнул, ТОЧНО имел установку на данность. А CEO IBM, которые поднял выручку во много раз, ТОЧНО имел установку на рост. В общем все "хорошие" люди по одну сторону, а "плохие" - по другую.

А идею я поддерживать - нужно всегда учиться, и делать выводы из неудач. Но наверное не все так просто в жизни.

среда, 26 февраля 2014 г.

Todoist - новый инструмент для ведения целей


3 года с "Коровой" завершились. Я переехал на новое современное решение - Todoist.
В виду того, что я не люблю TODO приложения и фокусируюсь не на задачи, а на цели, у меня не много требований к таким решениям:

  1. Скорость работы 
  2. Фильтрация задач через запросы

Подход из OmniFocus с формированием Today списка мне совсем не подходит. 2 раза пытался - не смог смериться. Мне нужна возможность написать свой запрос, который покажет задачи согласно моей логике эффективности. Раньше "гибкое" написание запросов для фильтров я видел только в "Корове", потому мог использовать только ее. Todoist - второе такое решение.

В Todoist можно использовать под цели "Проекты" что делает процесс проще (в "Корове" для этого использовались отдельные запросы на фильтрацию).
Web и  Mobile решения симпатичные.
Есть Karma Trend, который показывает полученные баллы за закрытые задачи. Очень мотивирует.

В результате у меня сейчас:

  • Бумажный молескин - чтобы думать над процессом достижения целей через визуализацию
  • Todoist (Web + Mobile) - для ведения целей и задач-результатов
  • DayOne - для ретроспективы, рефлексии, личного дневника

понедельник, 24 февраля 2014 г.

Книга "The Principles of Product Development Flow. Second Generation Lean Product Development"


Дочитал книгу - мне очень понравилось.
Экономическое обоснование под Agile и Lean мышление. Много про очереди, WIP, DIP и ожидания - очень расширяет сознание в рамках перехода на Kanban.
Очень много экономики по управлению портфелями проектов на уровне организации. Было бы интересно реализовать это мышление на таком мета уровне. 

Есть книги, которые ты читаешь первыми в какой-то области, и потому выглядят сильно полезными. "Как измерить все что угодно", Scrum от Майка Кона, "Стратегия голубого океана". Это одна из таких. Я перестал делать mindmap на прочитанные книги. Вместо этого пишу идеи/"задачи на проверить" в Keep. По этой книге написал идей 60. Для сравнения после предыдущей книги "The Lean mindset" я зафиксировал 5 идей.

четверг, 6 февраля 2014 г.

Наставничество. Цели на неделю и цели на день



У Падавана есть 10 целей до конца февраля. Что делать дальше?

Я рекомендую сделать визуализацию достижения каждой цели на бумаге. Для этого в блокноте рисуем название цели на отдельной странице. Одна цель - одна страница. В самом низу страницы пишем результат, который мы хотим получить. SMART-результат если цель сформулирована в общем виде. Если не можете придумать этот SMART-результат, то представьте себе что должно изменится через 2 месяца если вы сделаете все идеально. Я называю это "Impact".

Результат - внизу таблицы. Сверху - то, что есть сейчас. Нарисуйте план перехода от "Сейчас" к "Результату". Для вас это должно выглядеть логично и выполнимо. Очень подробный план не нужен. Как только вы начнете это делать, ваше понимание может измениться и план так же изменится.

Далее для 3-х Focus целей сформулируйте 3 цели на неделю. 3 результата на неделю согласно текущему плану. Для остальных 7 целей выделите 1 самую важную задачу, которую нужно сделать. Я называю это "@next" цель или "следующий шаг"

Для 3-х целей на неделю визуализируйте план задач на неделю - представьте его мыслено и на бумаге. Из планов на неделю сформулируйте 3 цели на день.

В результате должен получится следующий "TODAY" список:

  1. Цель 1 на день (Today) - это я ДОЛЖЕН сделать сегодня
  2. Цель 2 на день (Today) - это я ДОЛЖЕН сделать сегодня
  3. Цель 3 на день (Today) - это я ДОЛЖЕН сделать сегодня
  4. Цель 1 на неделю (Saturday) - я постоянно вижу и фокусируюсь на ней
  5. Цель 2 на неделю (Saturday) - я постоянно вижу и фокусируюсь на ней
  6. Цель 3 на неделю (Saturday) - я постоянно вижу и фокусируюсь на ней
  7. Next-цель по цели №4 - делаю когда появится возможность
  8. Next-цель по цели №5
  9. Next-цель по цели №6
  10. Next-цель по цели №7
  11. Next-цель по цели №8
  12. Next-цель по цели №9
  13. Next-цель по цели №10
При этом цели и визуализация плана по их достижению есть на бумаге. 
TODAY cписок всегда под рукой - тоже на бумаге или в электронном виде. 

Какие есть проблемы у Падавана здесь?
1) Цель лучше сразу формулировать в виде результата. То есть писать не процесс, а результат с метрикой. 

"Я сделал 1-3 слайда презентации по SpecByExample"

2) Всегда есть конфликт с текущим распорядком дня, где нет времени на выполнение этих задач. Вернее время выделяется домашнее, вечернее. "Я приду домой с работы и сделаю эти задачи". Это не работает. Эти задачи должны быть сделаны ASAP утром. Нужно выделять утром время на их выполнение и защищать это время от внешнего воздействия. Вам всегда будут мешать делать что-то полезное для себя, и вы не должны "прогибаться под мир".

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

- Я почитаю книгу про Agile Results (не сделано)
- Я прочитал 1-10 дни из книги Agile Results (прочитал 1-2 дни)
- Я прочитал 3-5 дни из книги Agile Results (прочитал 3-4 дни)
- Я прочитал 4-6 дни из книги Agile Results (Ура, сделал) 

среда, 29 января 2014 г.

Наставничество. Формирование целей



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

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

Задача №1 - это формализация наших желаний по всем сферам жизни (Карьера и бизнес, Финансы, Личный рост, Друзья и окружение, Отношения, Яркость жизни, Здоровье и спорт, Творчество). Я писал более подробно про это ранее. То есть нужно просто описать все наши желания. Все. Любые. Оказалось что желаний у Падавана не так много. То есть их оказалось 4-5 всего. В большинстве своем желания казались таким несбыточными, потому они даже не были желаниями. Видимо про это даже не стоит думать, желать, мечтать. И это кажется проблемой. Если ты боишься мечтать или желать чего-то, то как ты будешь расти? Что ты будешь достигать?

Задача №2 - это определение самые приоритетных и достижимых (как вам кажется) желаний и их конвертирование в SMART цели на 2 месяца. Причем 3 цели из сфер (Карьера и бизнес, Финансы), 3 цели из сфер (Личный рост, Друзья и окружение, Отношения) и 3 цели из сфер (Яркость жизни, Здоровье и спорт, Творчество). Еще одна 10-ая цель бонусом - откуда угодно. 
Так как желаний было не много, то нам пришлось сильно постараться, придумать еще желания и потом сделать их них цели. Цели оказались довольно искуственны. Наверное это не самые главные цели в жизни Падавана. Но это было началом. В дальнейшем когда пришло понимание мы договорились, что Падаван переделает список желаний, и соответственно скорректирует список целей. Видимо сам процесс формирования целей и начало движения позволяют начать осмысливать свою жизнь и начать определить ожидания от нее.

Задача №3 - это определение 3 Focus цели на месяц. Цели, на которые мы будем фокусироваться. Это оказались в основном цели, которые относятся к работе. Мы привыкли фокусировать на работе, и не привыкли жить своей жизнью и расставлять приоритеты правильно. Но я надеюсь повлиять в том числе на это.

Дальше мы стали ожидать понедельник, чтобы впервые сформировать 3 цели на неделю и 3 цели на день.

А вы сможете описать ваши желания? Вот шаблон в формате mindmap.
Вы сможете сделать 10 SMART целей из этих желаний?

воскресенье, 19 января 2014 г.

Как перейти на Kanban из Scrum или Scrumban-а? Часть 2

У нас был Scrumban и я решился на изменения.

Так как аналитика была на месяц вперед, то очень часто ее результаты "протухали". То есть результаты анализа по задачам были готовы, но в спринт не попадали. Понимание менялось, и сами результаты устаревали. Так же активность по аналитике была периодической. За пару дней к workshop она сильно возрастала, но готовность всех задач к обсуждению обычно не была реализована.
Контролировать это в рамках Scrum было сложно. Хотелось перейти на Flow/Поток задач. Вместо бесконечных споров про оценку и Scope историй фокусироваться на Impact/Влиянии.

В общем я решился.

Из Scrumban переход на Kanban занял у меня 2 часа на настройку В Agile Jira и еще час на создание новой бумажной доски.

Старую Scrum доску я оставил, удалив все Draft спринты - теперь это просто Product Backlog. В нем мы формируем задачи по релизам, как обычно.

Создал общую Kanban доску со всеми статусами по аналитике и разработке. Именно здесь задается весь Flow - указаны все возможные статусы задач и порядок их следования. Указал WIP на разные статусы. Здесь специально не присутствует столбец с беклогом - в нем всегда слишком много задач и потому он получается слишком большим.
Именно эта доска синхронизируется с бумажной.




Далее создал Kanban доску "Research" для аналитики. Она начинается с беклога и завершается готовностью задачи к разработке.



Sprint беклог перешел в Kanban доску "Development" для разработки.



Так как статусов слишком много для отчетов/анализа я создал еще одну доску "Common", объединим статусы по этапам.



Которая дает вот такой отчет и позволяет увидеть где у нас проблемы и wastes.



Что в результате после пары недель полета:
1) Команда считает что без спринтов на них ничего не давит, и они стали медленнее работать. Я в это не верю, и хочу проверить идеи #NoEstimates.
2) У нескольких знакомых видел что спринты позволяют лучше планировать в условиях заказной разработки. Знаешь срок завершения проекта, знаешь сколько спринтов успеешь провести, планируешь какой функционал должен быть закрыт за каждый спринт. Боюсь это самообман и походит на планирование через MS Project. IMHO, процесс планирования должен быть другим.
3) Все Scrum активности (кроме планирования) мы оставили и так же проводим их по расписанию.

Остальное - покажет время.

Бумажная доска выглядит так. Scrum-овские карточки с миньонами заменяются на более простые Kanban-карточки.

вторник, 14 января 2014 г.

Как перейти на Kanban из Scrum или Scrumban-а? Часть 1


Что лучше Scrum или Kanban? Не думаю что есть ответ, они для разных целей.
Нужен ли вам Kanban? Так же зависит от ваших целей.

Мое мнение - они фокусируются на разном.
В Scrum больше фокуса на реализации scope спринта. То есть важно уметь нарезать правильно истории и задачи, правильно их оценивать, реагировать на проблемы с ними, и все это заканчивается результатом - Успех или неуспех в реализации scope Спринта беклога. Не успех - давайте нарезать по-другому, давайте оценивать лучше, давайте обсуждать лучше.
В Kanban (я надеюсь) больше фокус на саму поставку историй, на скорость поставки, на их ценности. Именно поэтому я решился на изменение.

Scrum имеет сильное преимущество перед Kanban - он более строгий и формальный. Он дисциплинирует команду, PO, Заказчика. Вы не можете обеспечить стабильный scope Спринта на 2 недели? Заказчик все время требует перекрасить кнопку в красный и именно сегодня? Это не в Scrum процессе проблемы - это у вас проблемы. Вы оцениваете в часах, а потом требуется от разработчиков чтобы оценки исполнялись с высокой точностью? Вы не можете зафиксировать объем одной истории и при реализации она сильно пухнет? Вам нужно через все это пройти и научится. Потому я уверен что успешный опыт Scrum процесса нужен это эволюции команды и других участников проекта.

Почему мы перешли на Kanban?

В процессе работы мы перешли от чистого Scrum в сторону Scrumban, и последующий переход на Kanban был довольно логичен.

Проблема была в аналитике. Мы вынесли процесс аналитики за пределы Спринта, то есть к Планированию аналитика по всем историям должна была быть достаточной для их оценки. Аналитика должна была быть финальной - в процессе реализации все появляются вопросы/проблемы, которые нужно решать совместно разработчик-аналитик. Но до планирования большая часть аналитики должна быть выполнена.

Далее как я писал ранее про теорию ограничений возникло желание увеличить скорость выпуска путем увеличения усилий по аналитике, то есть к моменту Планирования по истории должны быть готовы все необходимые артефакты по историям - OK от Заказчика, готовые/согласованные SpecByExamples, скетчи/прототипы интерфейсов. Это увеличило длительность и сложность процесса аналитики и сделало его более формальным. В результате у нас появляются Draft Спринта (задачи, которые должны быть готовы к Планированию и которые мы вероятнее всего возьмем в Спринт) и Pre-Draft Спринта (задачи, которые мы грумим, если есть время). То есть 2 предварительных спринта по 2 недели. Мы делаем аналитику на месяц вперед.

Для Draft и Pre-Draft спринтов я создал отдельные аналитические Kanban доски, где описаны какие стадии и в какой порядке должны пройти истории в процесс аналитики. Чтобы формализовать процесс и сделать его визуализацию. То есть там есть столбцы на OK от бизнеса, на предварительное обсуждение с РО для формирование общего vision, на разработку скетчей, прототипов и спек.

Kanban board, Agile Jira
Настройка SQL выборки для доски 

Kanban board, Agile Jira
Настройка столбцов и статусов

У нас Scrum и 3 Kanban доски для работы. Это можно назвать Scrumban.

Продолжение следует.