Осторожно с аналогиями. Lean и TOC в разработке.
Из ленты: enter-agile.com
Автор: Александр Якима.
Подходы Lean и TOC (Theory Of Constraints — Теория Ограничений) весьма популярны в разработке ПО. Особенно Lean в последние несколько лет. Самый яркий последний пример — это Kanban. Модно по самое «немогу». И полезно тоже, однако как повествует известный анекдот о героях романа Д. А. Фурманова: «но есть нюансы…»
Кстати, это типичная болезнь современной теоретической науки, математики, например… Строим модель действительного феномена, не сильно заботясь о ее адекватности, а потом наворачиваем на этом неимоверный теоретический аппарат (так как получившуюся систему дифф-уравнений придется решить или, скажем, группу симметрических преобразований кристалла полностью описать). И все прекрасно работает… для статей и диссертаций. И в большинстве случаев не подразумевает ни единого случая применения! …А может это и хорошо.
Итак, наша основная «модель», используемая в Lean — это производство. Автомобилей, привычно, так как Lean принято считать методологическим продуктом Toyota. Возможны и дроугие (эквивалентные) аналогии: например, кухня в ресторане «производит» блюда и т.д. В случае с разработкой ПО, аналогией «автомобилей» (или «блюд») являются фичи продукта, которые похожим образом «проходят сквозь производство» и заканчиваются готовой функциональностью. Много в чем эта модель позитивна, например в идее ограничения работы в прогрессе или постоянном стремлении уменьшить Lead Time — общее время от «заказа фичи» до ее «доставки». Но есть и серьезные концептуальные отличия. Вот основное из них:
Все фичи, проходящие сквозь систему, физически связаны друг с другом, в отличие от автомобилей или супов и стейков в ресторане.
Чтобы было еще очевиднее, приведем пример. Представим ресторан, весь вечер готовящий и непрерывно доставляющий блюда на столы. Приходят и уходят клиенты, поступают и выполняются новые заказы, съедаются новые и новые тарелки с изысканными яствами. Но вдруг у одного из поваров образовалась проблема — случайно, в спешке, он солит суп из лобстера дважды. Естественно, он ничего не подозревает, но знает, что попробует блюдо перед тем, как отдавать его официанту — таковы правила у них на кухне. Но происходит странное — через минуту у повара за соседней плитой шок — соус к его стейку ужасно пересолен. То же самое у третьего, который тушил рыбу… она тоже оказалась пересоленой. Как так? Ведь они работают независимо. Такого не может быть. И действительно, такого не может произойти в ресторане, но именно это постоянно происходит в разработке ПО, потому что…
все фичи реализовываются в одной и той же системе и связаны друг с другом физически.
Другой важный отличительный ньюанс — каждая фича уникальна, абослютно каждая. По ней нет и не может наперед существовать избитого тех-процесса, как это имеет место для тех или иных марок автомобилей, например, или блюд в ресторане. Большая степень новизны и неопределенности постоянно дышит в затылок команде разработчиков, что бы они не разрабатывали и как похоже бы это не звучало на то, что они уже делали раньше.
Поэтому уже надо быть осторожным. Использовать аналогию с производством можно и нужно, но всегда помнить, что такая модель очень приблизительна.