В предыдущем посте просматривается противоречие, которое заключается в том, что для того, чтобы снизить стоимость разработки, нам необходимо повысить точность прогнозирования (повысить полноту требований), но повышение точности прогнозирования, в свою очередь, повышает стоимость разработки (возникает отрицательная обратная связь).
Причем, как уже упоминалось ранее, повышает её экспоненциально, в то время как бизнес-выгоды от этой точности возрастают логарифмически.
Мы не можем повышать точность прогнозирования, т.к. она превысит предел экономической целесообразности, но мы вынуждены её повысить для того, чтобы принимать решения в момент наименьшей стоимости их реализации.
Как можно разрешить этот "Catch-22"? Согласно "Первому закону диалектики", противоречие должно привести к синтезу, т.е. к качественному изменению.
И решение этого противоречия схоже с решением противоречия "Закона Брукса", в виде автономных команд. Или же с решением в виде Bounded Context, которое разрешает противоречие, заключающееся в том, что при стремлении выровнять язык по всей модели, он стремится к противоречивости (и неоднозначности). Т.е. стремление следовать предметной области вынуждает отступать от неё. В нашем случае решение так же заключается в разбиении целого (процесса разработки) на части (итерации), только вместо согласованности единого языка здесь критерием разделения выступает достаточность полноты требований.
Однако, согласно "Второму закону диалектики", качественные изменения происходят в результате количественных изменений.
Скачкообразное изменение состояния называется в философии "революцией" (коренной смысл этого термина далек от политики), и именно на это намекает заголовок статьи "The Winter Getaway That Turned the Software World Upside Down" By Caroline Mimbs Nyce - одного из участников встречи 2001 года по Agile Manifesto.
Осталось отыскать эти количественные изменения, что станет темой следующего поста.
#SDLC #Agile
Причем, как уже упоминалось ранее, повышает её экспоненциально, в то время как бизнес-выгоды от этой точности возрастают логарифмически.
Мы не можем повышать точность прогнозирования, т.к. она превысит предел экономической целесообразности, но мы вынуждены её повысить для того, чтобы принимать решения в момент наименьшей стоимости их реализации.
Как можно разрешить этот "Catch-22"? Согласно "Первому закону диалектики", противоречие должно привести к синтезу, т.е. к качественному изменению.
И решение этого противоречия схоже с решением противоречия "Закона Брукса", в виде автономных команд. Или же с решением в виде Bounded Context, которое разрешает противоречие, заключающееся в том, что при стремлении выровнять язык по всей модели, он стремится к противоречивости (и неоднозначности). Т.е. стремление следовать предметной области вынуждает отступать от неё. В нашем случае решение так же заключается в разбиении целого (процесса разработки) на части (итерации), только вместо согласованности единого языка здесь критерием разделения выступает достаточность полноты требований.
Однако, согласно "Второму закону диалектики", качественные изменения происходят в результате количественных изменений.
Скачкообразное изменение состояния называется в философии "революцией" (коренной смысл этого термина далек от политики), и именно на это намекает заголовок статьи "The Winter Getaway That Turned the Software World Upside Down" By Caroline Mimbs Nyce - одного из участников встречи 2001 года по Agile Manifesto.
Осталось отыскать эти количественные изменения, что станет темой следующего поста.
#SDLC #Agile