本次 7-11章
MSF基本原则
推动信息共享与沟通（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）
需求分析:
获取和引导需求：软件团队需要找到软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出对软件的需求；需求还可以来自各种管理机构；需求不仅来自外界，还可以来自软件企业本身；需求还可以来自技术团队本身；有些需求的目的是要更好地了解用户的行为和需求。
竞争性需求分析的框架——NABCD模型
1. N（Need，需求）
你的创意解决了用户的什么需求？这个需求可以是明确的、公开的（例如：希望能上网玩三国杀）也可能是说不清道不明的，例如——以前没人说：嗯，如果我能找到这样一个网站，我可以去偷菜，就好了……我们要充分了解用户的痛苦，他们对已有软件、服务不满意的地方。
2. A（Approach，做法）
好，你找到了需求，下一步怎么办，得看看你有什么招数，特别是独特的招数，来解决用户的痛苦。你不能说我会C++，所以我一定可以写好这个软件。你得有独特的办法，例如，有人脸识别技术，会做超大规模的数据处理。那你（你的团队）会什么呢？只会冒泡排序？这些招数不光是技术上的，也可以是商业模式上的（例如，我们第一个做众包的服务）、地域的（例如，我们对本市的公交线路很熟）、人脉的（例如，我们认识很多大学生）、行业的（例如，我们有地图测绘行业的资质），或者是成本上的（例如，我们能找到更便宜的资源来维护网站）。
3. B（Benefit，好处）
这时候你已经有了独特的做法，那你这个产品/服务会给客户/用户带来什么好处呢？如果用户已经有一个解决方案（例如用户已经在用QQ聊天），那你的新的聊天软件具体有哪些好处，能让用户离开现有产品，使用你的产品呢？这还有一个用户迁移成本的问题——用户要花费多少精力、时间、金钱才能得到你的产品的好处？如果你要求用户必须有8GB内存、最好的显卡、10Mbps以上的宽带连接，才能使用你的“更好的”视频聊天工具，那么会有多少用户愿意支付这个成本呢？
4. C（Competitors，竞争）
竞争对手也没有闲着，这个市场有多大，目前有多少竞争者在瓜分，你了解么？你的产品如果不是最先进入某个市场的，你还能赢么？先进入市场的产品，有所谓的先发优势（FirstMover Advantage，FMA），当然也有劣势。后面进入市场的产品，有种种不利的因素，但是也有后发优势（Second Mover Advantage，SMA）。
5. D（Delivery，推广）
在实际项目中经历多次的NABC之后，许多人意识到这个框架还应该加一个元素D：Delivery。怎样把你的创新产品交到用户的手中？例一，你想到了一个好主意，建一个比hao123更好的导航页面！我们姑且认为NABC都没问题，那如何把这么好、这么简单的产品交到（Deliver）用户手中呢？例二，你想到了一个手机的应用，NABC都不错，那如何把产品交到千万个用户手中呢？
我们首先要定义用户的角色。正如戏剧中有正面和反面的角色，软件系统中也有受欢迎的和不受欢迎的典型用户。
- 受欢迎的典型用户——指那些按设计者的期望使用系统的用户，如“网站的购物者”
- 不受欢迎的典型用户——指那些有不正当目的的用户，如在一个房地产业主论坛中滥发房屋中介广告的用户——这些用户也许在别的系统中（如房屋中介论坛）是受欢迎的
典型用户只是我们的设想，还要和这些典型用户的代表交流，理解用户，理解他们的工作方式和需要。然后再修改，细化典型用户
有了典型用户之后，我们还得决定每一个典型用户的目标——他/她使用系统想要达到什么目的。对于每一个目标，列出达到目标所必须经历的过程，这就是场景，也可以叫故事。注意，有些场景描述了成功的结果，有些场景描述了失败的结果。用户和系统有成百上千种可能的交互情况，写场景时要有针对性。
个人感悟:开发是要根据用户体验来进行的，不能闭门造车。
之前我的编写代码只是按照正确的思维来执行，怎能也不会检查出错误，如果找其他人测试代码，没有知情，就可以测试出很多错误。方便完善软件。