Merge pull request #141 from emacsway/emacsway

Emacsway

emacsway/it/sdlc/models/agile/agile.rst

@@ -199,7 +199,7 @@ Agile является естественным следствием эволю
 
     -- "Clean Agile: Back to Basics" by Robert C. Martin
 
-Kent Beck выяснил, что напряжение являлось ни чем иным, как упреждающими защитным механизмом, спровоцированным страхами участников процесса разработки.
+Kent Beck выяснил, что напряжение являлось ни чем иным, как упреждающими защитным механизмом, спровоцированным страхами обоих сторон процесса разработки.
 
 Идея Bill of Rights возникла на основе идеи Declaration of Independence (`перевод <http://www.hist.msu.ru/ER/Etext/indpndnc.htm>`__):
 
@@ -475,6 +475,29 @@ Impossible. Точка.
     -- "`The New Methodology <https://www.martinfowler.com/articles/newMethodology.html>`__" by Martin Fowler
 
 
+Пример
+------
+
+..
+
+    💬 I had a chance to witness the pitfalls of this trap firsthand.
+    Working with Nokia, I noticed that management was measuring the success of its digital transformation by how many people were trained on Agile software development methodologies and were onboarded onto Agile tools.
+    These activity-based proxy metrics had nothing to do with business outcomes.
+    As I will summarize in Part I, Nokia’s transformation efforts failed to address the core platform problems that made it so **difficult for the company to adapt to the changing market**.
+    In spite of what appeared to be a well-planned transformation, management was not able to realize this until too late.
+    I watched with frustration as Nokia lost the mobile market it had created, in spite of the heroic efforts of my colleagues, who were doing everything they could to save the company.
+
+    ...
+
+    Even if the teams had attained a theoretical ideal of agility, would Nokia have been **able to adapt more quickly** without upstream changes to how the business was measuring delivery?
+    Or **adapt** downstream changes in how the software was deployed? Or the **architecture changes that were slowing developers down in the first place**?
+    In my opinion, that narrow-minded and activity-oriented view of Agile was the root cause of Nokia’s failed digital transformation.
+    The failed transformation made fast iteration and learning from the market impossible, as the lead times for delivering new features, such as an app store and an elegant home screen, were far too slow.
+    This hindered the business’s ability to learn and adapt, and that inability to adapt was a key factor in Nokia’s downfall.
+
+    -- "Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework" by Mik Kersten
+
+
 Cм. также:
 
     - "`Writing The Agile Manifesto <https://martinfowler.com/articles/agileStory.html>`__" by Martin Fowler

emacsway/it/sdlc/models/agile/analysis/requirements/requirements.rst

@@ -60,6 +60,12 @@ Product Backlog Item и Requirements
 
 Актуальная версия Agile-расширения BABoK (на момент написания статьи) - вторая, хотя актуальная версия самого BABoK - третья.
 
+    💬 "The unit of requirements gathering is the "user story," user-visible functionality that can be developed within one iteration."
+
+    -- "Agile Software Development" by Alistair Cockburn
+
+..
+
     📝 "The **Product Backlog** is a list of **functional and nonfunctional requirements** that, when turned into functionality, will deliver this vision."
 
     -- "Agile Project Management with Scrum" by Ken Schwaber

emacsway/it/sdlc/models/iterative.rst

@@ -26,7 +26,15 @@ Iterative Development
 
 ..
 
-    📝 ""Iteration" here means applying a function to itself."
+    💬 If you run into a dead end in one of the areas, **iterate**!
+    Incremental refinement is a powerful tool for managing complexity.
+    As Polya recommended in mathematical problem solving, understand the problem, devise a plan, carry out the plan, and then look back to see how you did [Polya 1957].
+
+     -- "Code Complete" 2nd edition by Steve McConnell
+
+..
+
+    💬 ""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
 

emacsway/it/sdlc/uncertainty-management/adaptation/adaptation.rst

@@ -41,6 +41,8 @@
 
     -- "Concrete Mathematics: A Foundation for Computer Science" 2nd edition by Ronald L. Graham, Donald E. Knuth, Oren Patashnik
 
+Как сказал Томас Эдисон: «Я не терпел поражений. Я просто нашёл 10 000 способов, которые не работают».
+
 
 Назначение Адаптации
 ====================
@@ -157,6 +159,43 @@ Prediction при этом не исчезает полностью, а пони
 Таким образом, использование термина :ref:`requirements <emacsway-agile-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 <https://martinfowler.com/articles/products-over-projects.html>`__" 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 <http://wiki.c2.com/?WardExplainsDebtMetaphor>`__" 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 <https://www.martinfowler.com/articles/newMethodology.html#PredictiveVersusAdaptive>`__" by Martin Fowler

emacsway/it/sdlc/uncertainty-management/adaptation/software-construction/yagni.rst

@@ -173,6 +173,12 @@ Martin Fowler о выборе момента реализации проектн
 
     -- "`Yagni <https://martinfowler.com/bliki/Yagni.html>`__" by Martin Fowler
 
+.. seealso::
+
+   - "`Определите свои классы обслуживания с помощью Триаж Таблиц <https://kanbanguide.ru/opredelite-svoi-klassy-obsluzhivaniya-s-pomoshhyu-triazh-tablicz-podcast-kanban-talks-epizod-%E2%84%96-7/>`__" Podcast "Kanban talks" Эпизод № 7. Алекс Цыбульник
+   - "`Classes of Service: The Everyday Concept That Can Turbocharge Your Kanban <https://djaa.com/classes-of-service/>`__" by Anna Radzikowska
+   - "Successful Evolutionary Change for Your Technology Business" by David J. Anderson, chapter "Chapter 11: Establishing Service Level Agreements :: Typical Class-of-Service Definitions"
+
 
 В каких случаях момент реализации не стоит откладывать
 ======================================================

emacsway/it/sdlc/uncertainty-management/adaptation/software-design/simplicity.rst

@@ -73,6 +73,12 @@ Role of Simplicity in Agile
 
     -- И.Е. Репин
 
+..
+
+    💬 Simplicity is the ultimate sophistication.
+
+    -- Leonardo da Vinci
+
 
 Единица измерения
 =================

emacsway/it/self-education/self-education-for-software-engineer.rst

@@ -891,6 +891,11 @@ Donald E. Knuth:
 
 - "`How Do Story Points Relate to Hours? <https://www.mountaingoatsoftware.com/blog/how-do-story-points-relate-to-hours>`__" by Mike Cohn
 
+Оценка - это не единичное значение, а вероятностная распределённость:
+
+- YOW! 2016 Robert C. Martin - "`Effective Estimation (or: How not to Lie) <https://youtu.be/eisuQefYw_o>`__"
+- "`How to Read Lead Time Distribution <https://www.mauvisoft.com/2020/10/08/how-to-read-lead-time-distribution/>`__" by Mauvisoft Team
+
 
 Функциональное программирование
 -------------------------------

emacsway/it/team-topologies/harlan-mills'-proposal.rst

@@ -120,7 +120,7 @@ Frederick Brooks формулирует противоречие. С одной
 
     Дополнительная нагрузка состоит из двух частей — обучения и обмена данными. Каждого работника нужно обучить технологии, целям проекта, общей стратегии и плану работы. Это обучение нельзя разбить на части, поэтому данная часть затрат изменяется линейно в зависимости от числа занятых.
 
-    **С обменом данными дело обстоит хуже. Если все части задания должны быть отдельно скоординированы между собой, то затраты возрастают как n(n-2)/2. Для трех работников требуется втрое больше попарного общения, чем для двух, для четырех — вшестеро. Если помимо этого возникает необходимость в совещаниях трех, четырех и т.д. работников для совместного решения вопросов, положение становится еще хуже. Дополнительные затраты на обмен данными могут полностью обесценить результат дробления исходной задачи и привести к положению, описываемому рисунком 2.4.**
+    **С обменом данными дело обстоит хуже. Если все части задания должны быть отдельно скоординированы между собой, то затраты возрастают как n(n-1)/2. Для трех работников требуется втрое больше попарного общения, чем для двух, для четырех — вшестеро. Если помимо этого возникает необходимость в совещаниях трех, четырех и т.д. работников для совместного решения вопросов, положение становится еще хуже. Дополнительные затраты на обмен данными могут полностью обесценить результат дробления исходной задачи и привести к положению, описываемому рисунком 2.4.**
 
     .. figure:: _media/harlan-mills'-proposal/fig-2.4-task-with-complex-interrelationships.png
        :alt: Рис. 2.4 Зависимость времени от числа занятых — задача со сложными взаимосвязями. Fig. 2.4 Time versus number of workers—task with complex interrelationships. The image source is "The Mythical Man-Month Essays on Software Engineering Anniversary Edition" by Frederick P. Brooks, Jr., "Chapter 2 The Mythical Man-Month", перевод ООО Издательство "Питер".
@@ -141,7 +141,7 @@ Frederick Brooks формулирует противоречие. С одной
 
     The added burden of communication is made up of two parts, training and intercommunication. Each worker must be trained in the technology, the goals of the effort, the overall strategy, and the plan of work. This training cannot be partitioned, so this part of the added effort varies linearly with the number of workers.
 
-    **Intercommunication is worse. If each part of the task must be separately coordinated with each other part/ the effort increases as n(n-I)/2. Three workers require three times as much pairwise intercommunication as two; four require six times as much as two. If, moreover, there need to be conferences among three, four, etc., workers to resolve things jointly, matters get worse yet. The added effort of communicating may fully counteract the division of the original task and bring us to the situation of Fig. 2.4.**
+    **Intercommunication is worse. If each part of the task must be separately coordinated with each other part/ the effort increases as n(n-1)/2. Three workers require three times as much pairwise intercommunication as two; four require six times as much as two. If, moreover, there need to be conferences among three, four, etc., workers to resolve things jointly, matters get worse yet. The added effort of communicating may fully counteract the division of the original task and bring us to the situation of Fig. 2.4.**
 
     Since software construction is inherently a systems effort—an exercise in complex interrelationships—communication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning. Adding more men then lengthens, not shortens, the schedule."
 
@@ -553,6 +553,18 @@ Scrum of Scrums
 См. также структуру "Scrum of Scrum Team (SoS) a Core Team" на странице 5 "`The Scrum Software Factory <https://www.scrumatscale.com/wp-content/uploads/2020/09/Scrum_At_Scale_Case_Study_Air_Transport_Amogh.pdf>`__" by Amogh Joshi.
 
 
+Early Scrum
+-----------
+
+    The first keynote speaker was Ken Schwaber. Ken and Jeff Sutherland are the authors and founders of the Scrum agile methodology. Ken started by describing his experiences working with Scrum on large projects and several techniques he had successfully used in the early stages of the project life cycle.
+
+    Ken explained on one project how the team was very concerned with getting the overall architecture of the system proven in the early stages of development. Early project iterations (sprints in Scrum terminology) contained stories focused on proving the system architecture peppered with several real business cases. After several iterations, during which the architecture was continuously refined and tested, the team had a good sense of whether the architecture was sufficient for the demands of the business.
+
+    Scaling was then achieved by starting new teams with the founders of the original architecture team. With most of the architectural issues addressed, the new teams could focus on implementing business logic on top of the then stable architecture.
+
+    -- "`Canadian Workshop on Scaling XP/Agile Methods <https://martinfowler.com/articles/canScaling.html>`__" by Jonathan Rasmusson, Jim McDonald
+
+
 Другие
 ------
 

emacsway/soft-skills/cognitive-biases.rst

@@ -30,6 +30,7 @@
 - "`Селективное восприятие <https://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D0%BB%D0%B5%D0%BA%D1%82%D0%B8%D0%B2%D0%BD%D0%BE%D0%B5_%D0%B2%D0%BE%D1%81%D0%BF%D1%80%D0%B8%D1%8F%D1%82%D0%B8%D0%B5>`__"
 - "`Эффект привязки <https://ru.wikipedia.org/wiki/%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82_%D0%BF%D1%80%D0%B8%D0%B2%D1%8F%D0%B7%D0%BA%D0%B8>`__" (Эффект якоря)
 - "`Психологическая защита <https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D1%89%D0%B8%D1%82%D0%BD%D1%8B%D0%B9_%D0%BC%D0%B5%D1%85%D0%B0%D0%BD%D0%B8%D0%B7%D0%BC>`__"
+- "`Отклонение в сторону статус-кво <https://ru.wikipedia.org/wiki/%D0%9E%D1%82%D0%BA%D0%BB%D0%BE%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B2_%D1%81%D1%82%D0%BE%D1%80%D0%BE%D0%BD%D1%83_%D1%81%D1%82%D0%B0%D1%82%D1%83%D1%81-%D0%BA%D0%B2%D0%BE>`__"
 - "`Реактивное сопротивление <https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%B0%D0%BA%D1%82%D0%B8%D0%B2%D0%BD%D0%BE%D0%B5_%D1%81%D0%BE%D0%BF%D1%80%D0%BE%D1%82%D0%B8%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_(%D0%BF%D1%81%D0%B8%D1%85%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F)>`__"
 - "`Эффект ложной уникальности <https://ru.wikipedia.org/wiki/%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82_%D0%BB%D0%BE%D0%B6%D0%BD%D0%BE%D0%B9_%D1%83%D0%BD%D0%B8%D0%BA%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B8>`__"
 - "`Эффект неоднозначности <https://ru.wikipedia.org/wiki/%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82_%D0%BD%D0%B5%D0%BE%D0%B4%D0%BD%D0%BE%D0%B7%D0%BD%D0%B0%D1%87%D0%BD%D0%BE%D1%81%D1%82%D0%B8>`__" (упоминался `здесь <https://t.me/emacsway_log/97>`__ и `здесь <https://t.me/emacsway_log/101>`__)
@@ -56,6 +57,7 @@
 - "`Закон тривиальности (эффект велосипедного сарая) <https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D1%82%D1%80%D0%B8%D0%B2%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B8>`__"
 - "`Первый закон Паркинсона (Работа заполняет время, отпущенное на неё) <https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD%D1%8B_%D0%9F%D0%B0%D1%80%D0%BA%D0%B8%D0%BD%D1%81%D0%BE%D0%BD%D0%B0>`__"
 - "`Синдром неприятия чужой разработки <https://ru.wikipedia.org/wiki/Синдром_неприятия_чужой_разработки>`__"
+- "`Эффект авторитета <https://ru.wikipedia.org/wiki/%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82_%D0%B0%D0%B2%D1%82%D0%BE%D1%80%D0%B8%D1%82%D0%B5%D1%82%D0%B0>`__"
 - "`Групповое мышление <https://ru.wikipedia.org/wiki/%D0%93%D1%80%D1%83%D0%BF%D0%BF%D0%BE%D0%B2%D0%BE%D0%B5_%D0%BC%D1%8B%D1%88%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5>`__"
 
 - "`Кривая забывания <https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D0%B8%D0%B2%D0%B0%D1%8F_%D0%B7%D0%B0%D0%B1%D1%8B%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F>`__"