《敏捷软件开发》笔记 - 1

本笔记完成于2013/8/11；谢绝无授权转载。

这本书的中文译名是一个平淡无奇的<<敏捷软件开发>>，这个名字是如此的平庸以至于放在书架上不会有几个人注意到它真正的价值，除非你仔细的阅读了书面封底的作者介绍和英文原版所获得的荣耀 - 17届Jolt大奖获奖作品；而Cockburn大师本身又属于一个人能连续两次获得Jolt的技术作家之一；但是能够在连续两年中获得两次Jolt大奖的，估计又少之又少了。

脉络

这本书讲述的部分很多已经超越了软件开发本身，并且也并没有特别偏颇的只讲述Agile一种方法，而是从多个角度综合衡量多种方法论的优缺点和使用场景。总体而言，这又是一本务实的书，而不是简单的对agile方法进行鼓吹和传教。

全书的结构可以看作三个部分（虽然作者认为是2个部分）:

理论

前边一半的篇幅用于介绍各色理论 - 沟通的基础和协作，个人的影响，交互通信的方式和特点，团队以及方法学。讨厌理论的人可能会跳过这一大部分，然后我个人的看法是，这恰恰是作者最精华的所在。理论的探讨也不是简单的罗列和论证，而是引用其它人的研究成果，并结合了作者自己做管理咨询工作的经验和分析总结。每一个章节，都分为一大一小两个部分：

• 前者详细的分析和论证主题，并根据实践经验加以总结和分析
• 第二部分大多冠以evolution的后缀，在前者部分基础上加以升华或者扩展。

实践和方法学

第二个部分主要侧重于实践，即各种各样的方法学和实践方式，主要侧重怎样做的问题和思考这些方法学可以给个人带来怎么样的启发。描述了集中方法论：

• XP
• Light and agile
• Self adapting
• Crystal family

这些方法和常见的Scrum/XP/Clean Room方法论有些不同；其实现有的方法分支都以这些公共的理论为基础，互相学习/发展和渗透。

附录

一般书籍的附录不会太长，仅仅添加一些和主旨无太大关系的说明或者索引。这本书则不属于这一类；初一看会发现书籍的附录占据了四分之一的篇幅，并且分成留个章节，只有最后一个章节是关于索引和书籍引用的常规内容。其它的部分，也遵从了前边两个大块的结构，对正文没有详细说的部分做了更深入的扩展，或引用大篇幅已经脱销的书籍文字，或者直接给出一些偏一轮的paper的大部分乃至全文来辅助全书的主线。个人感觉这部分其实可以作为一个独立的部分。

有趣的是，敏捷宣言的部分和敏捷联盟的成立背景也在这里做了详细的介绍 - 由此我才明白为何外界对敏捷有那么深刻的误解：这只是一个松散的联盟，参与发起的先驱们其实有着很不同的观点和方法论。这个过程的产出才是大家常见到的敏捷宣言，过程本身又呼应了作者的观点 - 这是一个关于协作的游戏。

理论

沟通和倾听的三个境界

作者认为沟通是极其苦难的事情，甚至有些时候是那一达到的，所以才有各种各样的方法论来减少协作的难度。这个过程是有不同的阶段的，作者引用了Shua-Ha-Ri的学习理论来阐述这三个阶段：

• Shu 是基础部分，需要维持基本的原则和方法，学习成熟的方法和实践，确保这些实践不被破坏；这个是基础阶段，需要有mentor或者coach指明一条正确的道路，引导大家走下去，不要偏离到错误的路上去。
• Ha 是脱离第一个阶段，适度偏离死板的教条，获得一定的自由去深入的反思和理解其中不合乎实际情况的部分。这个部分的前提是，一些基础的原则和实践被真正吸收和消化，否则就容易随意的否定和偏移，这是一个提高的阶段
• Ri 是最高的升华阶段，这个水平之上要求能超越已有的所有舒服，用实践者的方法从实际情况出发，找到最适合的方式。这一阶段任何书籍和方法仅仅是参考，需要的是原创的思想和过程

理想的沟通在很多时候甚至是不可能的事情，尤其是如下的情况：

1. 人们很容易误会口头表达的意思
2. 有歧义的术语或者名词常常产生误解
3. 喋喋不休的人可能给出的指令是让人不想仔细听下去或者真正听进去
4. 领域知识的差异导致信息准确性的降低
5. 不同的知识背景导致某些预设的关于常识的背景可能根本就不存在

具体到实际工作中来，就会有

1. 设计文档阐述的意图很难准确和无偏差
2. 经验丰富的开发者很可能用简洁的语言描述设计想法

有鉴于此，我们可以在沟通的过程中，尽量创造共同的经验和背景知识作为讨论的前提，并在作出具体的Action之前多确认不必要的误解。而这一切都需要更好的协作和交互。

软件和创造/沟通游戏

游戏可以按照是否有目标和是否终止分为如下三个类型：

1. 有限结束的，没有目标导向的，如弹钢琴，跳舞等
2. 有限的，但是有确定的目标，譬如网球比赛，软件开发
3. 无限永远不终止的，如职业生涯管理，商业组织生存

自然这里关于有限无限的定义，是基于一个一个具体的活动而言的，譬如职业生涯的发展，相对于一次的工作更替来说是无限继续下去的，但是对于人的生命而言又是相对有限的，当然这个是不同的范围界定了。

Cockburn认为最容易和软件开发活动做对比的莫过于攀岩运动，因为他们有如下的共同之处：

1. 注重协作和目标导向：攀岩需要登顶，还需要分工合作，软件开发也同样有清晰的商业目标（开源软件不在此列），并且强调分工协作（个人项目自然不算）
2. 负载均衡和分工：根据不同的需要和负载来协作分配资源和重心
3. 团队：需要用团队的方式来完成
4. 智力水平的要求：有些人永远不能完成攀岩，有些人永远没有智力和能力做软件开发工作
5. 技巧密集型：需要经验和技巧的积累才能更好的完成目标
6. 培训：各种知识和技巧需要事前的培训才可
7. 工具：需要用工具来提高效率，并且工具扮演了一个重要的角色
8. 资源受限：没有无限制的资源供分配，必须协调和均衡
9. 计划：必须事先指定某种粒度的计划，进行资源的分配
10. 不确定性/挑战：总有无法预料的情况发生，天气可能突变，突然而来的技术问题等
11. 乐趣：过程本身是有趣的，编程过程本身是有趣味的（至少很多程序员是因此从事这个职业）

尽管有很多关于软件开发和传统工程学科的比较，然而Cockburn并不认为这样的比较是恰当的，因为工程师仅仅按照设计好的计划来操作就是，后期如果除了小问题，要么推倒重来，要么小修小补；然后几十年的软件工程时间却表明，仿照这种方式来操作带来了效率的问题和维护性的噩梦。软件开发的计划很难做到和变化的环境想符，而维护的成本也高昂到甚至直接取消项目。

作为软件开发工程师，他们需要的是达到目标，理解问题然后找到一种方法解决面临的问题，并用合适的工具和语言实现该解决方案，并解决可能的变更和维护需要。从这个角度出发，软件开发活动是：

1. 资源有限的
2. 协作性的
3. 注重创造和沟通的

同时，软件开发活动同时要求在沟通的过程中，将发布可用的软件作为首要的目标的同时，积累一些经验可用用到下一个软件中去。软件开发团队在没有满足第一个目标之前必须优先尽可能保证当前的软件可以发布；然后做到第一个之后，对于第二个目标，必须同时考虑到资源的限制性，做到尽可能好就够 - 奢求文档永远和代码同步就是一个没有意义的目标。足够好就是了。交互和协作才是最重要的，因为文档总为是死的，沟通则是总在变化的。

重构软件开发过程

软件开发过程是一个通过协商来达到协作的过程，该过程通过个人的技术尝试和由各个贡献者组成的团队的协作达成专业技术上的决策。从这个意义上来说，注重交互和协作的软件开发过程和传统意义上的软件工程有很大的区别。ECN（Engineering Collaboration via Negotiation)就是通过群体的协作达成的技术决策来完成软件开发的活动。这一活动强调，最好的流程是通过共同构建的过程达成，在这个过程中，每个人都动态的参与并影响最终的决策。因为人的想法和观点总是在动态的变化，因此这一过程必然要求协作和协商的过程也是动态进行和持续不断的。

同时这一过程也意味着工程上的协商决策(collaborative deal-making)和共同创新(collective innovation)。协作的结果是所有参与各方的互相竞争的偏好所达成的一整的意见。这个过程必然强调双赢的产出和新的创新，这些创新都不可能由单枪匹马的冒险所达到，而是通过协商而后的一致意见转化得来。

待续。