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