进入敏捷开发之前你想好了么?
上一篇 /
下一篇 2012-12-10 09:40:32
/ 个人分类：流程
好吧，我已经准备好被喷了，但这些也是我很多年前就想说的，请静下心来看。
首先，我需要说明的是，
敏捷开发这件事情，的确有利于在软件研发期加快开发速度和团队溶合，增进团队的互相了解。
但是很多人在不了解这件事情的好处和坏处就开始实施了，然后发现团队适应不了，原本完整有效的开发流程变得混乱，质量无法有效率地进行监控，维护困难，有些项目到中后期完全与项目定义偏离只有砍倒重来。
我简单以我的角度来理解这种方法，也希望各位理性思考一下，欢迎提出不同看法
1.团队能力
敏捷这件事情，首先要求你的团队几乎是全能的，必须在需要的时候每个人能够很好地完成自己份外的事情。
但这种要求在现代中大型公司几乎是不可能的事情。现代大型
软件开发，都不是一个人的事情，每个模块的代码量和复杂度都远不是一个人能够在短时间里熟悉得了的，人力资源的调派必然受到挑战。何况敏捷这种方法，需要每一个开发者都是需求分析，架构，编码，甚至
测试。更何况，刚入职的学生怎么办？
2.无障碍沟通
有很多公司很看好敏捷的原因，就是因为它的沟通过程。但是，在国内企业每天的站立会议里几乎每天都被走走过场安排一下
工作，需求评审流于表面，因为面子问题不好当面质疑，自尊问题造成的争吵，固执己见的开发所充满。
说实话，在国内团队现有的技术状态和大多数开发都极其自信的情况下，沟通的效率和时间花费会很不理想。 何况，开发者大多就不善于与人沟通，更不要说与客户沟通了。
轻文档，意味着需求不明，意味着可以随时随地自由发挥，意味着难于维护甚至无法维护，意味着分支版本的管理没办法做，意味着最终结果可能远远偏离大家刚开始的预想。
在现有国内企业甚至很多跨国公司在迭代开发模式下都无法确保按天、按周进行开发质量，需求进行管理的情况下，没有多少公司能够在这种轻文档模式下有效控制风险。
需求随时变更，工期和里程碑安排就没有任何意义。因为无法确定每个里程碑要做哪些主要的事情，无法确定这些事情最终会花掉的时间，没有需求评审，没有项目定义，没有定位评估，没有流程，没有绩效考核，最终只能导致混乱。
5.自觉性和主动性
我并不是想否定现在大多数开发人员的主动性和自觉性。但是做
项目管理的大家都知道，大多数公司如果没有工作安排或者自由度比较大靠员工主动去控制，结果就只能不断延期，我甚至见过有公司因为这些混乱一个项目延期了两年的。敏捷的要点在于，每个开发者都积极地参与到项目的开发中，把项目作为自己的一部分，主动参与需求的发现、评价、构建、监控等等流程。试问，有几家公司团队中80%以上的开发者都是这样的？有这样的一群员工，PM，PD，VC，QA睡着都会笑醒了。
文档化的意义在于需求明确，有据可查，偏离控制和责任追踪。这些在敏捷的条件下，没有办法完成。在迭代模式下，当文档需求不全的情况下，我们可以通过需求评审，需求分析，架构分析，测试分析，用例等等文档的维护来修正并确认不同的需求变更。敏捷又怎么做呢？探索测试？不要搞笑了，不就是Monkey Test么，没有需求验证叫什么QA、QC，只要会操作可以做了，又要QA、QC、内审员等等员工来做什么。质量控制最重要的要点就是在有限的时间里最有效的保证质量，需求、流程、产品模块无据可查，拿什么做用例覆盖。
以上，见解很浅，欢迎讨论。
收藏
举报
TAG:
