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

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

Все всегда разбивают задачи на более мелкие чтобы их было удобнее анализировать/разрабатывать/тестировать. Всегда были 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. Это сильно ускорит обратную связь от Бизнеса, в результате снизит ваши риски и увеличит доверие Бизнеса.

Готовы попробовать?

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

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

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

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

Мои идеи основаны на книгах про Lean в общем и 2-х книгам в частности:

• Книга "The Principles of Product Development Flow. Second Generation Lean Product Development"
• Книга "Kanban: Successful Evolutionary Change for Your Technology Business"

Главное, что нужно помнить. Как говорит 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. Полагаю, что из-за уменьшения времени релизов, увеличилась общая Ценность поставок, но пока не могу это явно посчитать.    

Что думаете?

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

Дочитал книгу - мне очень понравилось.

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

Очень много экономики по управлению портфелями проектов на уровне организации. Было бы интересно реализовать это мышление на таком мета уровне. 

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

Лучшие книги 2013 года (из прочитанных)

У меня была цель - прочесть 50 книг за год.
Я прочитал только 36. Но даже эти 36 сильно изменили мое мышление. Как обычно жаль что я не прочел эти книги раньше.
Я думал что практика легко заменяет теорию - я сильно ошибался. 

Если интересно какие книги я бы рекомендовал, то они далее. Без приоритетов.
Ссылки на Amazon есть на самом Shelfari. У меня можно взять PDF версии.

Делать продукты через оказывание положительного влияния на наш Мир

Как проводить изменения в своей жизни и жизни окружающих

Управление не временем, а энергией для более продуктивной жизни

Lean Startup мышление в разработке продуктов

Практическая инструкция по запуску продуктов/стартапов 

Дополнение к системному мышлению о том как измерять неизмеряемое

Теперь любой бизнес/продукт рассматриваю с точки алого и голубого океанов

Что нужно измерять и как влиять на процесс

Куча всего нового про управление людьми в рамках Agile мышления

Уровни лидерства. Раскрыла глаза о том, что Эксперт это самый первый уровень. Самый простой.

Пусть будет ровно 10 книг. 

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

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

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

Lean №12 - Заряжать команду

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

1. Сотрудники говорят менеджерам как нужно работать, а не наоборот. 

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

2. Мотивация.

У команды должен быть не просто список задач в виде беклога, например. Нужна цель чтобы заряжать их. Как этого можно достичь:

• Начните со понятной и озвученной цели
• Убедитесь что цель достижима
• Дайте команде доступ до Пользователя
• Позвольте команде самой коммититься
• Удаляйте помехи и скептиков

3. Лидерство

Тут понятно. Все время ищи проблемы у себя и анализируй их.

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

Нет давления по тестированию - нет крутого тестирования.

Проблемы архитектуры не становятся проблемой команды - потому нет желания делать KISS решения.

4. Экспертиза

С трудом вижу возможности для распространения различной экспертизы в рамках Компании. Это настолько не свойственно для крупных компаний. И все то обучение что выстроено - оно кажется таким малополезным. 

• Как делать презентации? 
• Изучаем SQL. 
• Делегирование. 

Это все здорово, но это не экспертиза. Это какие-то навыки. Потому меня полезным кажется только платные обучение в ScrumTrek. Хотя мы сами можем выстроить все эти тренинги внутри и иметь их бесплатными.

• У нас отсутствует процесс тестирования в проектах. Его заменяет процесс создания бессмысленных скриптов на Selenium. 
• Процесс аналитики выстраивается только в рамках старой Waterfall парадигмы. 
• Разработка? Нет смены культуры с создания value для бизнеса вместо технических задач.

Думаю эта настоящая экспертиза. Это хотелось бы развивать. Но желание в Компании отсутствует. 

Lean №11 - Поставляйте как можно быстрее

Зачем поставлять быстро?

1. Это нравится Заказчику. Чем быстрее покажешь, тем ему приятнее, тем быстрее он сможет использовать продукт.
2. Это снижает риски. Вы можете много закодировать, но пока это не в проде, вы не снимите все риски.
3. Это позволяет принимать решения как можно позже. Вместо того чтобы месяц думать над сложным решением, лучше показать через неделю и снизить уровень неопределенности, чтобы иметь возможность принять более правильное решение.

Что предлагается для этого:

1. Переход с Push системы на Pull. Всегда кажется что чтобы команда работала наиболее эффективно, необходимо микроменеджмент чтобы каждому говорить что ему нужно делать в каждый момент времени. Проблема в том что ИТ системы довольно сложны и комплексны, и четкий план мало вероятен. Лучше работает Pull система, основанная на сигналах и договоренностях. Для этого можно использовать:
1. Короткие итерации.
2. Визуальный контроль. Так как работа само-управляема, необходима визуализация того что происходит для всех. Burn-down chart, список проблем, список возможных рефакторингов, список идей для улучшений, статус сборок, статус тестов. Это все улучшает процесс само-организации. Нужно подумать как это можно улучшить сейчас.
2. Теория очередей. 
1. Необходимо постоянно оценивать время цикла и работать над тем чтобы его снизить. Время от начала грумминга истории до ее закрытия. Время от начала разработки истории с спринте, до ее установки на UAT стенд. 
2. Постоянная скорость прибытия работ. Скидки в ресторанах в дневное рабочее время, дешевый трафик по ночам. Все стараются избежать пиковых нагрузок и распределить их более равномерно. Не нужно выгружать все истории на тестирование в конце спринта - нужно стараться распределить поставку более равномерно. Не важно что вы много кодируете, если не успеваете это тестировать. Не важно много тестировать, если вы не успеваете выгружать это в прод.
3. Малые объемы работ. Чем меньше объем задачи, тем быстрее она пройдет весь процесс, тем меньше для нее будет время цикла. Тем быстрее ее можно будет протестировать и закрыть. Это позволяет распределить процесс тестирования по спринту более равномерно, и не сваливать его в самый конец.
4. Оценивайте объем работы, который ждет чтобы его выполнили. Он будет соотносится с временем цикла. Нужно посмотреть на все наши процессы более обще, со стороны.  
5. Чем больше вариативность времени прибытия работ или времени исполнения работ, тем выше будет время цикла и время ожидания работ. 
6. Чем больше объем работ, тем больше вариативность времени прибытия и исполнения (при чем не линейно). Из этого следует что более эффективно уметь разбивать User story для спринта на примерно одинаковый объем (оценку в points) чтобы сделать процесс более предсказуемым. Тогда время цикла будет меньше, ожиданий будет меньше, визуализация на Burn-down chart лучше.
7. Уменьшение вариативность в начале процесса оказывает больше влияния чем уменьшение вариативности в конце процесса.

Надо измерять и много думать. Можно использовать как одну из тем на ретроспективе.

Lean №10 - Простые правила

Решения принимаются на любом уровне. Не возможно предугадать все ситуации или все контролировать. Не возможно сформировать инструкции для всего. Потому предлагаются простые правила для принятия решений:

1. Удаляйте потери. Тратье время только на то^ что приносит Заказчику ценность (value).
2. Развивающее обучение. Если есть проблемы, увеличивайте feedback.
3. Принимайте решения как можно позже. Оставляйте варианты решений как можно дольше. 
4. Доставляйте как можно раньше. Доставляйте value Заказчику как можно раньше.
5. Заряжайте свою команду. Позвольте сотрудникам раскрыть весь свой потенциал.
6. Встраивайте целостность системы. Не пытайте достраивать целостность системы после, выстраивайте ее сразу.
7. Смотрите в целом. Не стоит оптимизировать части системы, только всю систему.

Это основные принципы Lean.

Lean №9 - Принятие решение в самый последний момент

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

Что предлагается для того чтобы это было возможно:

1. Не делайте дизайн системы в самом начале. Дизайн системы должен развиваться по мере того как мы больше узнаем про систему и требования к ней. 
2. Оптимизируйте процесс взаимодействия между теми что знает бизнес и тем кто знает код чтобы упростить внесение изменений в дизайн системы.
3. Любители пытаются сделать все правильно с первого раза. Эксперты выявляют ошибки до того как они приведут к проблемам.
4. Используйте объект-ориентированный дизайн и компонентную разработку. Например:
1. Используйте модули. Прячьте поведение внутри модуля, откладывайте дизайн модуля как можно дольше.
2. Используйте интерфейсы. Отделите интерфейсы от реализации.
3. Используйте параметры.
4. Используйте абстракции.    
5. Декларативное программирование, а не процедурное. Алгоритмы не должны зависеть от окружения.
6. Избегайте повторений кода - DRY. 
7. Модуль имеет одну, простую функцию. Поэтому метод по валидации объекта не должен менять содержимое этого объекта (чтобы оптимизировать лишний SQL запрос), Марат.
8. Инкапсуляция. Изменения не должны приводить к каскадными изменениям в других модулях.
5. Реализуйте максимально простое решение сейчас вместо того чтобы делать решение которое будет удовлетворять "будущим" потребностям. Завтра вы будете знать больше, потому завтра вы сделаете более крутое решение.
6. Избегайте лишних фич, добавляйте их лишь just-in-case. Любая фича - это потери на понимание, реализацию, тестирование, подддержку. НЕ бывает бесплатных фич.
7. Исследуйте то что критически важно бизнесу. Малое время формирования ответа. Когда тратить на него силы? В самом начале и потом поддерживать его до конца проекта, или оставить на завершение работ и сэкономить время? Это не ваше решение - это приоритет бизнеса. Если ему это критически важно - сделайте в самом начале, чтобы снизить риски изменения архитектуры в конце работ.
8. Чем медленнее ваша реакция на изменения, тем раньше вам нужно принимать решения. Чем быстрее вы можете менять код системы, тем больше вы сможете отложить решение.

 

Lean №8 - Вариантное принятие решений

Options Thinking.

Идеи:

1. Необходимо вариативное принятие решений. Формы заявлений были важным решением для Ruby системы. Мы выбрали спорное, не классическое решение без рассмотрения вариантов. Это стоит 1-2х недель переделки всех созданных форм. Текущие формы лучше, но может быть более лучше решение так как другие варианты мы не валидировали.
2. Откладывание необратимых решений как можно дальше дает большой экономический эффект
1. Лучше сами решения
2. Ниже риски
3. Снижение сложности системы
4. Снижение потерь
5. Более счастливые пользователи.
3. Старая парадигма - это предсказывающие процессы (ЧТЗ, ТехПроект). 
4. Новая парадигма - это адаптивные процессы. Мы даем пользователю возможность выбрать как можно позже. Но это не знает что в Agile и Lean мы ничего не планируем. Мы планируем, но в плане не специфицируются детально активности которые зависят от ситуации. Потому это Road Map, Story map и Product Backlog, а не диаграмма Ганта и ЧТЗ.

Lean №7 - Одновременная разработка

Смена мышления на парадигму по одновременной разработки

Идеи:

1. Одновременная разработка - это означает разработка "вширь" вместо парадигмы последовательной разработки "вглубь". Мы не пытаемся принять все технические решения по продукту сразу, максимально быстро. Мы итеративно поставляем продукт, стараясь открывать горизонт наших знаний максимально широко, чтобы принимать решение just-in-time обладая максимальным техническими знаниями. Мы ничего не знаем про offline-режим, и потому не закладываемся на него. Все что нам нужно - это аггресивный рефакторинг.
2. Но при этом в самом начале мы делаем самые главные пользовательские активности, основные User stories, валидируем критические архитектурные решения. Это нужно чтобы сформировать концептуальный дизайн продукта. Нужно показывать беклог команде и включать в него технические задачи на создание концептуального дизайна продукта.
3. Лучше закодировать фичу чтобы проверить, показать ее, чем вкладываться в проработку требований по фиче. Плохо, что нет мгновенного feedback для валидации любых фич.
4. Для Software свойственны потери связанные с внесением изменений. Изменения по некоторым типам ошибок после вывода на прод "стоят" в 1000 раз дороже чем тоже изменений на уровне концептуального дизайна. Архитектурные изменения могут стоить 100:1. Баги - 3:1 или 2:1. 
5. Последовательная разработка принимает решения как можно раньше, потому стоимость изменений высокая.
6. Одновременная разработка предлагает принимать решения как можно позже, что позволяет:
1. Уменьшить количество высоко уровневых ограничений. Эх, BPEL и редактирование регламентов услуг. Эх, Oracle DB.
2. Расширение горизонта знаний вширь позволяет принимать высоко уровненые решения более правильно.
3. Отодвигание принятия решений как можно позже уменьшает количество изменений. Эх, огромные сущности в протоколах и в БД. Полный waste.
4. Снизить стоимость изменений.
7. Lean мышление позволяет создавать дизайн систем, доступный для изменений. Это особенно необходимо для некоторых областей применений, где изменения могут проходить даже после успешного запуска продукта, и необходимо чтобы дизайн допускал внесение изменений и снижал их стоимость. 

Lean №6 - Разработка на ограничениях

Сложная тема про мышление через ограничения.

Идеи:

1. Сложно выполнить синхронизацию если все ее участники являются мастер-источниками данных. Когда есть Java-система которая накладывает условия по протоколам взаимодействия, а остальные их должны соблюдать, и нужно лишь убедиться что нет логических противоречий, то есть ошибок на бизнес-уровне - это одно. Но что если все участники могут накладывать условия. Нужно назначить встречу для 5х. Выбираешь время - кто-то не может. Выбираешь другое время - другой не может. В результате проходит много итераций. В этот момент люди интуитивно переходят на мышление через ограничения. Нужно собрать со всех их ограничения по времени (когда они могут), принять решение на основе этих ограничений и просто уведомить всех о выбранном времени. Количество итераций минимально.
2. В разработке я использую это следующим образом. 
1. Собираем все известные бизнес-требования, все value-feature которые есть/знаем в PBL
2. Вырабатывает технические решение 
3. Проверяем что оно удовлетворяет всех требованиям
4. Итеративно упрощаем его, проверяя что требования все еще проверяются
5. Результат - есть KISS решение. 
6. Например, версионность оЗАГС в Java проекте, иерархия организаций и ролевая модель в Ruby проекте
3. При принятии дорогих, критических решений - сформируйте несколько вариантов, сделайте их все, провалидируйте и примите решение. Ошибиться в конце и все переделать будет дороже.
4. Итерация - это одно из следствий такого подхода. Да, делаем только один, самый лучший по нашему мнению вариант, но чем быстрее покажем пользователю, тем быстрее провалидируем вариант, и сможем его изменить.
5. Критично. Дизайн системы должен быть доступен для внесения изменений.
6. Агрессивный рефакторинг - один из подходов внесения изменений, так изменений становятся дешевле. Если в Java проекте это уже 7-ая версия архитектуры - нужно жестко удалять все старые, ненужный куски кода. Они тянут вниз, тормозят разработку.
7. Код никогда не должен фризится.

    

Lean №5 - Синхронизация

Синхронизация важна для подхода когда нет четкого разделения зоны ответственности членов команды на отдельные области. То есть когда команда совместно делает какую-либо feature. Можно называть это Feature Driven Development, но по сути это общая практика для всего Agile мышления.

Идеи:

1. Для эффективной синхронной работы становится важным общее владение кодом. Потому мы используем git с дешевыми коммитами и merge. Потому мне так нравится GitHub и я готов его оплачивать. За месяц работы в GitHub код систем неожиданно стал публичным - его смотрят, его ревьюят, за него становится стыдно при fails. Хотя раньше был GitLab но в нем это было не интересно. Нужно продолжать вкладываться в коллективное владение кодом - это и качество продукта, и эффективность/скорость разработки.
2. Работа с git сейчас не достаточна эффективна. Возможно стоит найти публичные проекты на GitHub и посмотреть политику коммитов там для примера. Мы наверное сейчас на уровне SHU и нужно не строить свои регламенты, а начать с копирования хороших продуктов. 
3. Один из дешевых способов синхронизации команды - это CI. Красный билд - отличный показатель ошибки синхронизации усилий в части кода. 
4. Получается чем меньше коммит, тем меньше размер chunk, тем чаще синхронизация, тем меньше потерь на решение проблем синхронизации.
5. Чем чаще идет синхронизация веток в git, тем так же меньше потерь на решение проблем. Какой у нас регламент поднятия изменений из develop в feature-ветки? Почему Андрей фиксит тесты в develop, у Славы эти же тесты падают в своей ветки, он так же сам их фиксит, а потом нужно решать конфликты здесь? Почему feature-ветки такие огромные и включают в себя любые изменения которые разработчик решил сделать за время работы над feature, что в результате ни о какой синхронизации не может идти речи? И остается лишь один вариант - впихнуть потом это все в develop, полдня поднимать красные тесты и выдохнуть.   
6. Для синхронизации с внешними системами нужна тестовая система, которая эмулирует работу внешней и позволяет протестироваться интеграцию. Да, SoapUI решает можно проблем, но для эмуляции работы ведомства по межведу нужно было написать простую Web-форму чтобы визуализировать процесс. Это позволило бы протестировать не только протоколы и интеграцию, но и удобство работы с нашей системой по этим протоколам. ЭТО ВАЖНО! Почему мы сами не увидели проблему в межведе с тем что тип ответа должен быть известен заранее чтобы можно было сформировать ответ, подписать его человеком, и хранить для отправки по запросу. А вопрос удобства - это то самое Agile тестирование и Agile-тестировщик.
7. Вопрос интеграции и взаимодействия должен решаться первым чтобы как можно раньше выявить проблемы и риски, синхронизироваться и выполнять внутреннюю разработку компонент или систем независимо.

Lean №5 - Value Stream Mapping

Не получается провалидировать в боевом режиме - наши текущие процессы не имеют больших потерь по времени ожидания. Но идея понятна.

1. Берем процесс (или нужную часть процесса)
2. Бьем на активности, по исполнению которых есть результат
3. Считаем время исполнения активности (над чертой) и время ожидания (под чертой)
4. Используем 2 идеи
1. Канбан - общее время процесса должно быть минимально, потому думаем как сжать  весь процесс по ширине и минимизировать время ожидания (и внтуренние циклы - если они есть)
2. Принятие решений как можно позже. То есть процесс принятия решения должен быть как можно правее.
5. На картинке жизнь User story от инициации (разбивание Epic на мелкие User stories) до реализации.
6. Здесь в итоге решили
1. что не тратим время на User stories до grooming, на котором принимаем решение что US войдет в следующий спринт
2. не хватает время между Grooming и Workshop чтобы подготовить US
3. время между Workshop когда обсуждаем US и Planning когда берем их в работу должно быть минимально чтобы уменьшить вероятность изменения scope Spring Backlog
4. Потому сдвинули workshop на пятницу за 2 дня до демо/ретро/планирование

Lean №3 - Итерации

Итеративный подход является следствием Feedback практики. Чем меньше итерация, тем более быстрый feedback мы можем получить. Тем меньше потерь, быстрее сходятся точки зрения, мы более гибкие к изменениям.

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

Как следствие идеи на проверку

1. Просить feedback не только после ретроспективы но и после каждого events - планирование, grooming, workshop, daily, какие-то специфические встречи. Это позволит менять формат events в лучшую сторону - мы уже год мало что меняем в них. 
2. Помимо полугодовых аттестации в Компании проводить feedback встречи с сотрудниками (кто захочет) каждый месяц, например. Это было бы полезно. Но обычно никто не хочет развиваться. 

Идеи по Lean

1. 3 принципа итераций 
1. Исполнение работы маленькими порциями. Чем меньше порция результатов тем быстрее они проходят полный рабочий цикл. Если мы пытаемся тестировать все задачи спринта в конце спринта - это fail. Если дизайнер нарисовал прототипы сразу всех страниц и отгрузил их то любое замечание отправит большую часть его работы с корзину. Тоже самое с форматом требований, спеками, тестами и тп. 
2. Вариативный подход. Всегда реагируем на факты, а не полагаемся на наши планы. Нужно уметь подстаиваться, быть готовым к изменениями. 
3. Итерация - это точки синхронизации людей, команд и тп. Покажи продукт пользователю и синхронизируй vision. Покажи реализацию команде ASAP и у нее будет больше шансов тебя поправить. Провалидируй предположения с Impact mapping карты и меньше будет глобальных изменений 
2. "У Заказчика постоянно меняют требования - значит он не знает что он хочет - значит он идиот". Наоборот, это vision, понимание, точки зрения на продукт сходятся. И чем меньше итерация тем это дешевле стоит для команды. 
3. Изменяемый Scope работ - это хорошо. Это позволяет быстрее добится схождения точек зрения на продукт между Заказчиком и Исполнителем. Это позволяет реализовать только то что реально нужно, и то что не нужно будет удалено. 
4. "Но Scope не должен менятся во время спринта" - это уже задача PO и PO support team. Нужен root-cause анализ почему scope истории изменился во время спринта? Чаще всего это следствие плохой аналитики по истории, или не согласованности точек зрения на эту историю с Заказчиком или пользователем. 

Lean №2 - Feedback

Обратная связь - на мой взгляд, главная практика в Lean и Agile, внедрение которой дает burst-эффект. И этому мне нужно еще учится и учится.

Идеи

1. Пишите тесты как можно раньше. Быстрее команда разработки получит feedback по своим же изменениям в коде, и будет снижать технический долг
2. Вместо долгого планирования и разработки требований для разработчиков - просто напишите код и проверьте идею. Поэтому нет смысла делать ТЗ, ПМИ и ФТ для Ставрополя - пусть используют систему и говорят что еще им не хватает.
3. Вместо долгого сбора требований - покажите им примерный экран и получите по нему feedback. Делаем много дешевых mock-ups для сбора feedback на этапе сбора требований.
4. Вместо долгого изучения продуктов - выберите 3 лучших и протестируйте.
5. Всегда нужен НАСТОЯЩИЙ, МГНОВЕННЫЙ пользователь. Ростелеком и Минкомсвязь - это не пользователи, это заказчики. Наша главная беда всегда для всех проектов Электронного Правительства. Нужно биться в кровь за возможность общаться с Пользователем.
6. Чем меньше Feedback loop - тем лучше. Всегда. В любых случаях. Можешь показать реализацию story команде и РО - покажи. Можешь показать версию продукта Заказчику или пользователю - показывай. Можешь согласовать сложную спеку без полной реализации - согласовывай. Потому мы хотим показывать версию продуктов по завершению каждого спринта.

Feedback - самый простой и дешевый способ избежать потерь и повысить эффективность. А в условиях Startup (startup - это любой проект с высоким уровнем неопределенности. Потому почти любая разработка продукта - это startup) - это почти единственный способ успеха.

Хочешь стать лучше как разработчик, аналитик, тестировщик, менеджер - прости feedback у коллег.

Lean №1 - Удалить потери

Изучаю, внедряю, валидирую идеи Lean.

Смотрим на потери в продуктах.

1. Части продукта, которые не приносят Заказчику Value. 
1. Webadmin - нужен только нам для визуализации данных в Системе. Но потребляет усилия и время Ruby team. При переходе WebAdmin -> TechPortal value для Заказчика должен появится. Потому оставляем. Было бы полезно передать support на Java team и поставить кому из команды задачу на levelup по Ruby. 
2. Сложная структура БД, которая "стоит" нам больше чем нужно. Было бы полезно ее упроситить
3. Валидация документов-оснований. Фича, которую нужно было придумать на 3 года позже. Иначе тратим на это кучу времени
4. Протоколы. В рамках итеративного подхода протоколы были бы в 2 раза проще и доступнее. 
5. Выделение интеграционной части Service в отдельный компонент
2. Процессы, которые не являются прямой аналитикой и разработкой.
1. Разработка ДОКУМЕНТАЦИИ! 
2. Разработка подробного описания задач в Jira, которое никто не читает
3. Фиксирование знаний в Confluence, которые никто не читает
4. Работа с требованиями
5. Долгосрочное планирование
6. Работа с рисками в классическом плане (никогда ничем не помогала)  
7. Тесты, которые полезность которые ниже их стоимости.
8. Бесполезный Code Review 
9. Дорогой Code Checkstyle
10. То есть для всех Agile support практик необходимо понимать стоимость и оценивать их полезность, так как иначе возможно пустое следование канонам
3. Частично сделанная задача тормозит движение вперед.
1. Story, которую не смогли закрыть в этом спринте, и потому приходится закрывать в следующем не дает сильных потерь. Это прото плохо с точки зрения velocity, поставки продукта и как следствие fast feedback
2. Проблема с задачами, которые были частично сделаны и отложены на месяц и более. Фактически огромные затраты на решение задачи по merge всех типов объектов делают огромные же затраты на save всех типов объектов в прошлом году БОЛЬШИМИ ПОТЕРЯМИ. То что в том году задача не была сделана в нужном объеме делает ее бесполезной, так как сейчас почти вся логика была переписана.
3. При этом отложение решения проблем с merge и реализация merge всех типов до конца может привести к тому же глобальному рефакторингу позже.     
4. Extra фичи, которые Заказчику не нужны, но которые мы считаем ВАЖНЫМИ так как нам виднее. Для этого необходима валидация связи от feature к цели продукта с помощью Impact mapping. Если мы не можем построить эту связь - значит это waste. Хотя если нужно мы построим - видимо нужна валидация этой связи с помощью Заказчика.
5. Переключение между задачами. Возможно ли было делать задачи между 2-мя Ruby проектами полностью раздельно? В разных спринтах. Подумать в следующий раз.
6. Любые ожидания.
1. Ожидание процесса сборки - мерить и оптимизировать периодически
2. Ожидания тестов - выделять самые долгие тесты и оптимизировать по 2 теста за спринта, добавить в Craftsmanship как Silver метрику 
3. Ожидание mock-up интерфейсов - делать их на спринт вперед, делегировать процесс с команды разработки на PO support team 
4. Согласование АС тестов - сейчас гораздно быстрее когда все спеки уже написаны и согласованы. 
7. Долгие activity-процессы
1. Сколько времени уходит на получение ответа у аналитика? Сейчас вроде бы не долго
2. Сколько действий нужно совершить чтобы увидеть какие тесты упали?
3. Сколько действий нужно сделать чтобы найти причину красного теста? Судя по fixing time долго
4. Ненужная авторизация. Сделать auth-links так же для Webadmin 
5. Сколько времени "стоит" git за одну задачу? Нужен ли gitflow? Для меня GitHub for Mac приложение делает работу с git дешевым.
8. Bugs, которые тормозят разработку. Много в Ruby. Нужен root-cause анализ чтобы стопать весь конвеер и решать причину багов. 
9. Лишний, дорогой менеджмент. Не вижу потерь - текущие процессы мало формализованы и дешевы по времени.   

Интересная риторика:

1. Если документы никто не ждет (команда разработки), значит они бесполезны
2. Если вы не можете поддерживать базу знаний в актуальном состоянии, значит ее никто не использует.