思步网

思步网 首页 行业领域 敏捷开发 查看内容

Sprint会议和关键任务

2018-2-14 10:32| 发布者: 思步网| 查看: 506| 评论: 0|原作者: nini

摘要: 晨会中有个框架调试的任务没有搞定,而这个任务的成果恰恰是多个工程师任务验证的一个依赖条件,因此,导致昨天乃至前天的部分任务没有能够验证。 今天的晨会 ...
昨天没写,是因为昨天的故事在今天才有个结果
昨天的晨会中有个框架调试的任务没有搞定,而这个任务的成果恰恰是多个工程师任务验证的一个依赖条件,因此,导致昨天乃至前天的部分任务没有能够验证。
今天的晨会,大家心情都很愉快,因为这个阻塞任务可以移到Done区域了,很多相关任务也都可以验证完成了,按照平均每天搞定6Day的任务计算,昨天阻塞任务Done后,今天晨会一下子转移了11Day的任务后。燃尽图的趋势向理想趋势靠拢,这无疑是让大家都比较开心的
 
这里有两个反思
一:Sprint计划一定要共同做
正如我在8.27的日志(点击链接《下一阶段任务分解》中所说的,是PM、DPM和工程师一个个分解需求、细化任务的,这样的好处是节约时间,每个人都可以把注意力集中在自己的任务中。效率更高。
然这样做工程师彼此之间的工作了解是不够的,我们也考虑到这方面的欠缺,不过我们从自身的经验出发,觉得PM、DPM对各模块间关联的具体情况非常了解,可以弥补工程师彼此间计划阶段沟通不充分所带来的风险,但从这次实践来看,我们的前提并没有达到。
这次的实际问题是某个框架调整任务没有按时完成,而其他很多任务的验证都是基于该框架调整完成的基础,计划的时候也考虑到这种依赖关系,但对于该任务需要消耗的时间估计比较乐观,没有设置buffer,而结果是此任务耽误了一天,相关的一堆任务在框架完成后都得到了验证通过,实际上,这次并没有出现什么资源浪费。
Scrum经典要求是Sprint计划要大家共同参与,我们明白这个道理,但还是把他裁剪成一个个沟通确认,这是我们认知上觉得这样可接受,值得让我高兴的事情,现在我们以最小的代价让Team接受Sprint一起开的重要性,真是塞翁失马焉知非福
我们今天晨会达成一直,今后一个个讨论完任务后,集中花一段时间把所有需求和任务讲述一次,让所有项目人员来共同确认
 
二、更多关注关键任务
传统项目计划中,关键任务是很重要组成部分,由关键任务组成的关键路径是对项目周期估算的重要证据。
而在经典Scrum的任务看板上,从一个Sprint到下一个Sprint,虽然路线非常清晰,但在同一个Sprint内,虽然理论上所有任务都应该完成,所有Backlog都需要搞定,但我们未必真的能够理想的完成所有任务,在不能百分比完成的情况下我们要尽可能好的结果,也就是说我们需要定义一个Sprint中把最重要的任务,以确保这些任务获得更多的关注。
在《轻松Scrum之旅》这本书上的附页上,有一张任务板的实例图,这张纸加膜了,照相不清楚,干脆自己照原版的样子画了张
和经典Scrum看板不同的是,此图增加了“被阻塞”的任务,这可以更方便的让人关注,我无从得知所谓“被阻塞”的标准是什么,是否是超过预期天数的未完成任务(比如超过2天以上)?或者是被2个以上任务共同依赖的未完成任务?或者其它我想象不到的标准……
无论哪些标准,我觉得,被阻塞是一种事后加强补救的措施,能不能转化成事前加强预防的任务呢?
这个貌似比较难,我不确定在Scrum任务中,再增加彼此的依赖关系会不会违背敏捷原则,这个需要继续观察。
我现在可以继续尝试的,是在我们公认觉得被阻塞的任务上加上一个红色的圈圈,这样可以更醒目些,当然,前提是这些情况不要太多,不然的话这个Sprint基本上也失败了。
分享到微博 收藏 分享 邀请

最新评论



思步组织思步科技|思步网|火花学堂|思步文库|思步问答|思步英才|天下心
© 2007-2017 思步网 浙ICP备10212573号-4(首次备案号:浙ICP备07035264号)|邮箱:service#step365.com(将#换成@)|服务热线:0571-28827450
在线培训课程|求职招聘|思步文库|官方微信|手机APP|思步问答|微博平台|官方QQ群|交流论坛|软件工程透析|关于我们|申请友链|
点击这里给我发消息     点击这里给我发消息
思步 step365 过程改进 CMMI中文 质量保证 质量管理 流程体系 需求跟踪矩阵 敏捷开发 Scrum 软件度量 项目评审 全员改进 流程管理 人力资源 6sigma 信息安全 ISO27001认证 IT服务管理 ISO20000认证 ISO9000认证 软件测试 SQA 配置管理 IPD 软件工程 PMP认证 PMP试题 PMBOK中文 精益研发 agile 顾问式管理培训
返回顶部