我曾经为之服务的一家公司,由于新项目的特点,也为了在公司的方法论资产做一个积累和提高,并且在详细调研了Scrum方法之后,公司老板作出决定,在E-Notebook项目中,开始采用敏捷开发方法,最近有空将其整理出来,做个留念:
和一开始接触任何事情一样,我先是有个了理论认识,在InfoQ上查阅了很多资料,知道了敏捷的宣言,如何来作,我也在理论上做了很多准备。知道了敏捷会议、敏捷例会、backlog、Sprint,燃尽图等等,并知道了其具体的含义和做法。但是在具体实践当中,还是有各种出乎意料的事情发生,所以也更加加深了对敏捷开放方法论的理解。
1) 一开始,我总是认为在敏捷开发中,不需要做架构设计,所以在给我的组员交代任务时,我们只是进行了针对模块需求和功能的讨论,并采用敏捷方法推荐的方式(每个人对一个故事点的估计)来做了工作量的估计,并制订了backlog和燃尽图(用以跟踪项目进度和进度问题的图表工具)。但是我们开始工作的时候,发现虽然进行了讨论,并达成一致,但是由于每个人的能力不同,对设计和实现细节的理解也不尽相同,造成每个人的工作产出物(代码)在整体结构上的不一致,五花八门的,更要命的是,由于没有事前的统一规划,每个人的实现方式都不一致,为测试和联调带来了麻烦,而且没有统一的规划和设计,如一些系统用的常量,没有放到一个地方,连异常处理的方式都不一样,有的人是往上抛让框架或者最上层去处理,有的人是把异常丢给一个统一的处理器等等,有的地方写了日志逻辑,有的地方没有!一个小组最后在一个sprint中拿出的东西是如此的混乱!在第二个Sprint期间,我们改变了策略,那就是必须进行设计,并形成一定的文档,这样可以减少不一致性,和设计不正确性的可能(每个人的设计都不一样,所以会产生这样的问题),可以减少大家沟通上的成本,有利于模块之间的整合。综上,对于敏捷开发,不是不需要设计的,而是采用较轻的文档,最直接的沟通方式,方便的讨论等等形式来确认设计的,所以说在一个Sprint前期是需要做很多事情的,如设计活动。
2) 我们每次Sprint会议开得都不错,主要是我们对敏捷开发这一块的思想理解比较透彻,
第一, 我们利用Sprint会议达到对需求理解的一致性
第二, 我们利用Sprint会议进行工作量的评估
第三, 对风险的识别
第四, 任务的分配
第五, 对各个功能点的逻辑讨论,并达到一致意见
并且我们每次Sprint结束时(也就是客户认可完成标准时),我们都会开Sprint总结会,并在公司内部建立起一个wiki用来把总结的知识登录上去,以便共享。
3) 我们基本每天开例会,也就是敏捷例会,主要目的是为了了解进度情况,可能出现的问题等等,会去Check每个人昨天完成了什么和今天要做的工作以及遇到的问题。这好像是完整地按照敏捷开发方法论的要求来做,不过在我们实施了一段时间,发现,很多时候流于形式了,这是因为对于一个复杂的工作,一天可能没有啥可以交代的,每天开例会,又给组员增加了压力,因为我每次都会问他完成了什么。后来我们觉得都没有必要每天搞一次,我就根据实际情况来安排例会的频率,有时候一天一次,有时候好几天一次。并及时地去更新燃尽图,并提交给PM。
4) 我们在项目开始前有一个Production backlog,作为一个需求的范围,但是我们在每一个Sprint开始时就是根据Production backlog来制作Sprint backlog,注意这里我们没有打散,
结果是组员对具体要做哪些具体的功能点不清楚,在做RTM时,也无法跟踪到很细的Item,所以大家就不得不化时间讨论一个Backlog point有多少子功能点。后来我们改进了工作方式,那就是在Sprint会议中把Sprint backlog尽量细化到可以操作的地步。
综上,在按照backlog工作时,不是说把故事点列上去就可以了,而是应该关注它的操作性,毕竟Sprint backlog是给内部看的,如果给客户看,那就简化一些就可以了。
5) 我们和客户商量,并按照团队的生产率,制订了2周一次Demo的计划,并事先在Sprint会议上确认了如何演示的问题,并与客户达成一致。但是当到给客户做演示的时候,问题就来了,第一,客户在看完Demo后,改更需求,虽然说这很正常,但是就影响了下一个Sprint的计划,整个进度也受到了影响,我们事先没有考虑这一点,后来我改用每个正常Sprint之间加一个缓冲sprint的做法来解决,并写到项目计划中,使得变更能尽快反映到产品中去。综上,对于Sprint,我们应该灵活对待,应该根据项目特点进行改变使用。
6) 敏捷开发方法提倡很少的文档,当不等于不要文档,文档的目的是为了有效的沟通,我们在第一个Sprint中,没有对关键部分写文档,造成沟通成本较高。所以我们应该正确理解敏捷方法中有关文档得思想!
综上,其实Scrum就是提供了一个方向,方法框架,具体怎么做,还得根据公司的特点,项目的特点,人员的特点,客户的特点来使用,并在一定条件下进行形式的变化。也就是说敏捷的核不变,但是具体的操作形式是可以变的。不能死板硬套,也不能排斥其他的方法论,一个Sprint可以看成一个迷你的传统他软件开发周期(瀑布模型),也不是不要做测试计划,也不是不要使用XP方法(可以看成一种更接近实战的方法,Srucm更加高层一些),结合不同的方法会得到很好的效果。
分享到:
相关推荐
敏捷开发实践-我们这样实践Scrum 敏捷开发实践-我们这样实践Scrum 敏捷开发实践-我们这样实践Scrum
SCRUM实践 最佳实践文档 项目经理的首选
NULL 博文链接:https://agiledo.iteye.com/blog/611562
Scrum及其实践\敏捷测试模式
NULL 博文链接:https://agiledo.iteye.com/blog/558517
有关敏捷实践的思考与总结,特别是scrum训练。汇集了众多实践者的思考,欢迎下载。
Scrum精要Scrum精要Scrum精要Scrum精要Scrum精要Scrum精要Scrum精要Scrum精要Scrum精要
敏捷软件开发之Scrum实践敏捷软件开发之Scrum实践敏捷软件开发之Scrum实践
作者花四年时间,把自己近十五年的敏捷实践经验,特别是近四年中针对各种敏捷转型企业的咨询和指导工作,并结合旁征博引的方式,从更高的思想层次对敏捷与Scrum多年来的经验和教训进行深入而前面的梳理和总结,最终...
scrum敏捷开发全景视图,流程,方法和最佳实践,最佳指导实践
团队组建 评估会议 sprint计划会议1 sprint计划会议2 每日例会 sprint评审会议(验收) sprint retrospective meeting
Scrum 是一个轻量的框架,它通过提供针对复杂问题的自适应解决方案来帮助...Scrum 可以将一些已有的实践包装进 来,也可以甄别出非必须的实践。Scrum 可以凸显当前管理、环境和工作技术的相对成效,以便 可以进行改进。
从网上下载的scrum敏捷小抄本,很适合打印出来贴在墙上供项目团队成员学习
Scrum是一个敏捷开发框架,是一个增量的、迭代的开发过程.。在这个框架中,整个开发周期 包括若干个小的跌代周期,每个小的的跌代周期称为一个Sprint,每个Sprint的建议长度2到4周。 在Scrum中,使用产品Backlog来...
Scrum的实践经历, 讲解很透彻. Scrum是跨职能团队以迭代、增量的方式开发产品或项目的一种开发框架。它把开发组织成被称 为Sprint的工作周期。这些迭代每个都不超过4周(最常见的是两周),并且无间歇地相继进行。
在一个新的公司,新的团队,实施Scrum已经快一年了,近日总结了一些Scrum实践的具体做法,和大家共享、讨论。还在总结更多的内容,例如如何保证质量、团队激励、经验总结等,希望过两天可以完成。内容见“我们这样...
Scrum 的定义 Scrum 是一个轻量的框架,它通过提供针对复杂问题的自适应解决方案来帮助人们、团队和组织 创造价值。 简而言之,Scrum 需要 Scrum Master 营造一个环境,从而: 1. 一名 Product Owner 将解决复杂...
scrum及常见问题 ,scrum及常见问题处理解决办法等等
黄枫-大型Scrum实践银行产品敏捷转型与DevOps 经验分享pptx.pdf