Осторожно с аналогиями. Lean и TOC в разработке.

Автор: Александр Якима.

Подходы Lean и TOC (Theory Of Constraints - Теория Ограничений) весьма популярны в разработке ПО. Особенно Lean в последние несколько лет. Самый яркий последний пример - это Kanban. Модно по самое "немогу". И полезно тоже, однако как повествует известный анекдот о героях романа Д. А. Фурманова: "но есть нюансы..."

Кстати, это типичная болезнь современной теоретической науки, математики, например... Строим модель действительного феномена, не сильно заботясь о ее адекватности, а потом наворачиваем на этом неимоверный теоретический аппарат (так как получившуюся систему дифф-уравнений придется решить или, скажем, группу симметрических преобразований кристалла полностью описать). И все прекрасно работает... для статей и диссертаций. И в большинстве случаев не подразумевает ни единого случая применения! ...А может это и хорошо.

Итак, наша основная "модель", используемая в Lean - это производство. Автомобилей, привычно, так как Lean принято считать методологическим продуктом Toyota. Возможны и дроугие (эквивалентные) аналогии: например, кухня в ресторане "производит" блюда и т.д. В случае с разработкой ПО, аналогией "автомобилей" (или "блюд") являются фичи продукта, которые похожим образом "проходят сквозь производство" и заканчиваются готовой функциональностью. Много в чем эта модель позитивна, например в идее ограничения работы в прогрессе или постоянном стремлении уменьшить Lead Time - общее время от "заказа фичи" до ее "доставки". Но есть и серьезные концептуальные отличия. Вот основное из них:

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

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

все фичи реализовываются в одной и той же системе и связаны друг с другом физически.

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

Поэтому уже надо быть осторожным. Использовать аналогию с производством можно и нужно, но всегда помнить, что такая модель очень приблизительна.

No comments:

Post a Comment

 
Powered by Blogger