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 дня до демо/ретро/планирование

Идея №38. Бизнес

Новая идея для валидации. Попал на сайт - http://game.molodost.bz/ и http://molodost.bz/entry/
Сделал те же самые выводы что и неделей ранее

1. Нужно ставить больше целей - здесь это 10 одновременных целей за 3 месяца
2. Цели должны быть более амбициозные, сложные, valuable

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

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 у коллег.

Книга - Экстремальный тайм-менеджмент / Николай Мрочковский

Прочел книгу "Экстремальный тайм-менеджмент" - было интересно.

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

Там немного глав и немного советов. С частью из них я не согласен. Но пару идей оттуда взял.

В Agile Result идет фокус на 3 цели в году, 3 цели за месяц и тп. Это реально работает и цель на год про Agile-мышление исполняется очень уверенно. Но все остальные сферы жизни (Hot spots согласно Agile results) остаются без внимания. 

После прочтения я (хочу адаптировать это к Agile Results) решил:

1. вкладываться в развитие равномерно сразу по всем сферам жизни и брать сразу много целей в работу на месяц (но они будут не Focus цели)
2. вкладываться в Творчество и Яркость жизни (или Fun у меня). Стыдно что я все еще не умею кататься на роликах, на серфе, так и не пробовал рисовать на планшете. Куча всего чем хотелось бы занятся.
3. ставить более амбициозные цели. 

Сейчас читаю "The Power of Full Engagement. Managing Energy, Not Time, is the Key to High Performance and Personal Renewal"

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

Это TRUE - буду изучать и валидировать идеи.

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. Если вы не можете поддерживать базу знаний в актуальном состоянии, значит ее никто не использует. 

Craftsmanship / Мастерство

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

Я взял 3 практики: 

1. Software Craftsmanship (http://en.wikipedia.org/wiki/Software_craftsmanship) как общую идею, слоган
2. http://en.wikipedia.org/wiki/Gamification. В геймификацию проектов я не верю, но для развития навыков - хочу проверить 
3. Ожидания от своих сотрудников на следующую аттестацию, как советует HR департамент Компании чтобы сделать процесс оценки и повышения ЗП более предсказуемым. (Ранее фиксировать произвольные ожидания у меня не получилось - они устаревают, плохо формализуются и неоднозначно оцениваются.)  

В рамках этой идеи я взял набор областей, в каждой области набор практик и для каждой практики 3 уровня мастерства с набором метрик. 

Здесь текущее описание практик (нужно перейти по табам) 
Здесь область по разработке 

В результате ожидания на следующую аттестацию трансформируются в набор ожидаемых уровней мастерства по интересуемым практикам.

Сейчас описаны практики - те, что интересны сейчас нам + те, что я зафиксировал как ожидания у кого-то из своих сотрудников. Большинство практик еще не валидировал.