敏捷软件开发系列第2讲——Scrum与极限编程

 一家之言  原创  管理员  2019-03-02 11:25

概要:敏捷方法(特别是极限编程)的优点在于,它首先承认我们并不完全知道我们具体要开发一个什么东西,而要想弄清楚这个问题,最有效的方法就是把它开发出来。使用这种方法的团队用可工作的软件说话,而不是用详尽的文档,因为从用户那里得到反馈的最佳方法就是先完成软件的部分功能,并把软件交付到用户的手上。

敏捷软件开发宣言

  • 个体和互动高于流程和工具
  • 可工作的软件高于详尽的文档
  • 客户协作高于合同谈判
  • 响应变化高于遵循计划

没有银弹

没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍


瀑布式流程


缺点

  • 在项目开始前就需要准备好完整的需求文档
  • 过于关注文档而不是协作
  • 分级严格,低自由度
  • 用户只有在项目结尾才能看到成果

拥抱变化,引入敏捷


原则

  • 最优先要做的是尽早、持续地交付有价值的软件,让客户满意
  • 乐观地面对需求的变化
  • 频繁地交付,周期越短越好
  • 面对面交谈最有效
  • 业务人员和开发人员必须每天都在一起工作
  • 相信团队成员能做得更好

  • 可工作的软件是衡量进度的首要标准
  • 倡导可持续开发
  • 追求技术卓越和良好的设计
  • 最大程度减少不必要的工作
  • 最好的架构、需求和设计来自自组织的团队
  • 定期反思

人物角色


产品所有者(Product Owner)

让团队知道开发出怎样的产品,和团队其他成员一起工作,负责维护生产积压工作表(production backlog),并对表中的内容制订优先级。


主管(Scrum Master)

将敏捷落实到团队实践中,帮助项目分解、跟踪进度。和整个团队一同工作,帮助团队成员克服困难,保证项目正常运转。


团队其他成员


流程示例


重要的几个会议


冲刺计划会议

参与人:所有团队成员

  1. PO准备backlog(已排序)
  2. 产品所有者和团队一起选择出要在这一轮冲刺结束时需要交付的功能(需要同意在冲刺结束时演示一份可工作的软件)
  3. 会议结束时,必需要确定下这一轮冲刺的积压工作表

每日站会

参与人:所有团队成员,时长:15分钟

回答三个问题:

  • 自上一次站会到现在,做了些什么?
  • 从现在到下一次站会,计划做什么?
  • 遇到了什么困难?

冲刺评审会

  • 向用户和利益干系人展示可工作的软件(只应演示可工作的软件,不应演示中间产物)
  • 讨论对交付物的满意度及还有什么需要改进的地方等
  • 如果需要修改,则放入backlog中

冲刺回顾会议

目的:讨论可以改进工作方式的方法

每个人都要回答两个问题:

  • 在这一轮冲刺中有哪些事做得不错?
  • 未来有哪些事情可以改进?

冲刺过程约束

  • 每一个冲刺都应该在规定的时间内,如两周或一个月
  • 若有问题一定要第一时间通知PO(如延期、终止等)

以上是一个基本的敏捷流程,是不是很简单?


再说说迭代与增量


迭代

一种通过持续精炼而不断取得进步的流程。

开发团队首先给出一个系统的初步版本,大家都清楚这个版本在某些(甚至很多)方面并不完善或是功能很弱。然后他们迭代性地改善这些方面,直到产品达到令人满意的状态。在每一轮迭代中,更多的细节被加入到软件中,因此软件也一步步地得到了改进。


增量

一种把软件分成多个部分开发和交付的流程。

每一部分(或称为每一份增量)都代表了一组完整的功能子集。一份增量既可以小也可以大,既可以表示一个系统在小终端上的一个登录界面,也可以表示一组高度灵活的数据管理界面。每一份增量都要有完整的代码和测试。对一份增量的常见预期是这份增量的工作在事后不需要返工


猪和鸡的故事


一头猪和一只鸡在路上走着。 鸡说:“你好啊猪,我想我们可以开一家餐馆!” 猪说:“哼,呃,也行啊,这家餐馆叫什么呢?” 鸡回应道:“那就叫‘火腿鸡蛋料理’怎么样?” 猪想了一会儿:“我想还是算了吧。我得两肋插刀,而你管点蛋用就行了!”


在Scrum 项目中,谁是鸡,谁是猪呢?

  • 鸡通常用来指项目中指派任务的个人,猪则是与项目生死与共的人
  • 你是不是总是把项目的成败看作自己的成败呢?
  • 敏捷团队中,所有的角色都应该是猪,但是缺乏经验的Scrum 团队也很容易出现鸡的心态

如何召开有效的每日Scrum例会?

  • 表现得像猪一样
  • 细节会后讨论
  • 轮流先行(认真听取他人想法)
  • 不要当作例行公事
  • 所有人都要参与
  • 不要开成最新状态汇报会
  • 检查每一项任务
  • 计划需要则改变

如何理解用户的真实需求?


描述用户需求(User Story)

对一个用户使用软件某一特定功能时的一个简明扼要的描述




User Story卡片的背后

增加用户满意条件,也就是这个User Story完成的标准。


估算用户需求(Story Point)

  • 有多少个团队,就有多少种估计工作量的方法
  • 被证明对很多Scrum 团队都有效的方法是使用“故事点”
  • 一个sprint所消耗的point总和即为项目速度

所谓故事点,就是通过给每一个用户故事分配一定的点数,用以表示开发这个用户故事需要付出多大努力。通常,这些点数是通过将当前用户故事与过去开发过的用户故事进行比较得出的。

简而言之,也就是代表这个故事现实的复杂度


估算方法

斐波那契数列(0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233,...)

敏捷扑克:


实现具体的功能(Task)

实现该Story具体需要完成哪些事情


燃尽图

一种让任何人都可以一眼看出当前的冲刺与团队过去的速度相比如何(是更快还是更慢)的方法。



集体承诺

  • 整个团队应该有一种“同舟共济”的态度
  • 努力尝试让我们的软件变得更加有用

极限编程——编程

  • 能够从软件开发的各个方面帮助团队编写出灵活多变的代码
  • 目的是要解决那些导致开发团队写出糟糕代码的问题

测试先行编程(测试驱动开发)、结对编程


极限编程——集成

  • 开发团队需要一个自动构建全部代码的机制,而且完成自动构建的时间不超过10 分钟
  • 开发团队需要不断地进行构建并注意编译错误或单元测试失败

极限编程——计划

  • 每个周期以一个计划会议开始,会上团队成员回顾目前的项目进度,与客户一起挑选本次迭代的故事,然后将故事分解成具体任务,接下来对任务进行工作量估计并分配到具体的开发人员。
  • 每个季度,整个团队会坐下来开会审视全局
  • 在迭代结束时只交付那些“真正完成的”软件,也就是说,该软件工作正常,所有测试都得以通过,并且可以演示给最终用户看。

极限编程——团队

在一起、在一起、在一起


再次强调——拥抱变化

敏捷方法(特别是极限编程)的优点在于,它首先承认我们并不完全知道我们具体要开发一个什么东西,而要想弄清楚这个问题,最有效的方法就是把它开发出来。使用这种方法的团队用可工作的软件说话,而不是用详尽的文档,因为从用户那里得到反馈的最佳方法就是先完成软件的部分功能,并把软件交付到用户的手上。


总结

  • 敏捷开发不是快,而是灵活
  • 敏捷开发是让项目尽量透明
  • 敏捷开发对人的要求高(是意愿而不是技能)
  • 敏捷开发同样需要规范和流程

每个人都要对项目负责

Scrum主管指导团队的决策

产品所有者帮助团队了解软件的价值


THE END


敏捷软件开发系列  

编辑:myweb   最后更新于:2019-03-28 20:48

点评:请记住,敏捷最重要的思想就是拥抱变化,而不是抵制。



声明:本站部分文章系本站编辑转载,转载目的在于加快信息的传递,及时与广大网友分享更多信息,并不代表本站赞同其观点和对其真实性负责。 如涉及作品内容、版权和其它问题,请及时与本站联系,我们将在第一时间删除内容!本站文章版权归原作者所有,内容为作者个人观点,本站只提供参考并不构成任何投资及应用的建议。


联系我:x889@foxmail.com,鄂ICP备14016278号-2
©2016-2019 我的ABC All Rights Reserved.
友情链接: 一起编程网