标签：坚持 结合 投资 经理 开发人员 提高 美的 变更 阅读
构建之法现代软件工程（第五次）
这周我阅读了《构建之法》第六第七章
（1）尽早并持续地交付有价值的软件以满足顾客的需求；
（2）敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势；
（3）经常发布可用的软件，发布间隔可以从几周到几个月，能短则短；
（4）业务人员和开发人员在项目开发过程中应该每天共同工作；
（5）以有进取心的人为项目核心，充分支持信任他们；
（6）无论团队内外，面对面的交流始终是最有效的沟通方式；
（7）可用的软件是衡量项目进展的主要指标；
（8）敏捷流程应能保持可持续的发展。 领导, 团队和用户应该能按照目前步调持续合作下去；
（9）只有不断关注技术和设计才能越来越敏捷；
（10）保持简明 - 尽可能简化工作量的技艺 - 极为重要；
（11）只有能自我管理的团队才能创造优秀的架构, 需求和设计；
（12）时时总结如何提高团队效率, 并付诸行动。
1.找出完成产品需要做的事情。
2.决定当前的冲刺需要解决的事情。
3.冲刺（同时进行每日立会来进行面对面的交流）
4.得到软件的一个增量版本，发布给用户。
1.敏捷宣言表明的是一些优先级，不必当作圣旨或者教条来争论。
2.Scrum Master不是一个官，而是一个没有行政权力的沟通者，就像微软的PM那样。他/她同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master，大多行不通。
3.一些项目需要很多暗箱操作和政治角力才能搞定，Scrum会把这些矛盾都摆到明处。这有好处，也有风险。
4.在复杂的项目里，让一线团队成员做决定。
5.创业公司的团队其实经常是运行在Scrum的模式中（只不过大家太忙，没工夫论证自己到底有多么Scrum）
6.在Scrum计划阶段的估计不是一个“合同”，领导们不要把它当成一个合同。估计总是不准的。坚持短期的Sprint，这样即使不准的估计也不会有大的损害。
7.不要和管理层谈“流程”，他们只关心“结果”。
8.在大型团队、跨地区的团队，或者复杂项目中，Scrum并没有非常完美的答案，Scrum的创始人也承认这一点。
MSF是微软解决方案框架，MSF的9条基本原则：
1.推动信息共享与沟通，第一个原则，就是所有信息都保留并公开，讨论要包括所有涉及的角色，决定要公开并告知所有人。当然，对牵涉到技术机密、安全性等信息要采取必要的保护措施。
2.为共同的远景而工作，“共同的远景”是指产品的远景。我们做一个产品，不管是应用软件、行业软件，还是通用软件，要明确项目的目标是什么。
3.充分授权和信任，在一个高效的团队中，所有的成员都应该能得到充分的授权，他们有权在职权范围内按照自己的承诺完成任务，同时，他们也充分信任其他同事能实现各自的承诺。
4.各司其职，对项目共同负责，在项目进展的过程中，对于每一项任务，每个人都要明确以下几点。
5.交付增量的价值，现在的软件产业，特别是和互联网相关的产业，变化非常快，用户希望产品团队经常提供更新，以适应新的需求。
6.保持敏捷，预期和适应变化，软件工程，唯一不变的是变化。所以干脆别幻想客户的需求会在第一时刻很明确，然后保持不会变。要注意，我们是预期变化，不是期望变化。
7.投资质量，软件开发过程大部分时间花在了解/设计/变更/再了解/再设计的过程中。我们要重视质量，但并不是要不惜一切代价达到最高的质量标准（有人倒吸了一口凉气），因为提高人/过程/工具的质量是要花成本的！我们不是为提高质量而提高质量。我们要讲投资的效率。比如，在做快速原型的过程中，有些部分可以做得粗糙一点。
8.学习所有的经验，在学习过去的经验的同时，也要避免让过去的经验妨碍解决现在的问题 。
9.与顾客合作，在项目开发过程中，要一直保持与客户沟通交流，因为商业价值是由客户说了算的。
在MSF团队模型中，任何技术项目都必须达到特定的关键质量目标，才能够被认为是成功的项目。任何一个角色无法实现其目标，都将危及整个项目。因此，每个角色都被认为是同等重要的，重要的决定都要共同作出。
我认为在一个项目结束的时候，每个角色都应该问自己这样的问题——我是否达到了我的质量目标？
MSF过程模型是从传统的软件开发瀑布模型和螺旋模型发展而来的，它把瀑布模型中基于里程碑的规划优势与螺旋模型中增量迭代的长处结合了起来。
团队用里程碑来检查工作是否结束和同步各个角色的进度，以此来确定当前阶段的目标是否已经实现。此外，里程碑标志着每个阶段的结束，此时团队应该引导成员转移工作的重心，并鼓励队员以新的视角来看待下一阶段的目标。
标签：坚持 结合 投资 经理 开发人员 提高 美的 变更 阅读
原文地址：http://www.cnblogs.com/Marooned/p/6941138.html
