构建之法阅读笔记04

第七章 MSF
微软公司中关于软件开发的思想和宣言有一个方法论——微软解决方案框架（Microsoft Solution Framework，MSF），也就是微软推荐的软件开发方法

7.2 MSF基本原则

1. 推动信息共享与沟通（Foster open communications）

2. 为共同的远景而工作（Work toward a shared vision）

“共同的远景”是指产品的远景。我们做一个产品，不管是应用软件、行业软件，还是通用软件，要明确项目的目标是什么。

这个目标必须是明确的，没有二义性；
这个目标不是当前就能达到，必须是通过努力才能达到的；
3. 充分授权和信任（Empower team members）

这一点的关键是“授权”这个词，授权（Empower）有两个意思：

给某人权力和权威
给予某人更多自信和自尊在一个高效的团队中，所有的成员都应该能得到充分的授权，他们有权在职权范围内按照自己的承诺完成任务，同时，他们也充分信任其他同事能实现各自的承诺。类似地，团队的顾客（包括内部和外部的顾客）也认为团队能兑现承诺，并进行相应的规划
充分授权的管理方式是MSF的核心观念之一。MSF团队模型就是建立在以下两个原则上的：

平等协作—成员之间、团队之间是平等协作的关系
充分授权给团队和成员
这就是为什么MSF团队模型是网状，而不是层次结构。这样做有什么好处？好处有两点：

被授权的人会承担起自己对项目的责任，同时也期望同事们也同样对项目负责
MSF提倡自下而上的计划，每个人有充分的权力估计并决定自己的任务需要多长时间，而不是上级交给的时间，这意味着让真正做这件事的人按照自己的估计去完成任务。这样做的结果是啥？是人人都会支持项目的计划和时间表，因为这个时间表是每个人自下而上订出来的
充分授权在MSF团队模型的另一个含义是：信任，鼓励团队成员成长，每人都可以在某一时段。
4. 各司其职，对项目共同负责（Establish clear accountability and shared responsibility）

在项目进展的过程中，对于每一项任务，每个人都要明确以下几点。

Who：谁负责
What：做什么，具体的执行方案，什么叫做“做好了”
When：什么时候开始，什么时候结束
Why：为什么是这样安排（和项目的远景是否吻合），在什么情况下可以变更？
与“信息共享与沟通”原则相呼应，这样的安排能让所有人都明确自己的职责，同时有“大局观”—知道别人在做什么，为什么，以及整个项目的目标

5. 交付增量的价值（Deliver incremental value）

现在的软件产业，特别是和互联网相关的产业，变化非常快，用户希望产品团队经常提供更新，以适应新的需求。我们要保证在两个方面保证客户的利益：

我们提供的新版本对用户真的有价值
和客户商讨一个最优的新版本的发布频率
6. 保持敏捷，预期和适应变化（Stay agile, expect and adapt change）

软件工程，唯一不变的是变化。所以干脆别幻想客户的需求会在第一时刻很明确，然后保持不会变。要注意，我们是预期变化，不是期望变化

除开外部原因，团队内部也在变化，我们对技术的掌握每天都在提高，原来认为不可能的事可能变得容易。我们对客观世界和软件系统的了解每天都在深化，原来觉得没问题的小细节忽然成了大问题。甚至原来一起打拼的同事忽然要离开……这些都要求我们团队保持敏捷的身段

7. 投资质量（Invest in quality）

对质量的重视，引起对质量的投资，引起对人、过程和工具的投资。

投资要讲效率
投资要讲时机
投资是长期的
8. 学习所有的经验（Learn from all experiences）

在学习过去的经验的同时，也要避免让过去的经验妨碍解决现在的问题
这一原则有两个含义——

把经验总结出来
分享经验
MSF在每一个里程碑结束时都要做一个“里程碑回顾”，这个回顾不必等到整个项目结束才做。这样做的好处是，大家对最近的成败都记忆犹新，能提供比较准确和全面的反馈；如果发现了错误，可以马上研究解决办法，在下一个里程碑中通过实践来验证。另外，一些好的做法可以及时得到总结和推广。

在项目结束时，MSF推荐请团队以外的专家来主持召开“事后诸葛亮”会，这样的专家会比较系统地总结团队的成功经验和失败教训，同时也客观评价团队的一些特性和团队的开发过程管理，这样能促使团队成员以客观、向前看、解决问题的心态来参加“事后诸葛亮”会，避免主观臆断或相互指责。

9. 与顾客合作（Partner with internal and external customers）

个人感受：

这两章主要讲团队开发过程中的看注意事项，读时也正是我们结对开发项目的时候，对此，在读到这里

之前，在团队内部没有太多的交流，导致出现很多意见不统一的地方。

根据书中所说到的，我发现团队开发不是一个人的事，而且以后的工作大多都是团队开发，只注重一个人有很大弊端。

对此我再我在后面的团队开发过程中多与队友进行交流，努力去减少因为不交流尔产生的问题。