|
锁定老帖子 主题：敏捷与能力
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-05-09
团队实施敏捷，经常会遇到的一个问题是：“实施敏捷对个人能力要求高吗？”其实不止是正在实施的团队，国内各个敏捷社区、论坛 上也充斥着这样的论调：“实施敏捷对能力要求太高了，如果团队成员的能力达不到一定的程度，还是不要实施敏捷的好”。 为什么大家会有这样的问
题？有些是实施中确实遇到的，更多的则是臆测推断出来的；在大家把问题统统归结为“个人能力”之前，我们还是先澄清一下能力的范围，是指在开发过程中，团
队各种角色（BA、QA、DEV、PM）由于自身角色能力不足，导致团队无法交付、时间拖延或者产品质量低下。我们先来看看出现的一些确实出现过或者凭空
臆测的典型问题：
某团队开发速度很慢，大大低于预期。为什么呢？多数开发人员对随用的语言和框架不熟练； 我们团队要采用TDD方 式编写自动化测试，除了开始一个月，后面大家很难坚持，一定是大家能力不行； 项目的Bug太多了，开发人员经验太少； ... 这 些问题都很奇怪，如果不采用敏捷，难道就不会出现上面的问题吗？当大家转而使用传统的开发方式时，上面的问题难道就会自动消失吗？ 丰田精益生产方 式中一个经常用的隐喻是“湖水和岩石”。大意是指湖水太深，你无法发现阻碍当前生产的主要原因，只有把湖水讲下去，才能发现真正的岩石在哪里。在精益生产 中，湖水是指“库存”，而在软件开发中，对应的湖水则是“迭代周期”。 我们举一个例子，当发现“项目严重延期”时，通常已经是交付时间，不过开发 人员最近一直加班，也挺辛苦的呀。不过如果你是项目经理或者客户，你知道开发人员的时间都花到哪儿了吗？如果采用迭代式交付，每两周一个迭代，完成一定的 特性，你可能第一个迭代就发现问题了：开发人员Java语言的经验太少，光是IDE、构建环境就装了好几天；接下来的迭代你发现了更多的问题：开发人员根 本没有开发过web，每天上班就是在学习Web开发，加班时才是在干活... 我们可以抱怨团队开发人员能力不够，不过这关敏捷的什么事儿？本来大 家都知道的事情，只不过敏捷让它暴露的更严重更突出罢了，谁还会任由你“掩耳盗铃”呢。 如果你知道项目中可能存在问题，如果你想改进一下 当前的流程，为何不试试敏捷呢？把湖水（迭代周期）降下来，把岩石露出来，你会发现很多很多的问题。多数问题都跟能力有关吗？可能吧。不过能力都怨敏捷 吗？我不信。
声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2010-05-09
老话说，我不杀伯仁，伯仁因我而死
谁想去帮别人发现问题，谁就得帮别人解决问题 如果你压根没打算帮人解决问题，那么你就不要去撺掇别人发现问题 别人原来就算有一千个问题，至少他活着 你去把他肚子拉开了，指着里头说，你看，一大堆的瘤子，啧啧，都烂了也～～ 然后他一害怕一忧虑一悲哀，就真的死了 这个时候你又说，唉呀，害死你的是瘤子不是我，难道我不看见，瘤子就不会害死你了么？ 他会死。但不是现在。 他之所以现在死了，就是我开头说的那句话。 |
| 返回顶楼 | |
|
发表时间：2010-05-09
如果是重要的项目，值钱的产品。不会出现这样的团队能力问题的。团队的能力出现问题就是因为你做的事情还不值得领导或者客户出大价钱。软件开发的问题就在于软件自身的价值与合格开发团队价格之间的矛盾。所以要指望能力强调团队做高质量的交付，就得先企盼你要做的事情是值得下大本钱的东西，不是口头的重视，是真正舍得砸钱在开发人天上掉重视。
|
| 返回顶楼 | |
|
发表时间：2010-05-09
我觉得实施敏捷与实施CMMI都有一个误区，一开始就把最佳实践拿出来照着做，但一个人是无法从一种还没有掌握的方法中受益的，即使那是一个好方法。
你真的想推广TDD，首先你自己必须在TDD方面是一个很有经验而且确实受益的人，其次你必须通过大量的实践引导你的组员用TDD去做，这种时候你和他结对编程就是一种好的办法。 敏捷的很多东西确实有效，但是敏捷并不是一份免费的午餐。你的组员最高的工作效率必定是他现在熟悉的方法，你要改进这种方法，就会进入一个改进期，这段时间里他不可能发挥出使用新方法的真正水平，并且工作效率还会不如从前。这是一种权衡，依据就是你本人对新方法的认识，以及对项目的考虑，对团队未来的考虑等综合因素。 如果一切都没有进行过认真的判断就贸然革新新的生产方式，那必然是要失败的。 |
| 返回顶楼 | |
|
发表时间：2010-05-09
gigix 写道 老话说，我不杀伯仁，伯仁因我而死
谁想去帮别人发现问题，谁就得帮别人解决问题 如果你压根没打算帮人解决问题，那么你就不要去撺掇别人发现问题 别人原来就算有一千个问题，至少他活着 你去把他肚子拉开了，指着里头说，你看，一大堆的瘤子，啧啧，都烂了也～～ 然后他一害怕一忧虑一悲哀，就真的死了 这个时候你又说，唉呀，害死你的是瘤子不是我，难道我不看见，瘤子就不会害死你了么？ 他会死。但不是现在。 他之所以现在死了，就是我开头说的那句话。 识别和治疗为什么非得是一套体系？任何悖论都可以用另外一个悖论来反驳： 别人有一千个问题，他活着，但是活的很痛苦 你用西医去把他肚子拉开了，指着里头说，你看，一大堆的瘤子，啧啧，都烂了也～～应该是癌症吧，但是西医治不了。 至少他知道了是癌症，他就可以想各种办法了：找大仙，跳大神... 我觉得不会别原来差，没准给跳好了呢 |
| 返回顶楼 | |
|
发表时间：2010-05-09
“迭代周期”不如“反馈周期”更贴切。
|
| 返回顶楼 | |
|
发表时间：2010-05-10
我感觉如果有时间还是帮其它人发现问题为好，要不感觉太自私了
|
| 返回顶楼 | |
|
发表时间：2010-05-10
aqingsao 写道 gigix 写道 老话说，我不杀伯仁，伯仁因我而死
谁想去帮别人发现问题，谁就得帮别人解决问题 如果你压根没打算帮人解决问题，那么你就不要去撺掇别人发现问题 别人原来就算有一千个问题，至少他活着 你去把他肚子拉开了，指着里头说，你看，一大堆的瘤子，啧啧，都烂了也～～ 然后他一害怕一忧虑一悲哀，就真的死了 这个时候你又说，唉呀，害死你的是瘤子不是我，难道我不看见，瘤子就不会害死你了么？ 他会死。但不是现在。 他之所以现在死了，就是我开头说的那句话。 识别和治疗为什么非得是一套体系？任何悖论都可以用另外一个悖论来反驳： 别人有一千个问题，他活着，但是活的很痛苦 你用西医去把他肚子拉开了，指着里头说，你看，一大堆的瘤子，啧啧，都烂了也～～应该是癌症吧，但是西医治不了。 至少他知道了是癌症，他就可以想各种办法了：找大仙，跳大神... 我觉得不会别原来差，没准给跳好了呢 很多人没发现癌症之前还是能吃能睡的，一检查出来就彻底倒了。 敏捷对能力要求高这点不用怀疑，怀疑的人一定没有搞过，至少没有尝试过敏捷。 |
| 返回顶楼 | |
|
发表时间：2010-05-10
引用 这 些问题都很奇怪，如果不采用敏捷，难道就不会出现上面的问题吗？当大家转而使用传统的开发方式时，上面的问题难道就会自动消失吗？
如果不采用敏捷，上面的问题还是存在。但采用敏捷以后，又多了一个问题：他们不懂敏捷。 |
| 返回顶楼 | |
|
发表时间：2010-05-10
正在学习 敏捷开发
|
| 返回顶楼 | |
