• 设为首页
  • 点击收藏
  • 手机版
    手机扫一扫访问
    迪恩网络手机版
  • 关注官方公众号
    微信扫一扫关注
    公众号

C项目敏捷实施(2)-第一次迭代

原作者: [db:作者] 来自: [db:来源] 收藏 邀请

就这样,C项目组糊里糊涂的开始了敏捷之旅。在第一个迭代完成后:

基本情况

2011年2月21日-3月4日,项目组成员每天站在白板前进行每日站立会议。如果发现了需要讨论的话题,就在会后进行讨论。

2011年3月4日,项目组进行了第一次回顾会议。没有评审会议了,因为项目组仅完成了预估工作的不到一半,仅提供了一个Demo。

第一次回顾会议

团队在白板前进行第一次迭代回顾,会议总耗时一个小时。会议结果如下:

1. 做得好的

a)         成功完成Demo,所有Bug都修复了。

b)        每日站立会议对团队有很大帮助,可以清楚知道团队其他成员在做什么。团队协作比以前更好了。

c)         感谢美国团队的及时响应。

d)        感谢团队成员的认真负责,开发和QA联手解决了浏览器兼容问题,开发把Silverlight的单元测试集成到每日构建中。

2. 需要改进的

a)         UI是个瓶颈,开发流程不顺畅,有时会等待。

b)        没有完成工作计划。

c)         会议太多,时间太长。

3. 改进计划

暂略。

分析与思考

纠结的目标

第一次迭代是相当纠结的一个迭代。完成既定的任务,遵照Scrum的流程和建立自组织团队,这三个目标交织在一起。在其中还混杂着,证明敏捷优于以前模式的压力,这部分压力承载了证明自己的期许,公司管理层的期待和团队参与者们的期望。

残酷的现实

从很多方面来看,第一次迭代都不能算成成功。团队承诺的过多,甚至算不上团队承诺,而且不能顺利完成。工作流程中暴露出很多问题,瓶颈变得显而易见。

从乐观的角度看,也有些进步。团队在持续解决工作中出现的问题,合作与沟通也在进步中。

怎么办?

很多团队都是在第一、二次迭代中不能顶住压力,最后只好回归以前的工作方式。

1. 意识灌输

在暴露出的各种问题面前,团队显得无助,怀疑论正在成长。作为敏捷推动者,要知道“坏消息就是好消息”,不停询问团队“这样的问题在以前的模式中能够发现和解决吗?”让这些问题暴露出来,这本身就是敏捷实施的成果。

2. 顶住压力

不管怎样,项目交付的压力持续存在,而管理层因实施敏捷对团队的关注,导致压力持续增大。作为敏捷推动者,在这时候要顶住压力。一个好办法是告诉团队,管理层对团队当前的工作进度并不满意,让我们一起来想想办法解决这个问题。

3. 培养信心

作为敏捷推动者,不要过于强调我有好办法,要注意发掘团队的闪光点。这是培养自组织团队最有效的一种办法,认可和表扬团队的闪光点,培养团队自主改进的信心。


鲜花

握手

雷人

路过

鸡蛋
该文章已有0人参与评论

请发表评论

全部评论

专题导读
上一篇:
C++中的new/delete发布时间:2022-07-13
下一篇:
C#反射机制发布时间:2022-07-13
热门推荐
阅读排行榜

扫描微信二维码

查看手机版网站

随时了解更新最新资讯

139-2527-9053

在线客服(服务时间 9:00~18:00)

在线QQ客服
地址:深圳市南山区西丽大学城创智工业园
电邮:jeky_zhao#qq.com
移动电话:139-2527-9053

Powered by 互联科技 X3.4© 2001-2213 极客世界.|Sitemap