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