故障发生前为什么敏捷团队的成功?
2015-07-17 18:35
267 查看
9有一天,一月,我参与日常微信智沙龙的发展,他讲述了一个成功的团队的故事了第一个敏捷。失败后,故事,著名的人从一个特定的公司实例。伟大。
后沙龙,丰满老王整理博客《一个成功敏捷团队的失败历程》。(转载在 /article/2695025.html )
本文试着从我的视角来分析下为什么?
首先来看其前期为什么成功?
1,项目经理首先选用了Scrum。决定实施自己主动化測试,同意測试落后开发一个Sprint
2,美国老大不惬意。要求开发測试必须同步。制定强制要求,引入TDD(被老大逼迫使用的)
3。项目经理进一步要求,开发者必须參与集成測试Case的编写
以上看起来是命令驱动的结果。将常见的敏捷实践用起来了。
那么为什么后期失败呢?
1,项目经理和測试Leader离开团队,尽管来了一位美国架构师,但后来他也离开了。
2,原測试人员的顶头上司(測试部门经理)转变了职能
3,没有人真正关心质量。原来的敏捷实践-结对。TDD被放弃,自己主动化測试用例不再维护
咕咚老王对于前期成功的分析是“前一个产品开发阶段的敏捷。是权威下的“敏捷”。之所以成功。不是形成了真正敏捷的自组织团队。而是在项目管理人员的个人权威之下。实施了真正的敏捷实践。”
所以能够看到,真正的敏捷实践能够带来团队的成功,尽管没有形成真正的敏捷自组织团队。
咕咚老王在文中推荐了敏捷教练/Scrum Master。这是一个不错的解决方式。
但除了这个解决方式之外,还是否有其他方案呢? 笔者推荐例如以下的2个方案
1,保持权威,既然权威敏捷带来了成功,何不发挥这样的方式。
2,将形成的好实践落在团队章程上,形成组织+团队双重监督
对于保持权威,即是让续任的项目经理继续坚持好的实践,续任的项目经理要相同的理解敏捷实践。理解当中利弊,能够做出权威的正确决策。这事实上是对一个组织的项目经理培养机制的考验。一个成功的项目经理晋升了,续任者不可能有前任相同的看法和经验。中国人信奉新官上任三把火。续任者总是有些不一样的。“萧规曹随”尽管也是国人古代的智慧。但貌似在中国用得不多。
眼下而言。培养权威的项目经理较之培养合格的敏捷教练,我觉得培养前者更easy些。
在东方官文化下。合格的敏捷教练实在是太稀缺了。
而对于团队章程。即是将团队得到的好做法记录下来。在Scrum中推荐制定完毕定义DoD,这事实上就是团队章程,或者说章程的一部分。
团队章程在每一个(或者每2个)迭代的回想会议上得到更新的机会。把最新的好实践加到团队章程中。
增加的方式能够是自组织的方式,也能够是权威方式。
权威方式获得的团队章程将高于权威,也即是团队章程不会被权威轻易的改动。
团队章程的形成会对权威形成制约。
这样固化后的共识不会留下个人权力的工作人员由于消散。
后沙龙,丰满老王整理博客《一个成功敏捷团队的失败历程》。(转载在 /article/2695025.html )
本文试着从我的视角来分析下为什么?
首先来看其前期为什么成功?
1,项目经理首先选用了Scrum。决定实施自己主动化測试,同意測试落后开发一个Sprint
2,美国老大不惬意。要求开发測试必须同步。制定强制要求,引入TDD(被老大逼迫使用的)
3。项目经理进一步要求,开发者必须參与集成測试Case的编写
以上看起来是命令驱动的结果。将常见的敏捷实践用起来了。
那么为什么后期失败呢?
1,项目经理和測试Leader离开团队,尽管来了一位美国架构师,但后来他也离开了。
2,原測试人员的顶头上司(測试部门经理)转变了职能
3,没有人真正关心质量。原来的敏捷实践-结对。TDD被放弃,自己主动化測试用例不再维护
咕咚老王对于前期成功的分析是“前一个产品开发阶段的敏捷。是权威下的“敏捷”。之所以成功。不是形成了真正敏捷的自组织团队。而是在项目管理人员的个人权威之下。实施了真正的敏捷实践。”
所以能够看到,真正的敏捷实践能够带来团队的成功,尽管没有形成真正的敏捷自组织团队。
咕咚老王在文中推荐了敏捷教练/Scrum Master。这是一个不错的解决方式。
但除了这个解决方式之外,还是否有其他方案呢? 笔者推荐例如以下的2个方案
1,保持权威,既然权威敏捷带来了成功,何不发挥这样的方式。
2,将形成的好实践落在团队章程上,形成组织+团队双重监督
对于保持权威,即是让续任的项目经理继续坚持好的实践,续任的项目经理要相同的理解敏捷实践。理解当中利弊,能够做出权威的正确决策。这事实上是对一个组织的项目经理培养机制的考验。一个成功的项目经理晋升了,续任者不可能有前任相同的看法和经验。中国人信奉新官上任三把火。续任者总是有些不一样的。“萧规曹随”尽管也是国人古代的智慧。但貌似在中国用得不多。
眼下而言。培养权威的项目经理较之培养合格的敏捷教练,我觉得培养前者更easy些。
在东方官文化下。合格的敏捷教练实在是太稀缺了。
而对于团队章程。即是将团队得到的好做法记录下来。在Scrum中推荐制定完毕定义DoD,这事实上就是团队章程,或者说章程的一部分。
团队章程在每一个(或者每2个)迭代的回想会议上得到更新的机会。把最新的好实践加到团队章程中。
增加的方式能够是自组织的方式,也能够是权威方式。
权威方式获得的团队章程将高于权威,也即是团队章程不会被权威轻易的改动。
团队章程的形成会对权威形成制约。
这样固化后的共识不会留下个人权力的工作人员由于消散。
相关文章推荐
- java集合运算:求交集,并集,集合差
- YUM常用命令详解
- Lua模拟类,继承,私密
- “牛市”惊涛骇浪中的股友们
- 表单验证
- Binary Search Tree Iterator
- 直方图均衡化和规定化
- 关于数据库性能优化小经验
- UVa221 以后用区间覆盖问题解决
- hibernate中出现 文档根元素 "hibernate-mapping" 必须匹配 DOCTYPE 根 "hibernate-configuration"
- 来咯
- 数组的使用
- mac Charles 使用
- leetCode(42):Flatten Binary Tree to Linked List
- 如何判断正整数(非正则表达式)
- leetCode(42):Flatten Binary Tree to Linked List 分类: leetCode 2015-07-17 18:31 96人阅读 评论(0) 收藏
- char最大值和最小值表示方法与左移右移
- Golang:slice之append时原数组发生变化的问题
- 关于分钻石的数学题有五个海盗得到了一百颗的钻石
- win8改win7笔记