敏捷开发是如何被跑偏的基础入门_开发小白攻略

今天聊聊敏捷软件过程。先说结论:据我观察,至少有60%的团队误用了敏捷软件过程,或者说至少60%的团队在进行伪敏捷开发。与大家通常的认知是相反的,敏捷过程并不是一个非常容易实践或者实施的过程规范。通常来讲,没有天上掉馅饼的事儿,所以使用敏捷软件过程带来灵活性收益的同时,一定是要付出相应的代价的。例如:如果需要实行结对编程,那么在选择团队成员的时候就需要考虑人

敏捷开发是如何被跑偏的基础入门

今天聊聊敏捷软件过程。

敏捷开发是如何被跑偏的基础入门_开发小白攻略

先说结论:据我观察,至少有60%的团队误用了敏捷软件过程,或者说至少60%的团队在进行伪敏捷开发。

与大家通常的认知是相反的,敏捷过程并不是一个非常容易实践或者实施的过程规范。

通常来讲,没有天上掉馅饼的事儿,所以使用敏捷软件过程带来灵活性收益的同时,一定是要付出相应的代价的。

例如:

  1. 如果需要实行结对编程,那么在选择团队成员的时候就需要考虑人员的性格特质,或者增加相应的培训和团建活动;
  2. 如果需要实行测试驱动开发,则要求团队成员对于自动化测试的技术掌握更加熟练和深入;
  3. 如果需要进行快速设计,则会对开发人员的设计经验有一定的要求,并同时未来一定要有进行重构的时间安排才可以;
  4. 等等其它

最终,你会发现:如果一个团队没有能力实施传统的软件开发过程的话,则他们多半也无法很好的实施敏捷软件过程……

敏捷过程实施起来其实还是有一些难度的。有一些团队准备实施循序渐进的策略:针对敏捷过程所要求的一些最佳实践,先上一些比较容易实施的,然后在陆续加入其他。

令人失望的是,这样的做法也会引发一些问题。就拿非常流行的极限编程来讲,极限编程所要求的最佳实践实际上是相互循环依赖的!所以仅仅选择某几项最佳实践来进行实施的话,最终会导致整个系统的崩溃!比如:

  1. 极限编程讲究的是快速设计,但是其最终的设计合理性和最优性是由CRC讨论会和后续的重构动作来保证的;
  2. 极限编程省略了冗长的需求分析文档,代之以即用即抛的“用户故事”;但是为了保证功能的正确性,他会有一个更加严峻的要求:现场客户;
  3. 极限编程没有专门的测试阶段,那么如何保证产品的质量呢?辅助以三个最佳实践:结对、测试先行和持续集成;
  4. 重构动作保证了架构的最优化,但是谁来保证重构不会对系统带来负面影响呢?测试先行和持续集成;
  5. 类似的等等

于是,有不少团队在实行了敏捷软件过程之后,仍然停留在(或者说倒退回了)游击队式的野生软件开发过程。

那么如何才能够正确的实施敏捷开发过程呢?我理解,至少需要具备如下的前提,才能够比较顺利的实施敏捷过程:

  1. 团队成员对面向对象的开发和设计有相当程度的理解和经验(最起码有想要提高或者学习的需求);
  2. 团队成员能够熟练的使用自动化测试的框架,并编写自动化测试脚本;
  3. 团队成员能够熟练的使用持续集成的框架或者产品;
  4. 团队成员平均沟通能力中上,没有表达能力低下者;
  5. 至少有一个渠道能和客户(或者有足够话语权的客户代表)进行频繁并流畅的沟通;
  6. 管理者(包括甲方客户)和开发团队之间有相对比较平等的话语权;
  7. 管理者(包括甲方客户)能够理解(或者信任)开发团队所提出的一些隐性的工作量(例如重构、编写文档、测试脚本等)所带来的时间成本;

上述看似并不太高的门槛,却挡住了60%的软件开发工程师……

海计划公众号
(0)
上一篇 2020/03/30 07:19
下一篇 2020/03/30 07:19

您可能感兴趣的内容