一、敏捷力介绍
1、瀑布模型:在瀑布流程中,每一步骤都必须等待前一步骤结束后才能继续,也只有等待所有步骤都结束后才有可能向客服交付价值。
瀑布模型相当于在投入生产前就“完美化”产品设计是可以做到的。但软件产品是复杂系统,而不是静态物件,毫无经验数据只能设计出致命的烂系统,从而导致不良的后果。
2、敏捷:
所有种类的敏捷流程都有一个共同点:他们拥抱变化,视变化为成长的良机,而非障碍。
敏捷与瀑布模型的差别在于:敏捷一点点需求收集,一点点设计、编码、测试,最后交付一点点价值给客户。接着团队在重复此过程,周而复始,直到项目完成为止。
敏捷需要的:边做边测试、及早且频繁地交付产品、文档边做边写、构建跨职能团队。
敏捷的核心思想在于:迅速交付商业价值,体现为可工作的软件,还要以定期增量的形式持续地交付价值。
3、敏捷价值观与原则:
敏捷价值观:
- 个体和互动高于流程和工具:流程和工具是为人服务的,不能强加,可以尝试,允许犯错。
- 工作的软件高于详尽的文档:不奉行文档,但同样记录工作(包括每次变化:构建、测试集成),因此一直在积累和演变的敏捷计划是活物。
- 客户合作高于合同谈判:降低客户风险,不是靠前期担保方式转嫁风险给承包商,而胡思依靠流程中客户的持续参与,以及敏捷团队定期交付可工作软件增量的能力。
- 响应变化高于遵循计划:软件开发的变化不可避免且理所当然的,认为变化是好事而积极响应好过“变化控制”。
敏捷原则:
- 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
- 欣然面对需求变化,及时在开发后期也一样,为了客户的竞争优势,敏捷过程掌控变化。
- 经常地交付可工作的软件,相隔几星期或一两个月,倾向于才去较短的周期
- 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
- 激发个体的斗志,以他们为核心搭建项目,提供所需的环境和支援,辅以信任,从而达成目标。
- 不论团队内外,传递信息效果最好效率也最高的方式是面对面交谈。
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
- 以简为本,他是极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自自组织团队。
- 团队定期地反思如何能提高成效,并依次调整自身的举止表现
4、敏捷力的商业案例:
敏捷的持续交付,把一整个项目多次迭代,频繁交付,每次都能交付可运行的软件。开发周期较短,接受变化的能力较强。每次交付都能获得利润,即使项目终止于某个迭代周期也不至于亏损严重。大大的降低了成本,控制了风险。因为在软件开发过程中不断适应变化,持续满足新的需求,潜移默化的提高了最终交付软件的质量,因此收获的利润也更可观。
而瀑布模型每一步骤都必须等待前一步骤结束后才能继续,客户只有等待整个项目开发完毕才能看到可运行的软件,周期较长,几乎没有接受变化的能力,无法适应开发软件这段时间,外界变化而带来的需求变化。一旦最终交付的产品不能令客户满意,面临的亏风险是相当大的。
二、Scrum
1、角色:
(1) 产品负责人:是唯一有权要求团队做事以及改变列表条目优先级的人。因此需要和干系人密切合作。持有产品愿景、代表业务、代表客户、拥有产品列表、划定故事优先级、设立故事的接收标准、有空回答团队成员们的问题。
(2) Scrum Master:担当教练角色,引领团队达到更高级的凝聚力、自组织和表现。作为专家,为团队获取最大价值,为团队移除障碍。Scrum专家和谏言者、教练、障碍推土机、引导者。
(3) 团队成员:团队全权决定如何完成工作、使用哪种工具和技术,以及如何瓜分任务。负责交付用户故事、做所有的开发工作、自组织地交付用户故事、支配估算流程、支配“如何干活”的决策、避免“与我无关”
2、Sprint周期:
(1) Sprint规划会议:团队选择一组交付物作为当前Sprint的承诺。团队罗列出交付用户故事所需完成的所有任务。回答:“做什么?”(完成哪些功能点)“怎么做”(功能点分成哪些任务)
(2) Scrum站会:在每天工作前开会,只有开发人员参与。简要、直截了当的说明已经完成的内容和期望完成的内容。
(3) 故事时间:每周一次,估计还未制定大小的故事,将较大的故事拆分成更小的故事。在中期召开,修整好列表,以便流出充足的前置时间。
(4) Sprint评审会议:演示可工作软件
(5) 回顾会议:每次迭代都要召开回顾会议,在迭代最后才举行,专门留给团队的时间,专注于讨论他们当前sprint的心得和体会。准备阶段(让参与者放心大胆的畅所欲言)、收集数据(用索引可或便签记录,回忆上一个sprint发生的事)、洞察问题(发现数据的模式、最重要的条目,然后深化理解寻找因果关系,最后确定解决方案或改进方案)、确定方案(在团队控制范围和能力范围内去改进)、结束(感谢)
(6) Sprint异常终结:为了响应外部的事情或是团队遇到一些情况。团队和产品负责人交换自己的意见,看产品负责人是否想要终结sprint。提早终结sprint本质上是商业决策,因为需要由产品负责人来操持。
3、Scrum工件:
(1) 产品列表:包括特性、缺陷修复、文档变更和任何值得创建的东西。
(2) Sprint列表:任务清单,存活时间有限,仅存活一个sprint的时间,包含所有已承诺的故事以及相关联的任务,以及此外的附加工作。
(3) 信息辐射器:待办、进展中、已完成(任务版)
(4) 燃尽图:描述剩余工作随时间变化的轨迹。
4、用户故事:
作为<某类用户> 我想<做某事> 从而<创造出某些价值>
聚焦目标:为了<达成某目标> 作为<某类用户> 我想<做某事>
聚焦价值:为了<创造某价值> 作为<某类用户> 我想<做某事>
用户故事不是完整的需求或说明书,它们是占位符。找过一系列测试,直到所有人都认同测试通过,就意味着故事按预期实现,则得到验收标准。
5、用故事大小值估计工作:
第一步:给所有的工作项都分配相对大小值。大小值表明需要完整的工作有多少。
第二步:完成几个工作项,度量她们实际花费的时长。得到实测数据后,结合制定给其他条目的相对大小值使用,预期的进度可见性也就有了。
找出一个故事,估计值为“1”,成为度量的相对单位,来估计其他故事所需的工作量。
估算方法:计划扑克
三、辅助性实践
1.在固定时间、固定资源的情况下,做规划时,得做出一些艰难的权衡决策,使不使用scrum都同样需要考虑。
2.铁三角(速度、成本、范围):三者需要平衡,改变其中任何一个,必然会导致另一个或两个相应地产生变化。
3.绘制故事地图:用户故事按优先级从高到低的顺序排序。
4.纸上原型:(用户、计算人、引导者)
(1)画出轮廓,并写出按钮和特性的名称
(2)使用便利贴制作因用户的操作而显现、消失的按钮。
(3)用户看到的所有界面都要用纸张做出来,指导完成操作为止。
引导者告诉用户,他们被要求使用此应用来完成一些事情,用户轻拍纸张进行单机,告知计算人要输入的内容,计算人翻转或操作页面,以响应用户的动作。用户不可以向计算人或引导者问问题,这个测试就是为了看看应用能否干得了活。
纸上原型不是scrum的一部分,但他具有敏捷的本质,是充实产品负责人工具箱的上佳之选。
5、项目微章程:
越长篇大论的业务文档,越是无人问津。微章程涉及多个话题,最终还是会在其它文档中详细叙述,是份非常有用的总结。
包括:代号、使命宣言、愿景宣言、电梯演讲(剪短几句话,关注项目要解决的问题)、商业价值(金钱或其他方面的价值)、客户和用户、度量指标(如何度量价值)、里程碑(重要的时间点)、资源、风险、权衡。
6、重构:只构建今天你需要的架构,随后根据需要而不断发展它。以此方式,架构一直都是恰到好处,系统因而也易于理解、维护和强化。
7、测试驱动开发
目标在于快速地开发出设计精良、正确性已获证实的代码。这个循环“红色—绿色—重构”红色需要重新运行测试,若全部通过则处在“绿色”状态。维护者一层保护性测试使得开发人员可以大胆地修改和改进代码,就带来了快速、敏捷的开发。
一旦开发人员切实地理解了代码需要做什么,就已经准备周全可以妥善地设计代码实现了。TDD可以降低缺陷水平,且无需牺牲生产力。
8、结对编程:两个程序员一前一后,用一台电脑写代码。更加快速地生产处设计更精良、简洁的代码。消灭了只是简仓,因为至少两个开发人员都熟悉了对方那部分代码。结对的方法很多,应该多试几次,以便找到是和他们的方式。
(1) 驾驶员—导航员结对:驾驶员控制键盘,关注当前代码行。导航员关注战略,思考该编写哪部分代码。
(2) 乒乓结对:反复交换键盘,挑战对方以解决问题。
(3) 测试驱动开发结对编程游戏:代码永远只有两种状态:红色(测试没通过)或绿色(测试通过)。把合法动作看成是状态转换,发生转换则递交给另一名玩家。