20170930-构建之法：现代软件工程-阅读笔记

msf原则:
1推动信息共享与沟通（Foster open communications）
2为共同的远景而工作 (Work toward a shared vision)
3充分授权和信任（Empower team members）
4各司其职，对项目共同负责（Establish clear accountability and shared responsibility）
5重视商业价值（Focus on delivering business value）
6保持敏捷，预期变化（Stay agile, expect change）
7投资质量（Invest in quality）
8学习所有的经验（Learn from all experiences）
9与顾客合作(Partner with internal & external customers)

敏捷和现有做法的区别:
现有的做法 敏捷的做法
流程和工具 个人和交流
完备的文档 可用的软件
为合同谈判 与客户合作
执行原定计划 响应变化
敏捷的团队:
敏捷对团队的要求很简单：
自主管理（Self-managing）、
自我组织（Self-organizing）、
多功能 型（Cross-functional）。
自主管理：以前领导布置了任务，我们实现就可以了，现在要自己挑选任务；每次 Sprint 结束之后，还要总结不足，提出改进，并且自己要实施这些改进。“自主管理” 不等于“没有管理”。
自我组织：以前做好自己的事情就好了，安心下班。现在每个人要联合起来对项目负责， 有人工作落后了还要帮助他改进，项目缺少某类资源还要自己顶上去。
多功能型：以前规格说明书由PM来写，测试由测试人员来做，现在每个人都全面负责， 自己搞定规格说明书，和别人沟通，同时自己搞定测试。
敏捷在实践中的教训 1
1. 敏捷宣言表明的是一些优先级，不必当作圣旨或者教条来争论。
2. Scrum Master 不是一个官，而是一个没有行政权力的沟通者，就像微软 的 PM 那样。他 / 她同时还要在团队中做具体的工作。直接把原来的 “经 理”变成 Scrum Master，大多行不通。
3. 一些项目需要很多暗箱操作和政治角力才能搞定，Scrum 会把这些矛盾 都摆到明处。这有好处，也有风险。
4. 在复杂的项目里，要让一线团队成员做决定。
敏捷在实践中的教训 2
5. 创业团队其实经常是运行在 Scrum 的模式中
只不过大家太忙， 没工夫论证自己到底有多么 Scrum
6. 在 Scrum 计划阶段的估计不是一个“合同”，领导们不要把它当成一个 合同。估计总是不准的。坚持短期的 Sprint，这样即使不准的估计也不会有大的损害。
7. 不要和管理层谈“流程”，他们只关心“结果”。
8. 在大型团队、跨地区的团队，或者复杂项目中，Scrum 并没有非常完美 的答案，Scrum 的创始人也承认这一点 。