Что такое Adaptation¶
Автор раздела: Ivan Zakrevsky
Суть Адаптации¶
📝 "No crystal balls. Humans are not able to predict the future. For example, your competition makes an announcement that was not expected. Unanticipated technical problems crop up that force a change in direction. Furthermore, people are particularly bad at planning uncertain things far into the future – guessing today how you will be spending your week eight months from now is something of a fantasy. It has been the downfall of many a carefully constructed Gantt chart."
—"Jeff Sutherland's Scrum Handbook" by Jeff Sutherland
📝 "Глаза боятся - руки делают."
—Народная пословица.
Суть Adaptation (Адаптации) заключается в том, что мы не пытаемся разрешить неопределенность заблаговременно путем логического вывода, а, в противовес Prediction, разрешаем неопределенность опытным, экспериментальным путем (широко известным как "метод научного тыка" 🙂️). Выдвигаем гипотезу, вносим её в план, реализуем Системный Инкремент, инспектируем результат на практике, и адаптируем план на следующую итерацию. Этот цикл образует итерацию.
Полученные практическим способом знания, снижающие неопределенность, являются входными аргументами для следующей итерации.
📝 ""Iteration" here means applying a function to itself."
—"Concrete Mathematics: A Foundation for Computer Science" 2nd edition by Ronald L. Graham, Donald E. Knuth, Oren Patashnik
Как сказал Томас Эдисон: «Я не терпел поражений. Я просто нашёл 10 000 способов, которые не работают».
Назначение Адаптации¶
Рость неопределенности приводит к росту стоимости Prediction по мере роста его точности. Предел экономической целесообразности Prediction определяется пересечением графика роста стоимости Prediction (в зависимости от его точности) с графиком роста бизнес-выгод от точности Прогнозирования.
Там, где сумма произведений количества Адаптаций Системного Инкремента на стоимость Адаптации системного инкремена для каждой итерации пересечет сумму экономически целесообразной стоимости Prediction на горизонте планирования, возникает предел экономической целесообразности эмпирического способа обработки неопределенности Проекта при допущении, что остаточная стоимость самой реализации (которая не имеет отношения к разрешению неопределенности) остается неизменной в обоих случаях. Обратите внимание, в данном случае речь идет о стоимости Адаптации Системного Инкремента, а не Плана. Т.е. речь идет о стоимости экспериментального разрешения неопределенности (цикл ошибка - исправление).
Prediction при этом не исчезает полностью, а понижает свою точность и дополняется Адаптацией. Для наилучшего совокупного экономического эффекта важно правильно находить баланс между Prediction и Adaptation, а также обеспечивать характер роста стоимости Adaptation максимально приближенный к горизонтальной асимптоте, поскольку, чем больше Адаптаций Системного Инкремента возникает на горизонте планирования, тем дороже становится экспериментальный способ разрешения неопределенности по сравнению с логическим.
При этом нужно учитывать, что стоимость Prediction также не константна по отношению к жизненному циклу системы, а имеет тенденцию к понижению. Т.е. чем большая часть системы уже реализована, тем больше баланс экономической целесообразности смещается от Adaptation к Prediction.
FIGURE 3.6 Make decisions at the last responsible moment. The image source is "Essential Scrum: A Practical Guide to the Most Popular Agile Process" by Kenneth Rubin, "Chapter 3 Agile Principles :: Prediction and Adaptation".¶
📝 "Most of us would prefer to wait until we have more information so that we can make a more informed decision. When dealing with important or irreversible decisions, if we decide too early and are wrong, we will be on the exponential part of the cost-of-deciding curve in Figure 3.6. As we acquire a better understanding regarding the decision, the cost of deciding declines (the likelihood of making a bad decision declines because of increasing market or technical certainty). That's why we should wait until we have better information before committing to a decision."
—"Essential Scrum: A Practical Guide to the Most Popular Agile Process" by Kenneth Rubin, "Chapter 3 Agile Principles :: Prediction and Adaptation"
Это и есть та самая причина, по которой выбор SDLC-модели является неотъемлемой частью процесса проектирования, и изучается архитектурой. Ведь различные SDLC-модели (итеративные, инкрементальные, спиральные, гибридные, каскадные), реализованные в виде Scrum, RUP, SAFe, BDUF etc., обладают различным соотношением Prediction vs. Adaptation, имеют разные подходы к масштабированию команд и различные ограничения. Выбор SDLC-модели сильно зависит от ситуативного контекста проектирования. Повторюсь, основная цель итеративной разработки - удешевить стоимость проектирования в условиях неопределенности.
Об этом Брукс писал в Мифическом человеко-месяце еще до появления Agile Manifesto:
📝 "Therefore the most important function that software builders do for their clients is the iterative extraction and refinement of the product requirements...
I would go a step further and assert that it is really impossible for clients, even those working with software engineers, to specify completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product they are specifying.
Therefore one of the most promising of the current technological efforts, and one which attacks the essence, not the accidents, of the software problem, is the development of approaches and tools for rapid prototyping of systems as part of the iterative specification of requirements."
—"The Mythical Man-Month Essays on Software Engineering Anniversary Edition" by Frederick P. Brooks, Jr.
💬 Furthermore, a waterfall approach forces us into a predictive style of planning, it assumes that once you are done with a phase, such as requirements analysis, the resulting deliverable is a stable platform for later phases to base their work on. In practice the vast majority of software projects find they need to change their requirements significantly within a few months, due to everyone learning more about the domain, the characteristics of the software environment, and changes in the business environment. Indeed we've found that delivering a subset of features does more than anything to help clarify what needs to be done next, so an iterative approach allows us to shift to an adaptive planning approach where we update our plans as we learn what the real software needs are.
These are the major reasons why I've glibly said that "you should use iterative development only in projects that you want to succeed".
—"Waterfall Process" by Martin Fowler
Конечно, сугубо семантически, термин "requirements" немного вводит в заблуждение в Agile, ведь заранее требования к продукту неизвестны полностью, и они изменяются по мере реализации продукта. А в таком случае, как они могут что-то требовать? Вы, наверное, встречали картинку с треугольником "Iron Triangle" (Requirements/Scope, Cost, Time), где в waterfall он обращен вершиной Requirements вниз (константная область), а в Agile - вверх (переменная область). The iron triangle of planning:
Iron Triangle. Agile fixes the date and resources and varies the scope. The image source is "Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise" by Dean Leffingwell¶
Итеративная разработка востребована, когда невозможно достигнуть полноты (Complete) требований (set of requirements).
📝 "Agile methods are most valuable when we're dealing with high levels of uncertainty."
—"Agile and Architecture: Friend, not Foe" by Gregor Hohpe
📝 "Complete. The set of requirements stands alone such that it sufficiently describes the necessary capabilities, characteristics, constraints or quality factors to meet entity needs without needing further information. In addition, the set does not contain any To Be Defined (TBD), To Be Specified (TBS), or To Be Resolved (TBR) clauses. Resolution of the TBx designations may be iterative and there is an acceptable timeframe for TBx items, determined by risks and dependencies."
—"ISO/IEC/IEEE 29148:2018 Systems and software engineering - Life cycle processes - Requirements engineering"
Но это и не требуется стандартом по SDLC:
📝 "To deal with the issues of incompletely known requirements and inaccurate estimates, a number of other types of models have been proposed: incremental, spiral, iterative, and evolutionary (adaptive).
<...>
The "evolutionary model" is intended to deal with incomplete knowledge of requirements."
—"ISO/IEC/IEEE 12207:2017 Systems and software engineering - Software life cycle processes"
Как можно заметить, неполнота требований здесь первична, и именно для её разрешения и применяются такие SDLC-модели, как incremental, spiral, iterative, and evolutionary (adaptive).
Интересно, что, во времена появления термина User Story, полнота требований так же не требовалась старым стандартом:
📝 "The SRS may need to evolve as the development of the software product progresses. It may be impossible to specify some details at the time the project is initiated.
<...>
Requirements should be specified as completely and thoroughly as is known at the time, even if evolutionary revisions can be foreseen as inevitable. The fact that they are incomplete should be noted."
—"IEEE Std 830-1998, IEEE Std 830-1993 IEEE Recommended Practice for Software Requirements Specifications"
Таким образом, использование термина requirements, несмотря на то, что вызывает вопросы относительно семантики, никоим образом не противоречит использованию его в Agile SDLC-моделе, которая, кстати, описана тем же стандартом - ISO/IEC/IEEE 12207:2017, в разделах "5.4.2. Life cycle model for the software system" и "Annex H".
Немножко о продуктовом подходе¶
💬 Product-mode: For building, running and iterating on the solution or even pivoting to a different solution till the underlying problem is verifiably solved.
💬 To migrate to product-mode, it is best to adopt an iterative and fail cheap approach. Start with a pilot or two, learn and adapt. Although it may feel unsound to those who are used to approving big change programs with detailed roadmaps, it is the essence of a Lean-Agile mindset to avoid overinvesting before validating actual (not projected) benefits.
💬 Product-mode: Product owners prove actual benefits either with data from A/B testing, analytics, user surveys, etc. or with feedback from business. This ability is dependent on good engineering capability to develop and release frequently in small chunks and good analytics capability to determine delta changes in adoption, conversion etc.
There is relatively less emphasis on assessing projected benefits upfront, especially amongst the best such teams that execute with short cycle times and can therefore try new ideas without incurring a high cost of failure. The product owner is empowered to approve development of roadmap items as they see fit. By developing in small, end-to-end iterations, product owners are able to detect early any efforts that miss the mark and thereby fail-fast (fail-cheap).
—"Products Over Projects" by Sriram Narayan
Причем здесь refactoring?¶
💬 I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.
—"Ward Explains Debt Metaphor" by Ward Cunningham
💬 McConnell writes, "In ten years the pendulum has swung from 'design everything' to 'design nothing.' But the alternative to BDUF [Big Design Up Front] isn't no design up front, it's a Little Design Up Front (LDUF) or Enough Design Up Front (ENUF)." This is a strawman argument. The alternative to designing before implementing is designing after implementing. Some design up-front is necessary, but just enough to get the initial implementation. Further design takes place once the implementation is in place and the real constraints on the design are obvious. Far from "design nothing," the XP strategy is "design always."
—"Extreme Programming Explained" 2nd edition by Kent Beck
См. также:
"The New Methodology :: Predictive versus Adaptive" by Martin Fowler
См.также
