阅读笔记之《构建之法》三

第六章 敏捷流程

6.1 敏捷的流程

①敏捷开发原则:

(1)尽早并持续地交付有价值的软件以满足顾客需求

(2)敏捷流程欢迎需求的变化,并利用这些变化来提高用户的竞争优势

(3)经常发布可用的软件,发布间隔可以从几周到几个月,能短则短

(4)业务人员和开发人员在项目开发过程中应该每天共同工作

(5)以有进取心的人为项目核心,充分支持信任他们

(6)无论团队内外,面对面的交流始终是最有效的沟通方式

(7)可用的软件是衡量项目进展的主要指标

(8)敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去

(9)只有不断关注技术和设计,才能越来越敏捷

(10)保持简明——尽可能简化工作量的技艺

(11)只有能自我管理的团队才能创造优秀的架构、需求和设计

(12)时时总结如何提高团队效率并付诸行动

②敏捷流程概述:找出完成产品需要做的事情→决定当前的冲刺(Sprint)需要解决的事情→冲刺(冲刺期间每天开每日例会)→得到软件的一个增量版本并发布

6.3 敏捷的团队

自主管理:自己挑选任务、自己提出改进并实施改进

自我组织:每个人联合起来对项目负责

多功能型:每个人都全面负责,自己搞定规格说明书,和别人沟通,自己搞定测试

6.4 敏捷总结

在迭代开始时,团队审视摆在他们面前的任务,选择他们认为可以在迭代期间完成的那些任务(Plan)。然后团队独立地尽最大努力完成这些任务(Do)。在迭代结束时,团队给利益关系人展示成果(Check),并对开发流程进行调整(Act/Adjust)。

这里有一些实践者的经验教训:

(1)敏捷宣言表明的是一些优先级,不必当作圣旨或者教条来争论。

(2)Scrum Master不是一个官,而是一个没有行政权力的沟通者,就像微软的PM那样。他/她同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master,大多行不通。

(3)一些项目需要很多暗箱操作和政治角力才能搞定,Scrum会把这些矛盾都摆到明处。这有好处,也有风险。

(4)在复杂的项目里,要让一线团队成员做决定。

(5)创业公司的团队其实经常是运行在Scrum 的模式中(只不过大家太忙,没工夫论证自己到底有多么Scrum)。

(6)在Scrum计划阶段的估计不是一个“合同”,领导们不要把它当成一个合同。估计总是不准的。坚持短期的Sprint,这样即使不准的估计也不会有大的损害。

(7)不要和管理层谈“流程”,他们只关心“结果”。

(8)在大型团队、跨地区的团队,或者复杂项目中,Scrum并没有非常完美的答案,Scrum的创始人也承认这一点.

 

第七章 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)

posted @ 2023-06-08 23:29  你好,幸会  阅读(13)  评论(0编辑  收藏  举报