书中内容没有太多新意，但是帮助启发和建立敏捷实践的结构化知识图谱， 更好的表述和理解敏捷实践。 在这个角度可以推荐一下，不错的一本书。 这本书有免费的电子版 https://www.infoq.com/minibooks/agile-patterns
软件，是有价值的，是一个商品； 软件开发就是将价值交付的过程。 所以整个软件生命周期就是围绕上面两个问题，发现价值，交付价值。 这个两个问题还有另外一个提法，常说的Do Right Thing和Do Thing Right。
image.png
书中用一个很好的隐喻，对于那些影响软件交付的现象，看做坏味道。书中围绕着这如何识别不同的坏味道，选择对应的技术实践和推广去除掉这些坏味道。书中内容包含三部分，第一部分介绍商业价值以及不同属性，坏味道，如何采纳工程实践；第二部分，介绍软件一些软件的工程实践；第三份介绍软件工程实践的组合。
- 关注对于客户的商业价值.
- 当软件的商业价值不能被交付时，识别出这些现象，或者称之为坏味道。
- 如何选择不同的实践并在项目中采纳它。
- 描述每一条实践方式，以及如何在项目中采纳和推广。
- 不同实践可以形成更大的实践，以及如何在项目中推广。
对于每一条工程实践，用一个结构化的模板来介绍。这和Design Pattern 介绍每一个pattern的模式同出一辙。 来回答这一条工程实践的上下文，是解决什么问题，或者什么样的情况会优先考虑该实践。
#名字和依赖
- Name
- Description: a brief overview of the practice or cluster.
- {Dependency Diagram:} A diagram showing inter-practice dependencies (for practices) and grouping (for clusters).
#价值和上下文
- Business value: A sorted description of the business values this practice or cluster improves.
- Sketch: A fictional story that describes this pattern being used on a software development project in context.
- Context: The preconditions and environment where this pattern is useful. The context is a collection of fact, correct application of the pattern should remove
many of the forces.
- invariants: issues that do not change by applying the pattern.
#解决的问题和得到的好处
- Forces: Used to elaborate context and give specific issues that are problems (partially) resolved by this pattern. Infact, correct application of the pattern should remove many of the forces.
- Therefore: The pattern description.
#如何推广以及在推中留意的副作用
- Adoption: Steps, ordering, guides to adopting this pattern.
- But: Negative consequences that can occur from applying this pattern.
- {Variations:} Different ways this pattern has been implemented successfully other than that described in the Therefore section.
- {References:} Where to read more.
本书覆盖的软件的实践主要在技术实践
- Automated development Tests ( Test-Last, Test-First, Unit Test)
- Refactoring
- Continuous Integration ( 现在应该扩展为 continuous delivery ）
- Simple Design (vs Fountup Design)
- Functional tests ( end-to-end test)
- Collective code ownership
Cluster practice （ 组合实践）
- Evolution Design
- TDD
- Test-derive requirements (BDD)
书中关于软件开发流程的实践并没有包含在内，比如没有scrum中的迭代，增量，尽早发布Story，review meeting，retro meeting， daily meeting。
其后续作者另外一本书有介绍: Agile Adoption Patterns: A Roadmap to Organizational Success
交付价值角度看软件工程实践
软件开发就是交付价值，那么交付价值的极限就是：
- 随时可以交付，也就是 持续发布
持续交付第一步需要软件有一个管道(pipeline)， 将软件从源码到发布的artifacts （CI） ， 部署到最终的托管环境（CD）。这样就对于任何提交，就可以随时发布，理想的达到的实时发布。但是仅仅有一个持续发布的管道是不够的，管道解决从代码到artifacts，以及环境自动化和提供快速发布的能力，但是交付软件的质量本身管道没有办法保证。 管道保证发布的快，那么如何保证软件质量，所谓又快又好？ 需要关心软件的质量。
ci-cd.png
- 软件的质量，软件测试金字塔, 保证尽早反馈发现问题。 基于单元测试保证底层最小单元没有问题，端对端（e2e）的测试保证集成没问题用户需求或者价值没有被影响， 模块测试（component）在二者之间，是一个中间的集成保证模块粒度的集成没有问题。
test pyramid.png
管道提供发布快，测试保证质量好，那么就够吗？ 软件是交付价值，而前面只是保证提交有效。要软件快速交付价值，那么需要需求分解，垂直节分，找出价值最高的需求来做。
-
需求要分解的小，这样价值才能尽早交付。
-
需求蛋糕切分法： 垂直切分，每一个story都是一个价值交付。
image.png
-
需求高低有衔接
-
需求的Invest 原则
-
管道提供快速发布，测试金字塔保证软件问题尽早发现，需求分解提供价值尽早交付，那么够呢吗？ 软件要持续发布，那么软件的架构如何支撑呢？ 提前设计问题，
预判不准。需求是渐进明细，随着需求明确和新功能的增加使得之前的架构不合适；软件开发就是学习过程，对于之前问题有更好的认识，那么提前设计没问题很难保证一次性正确。即使一次设计正确也存在过度设计，前期有太多架构基础设施，对于用户而言是看不到价值，或者说不能交付价值。 如果对于软件架构不能随着即使更新使得适应新的需求，那么后续的开发的效率和维护都会付出代价，软件开发速率也就越来越慢，所谓技术架构的腐化，架构的技术债。
相比提前设计， 更倾向于渐进式架构。随着问题的深入，随着需求的增加，随着认识的提高，软件架构也随之改变。
- 演进式的架构，支撑软件架构随着需求的改变而改变。
image.png
上图来自于 “Nature of Software Development”
明显渐进式架构，需要重构来支撑；而重构需要测试覆盖来支撑。渐进式架构是一个复杂的实践。
这些只是涉及到一些个人的角度工程实践， 那么基于团队的工程实践更注重于协作和交流。
- Collective of ownership
- Code standard
- Pair programming
- Mob programming
- Code review ,code inspect
- Code scan, code coverage
基于流程的实践
- Iteration and Incremental
- Game Planing -Story
- Daily meeting
- Demo (review) meeting
- Retrospective meeting
- Whole team( product owner)
3. Extreme Programming
这些实践大部分已经包含XP中。
image.png
将XP的实践如果从个人和团队角度，可以有这样的分类##
- 个人提高 （ Developer Test, Refactor, Simple Design, Evolution Design)
- 团队协作技术部分 ( Code standard, Collective Ownership, CI&CD, Metaphor， pair-programming)
- 团队协作流程部分 ( Whole team, Customer Test, Small release, Planning Game)
5. 从问题视角看软件实践
image.png
image.png
image.png
软件工程实践(best practice) 是经验模型，是用来解决软件开发中的问题。 而这些模型本身来源于人们对于来自于不同方面的经验总结 。 比如很多实践是基于反馈原则，比如CI-CD, Developer Test; 一些来自于生产的Lean， 比如 减少浪费， test -fix 的浪费。
没有绝对的对与错，合适自己的才是最好的，不能因为实践而实践 。如果这些原则于现实冲突，请尊重现实。
网友评论