CargoSmart公司从2008年起,通过引入专业的敏捷开发咨询公司,开始由以往的RUP开发模式(User Case Base)向敏捷开发模式(Iteration&Increasement,User Story Base)转型,我们的敏捷开发转型, 是先由咨询师和一个种子团队(包括BA, QA, SA, Dev etc. 不同的role)以敏捷软件开发模式一起共同完成一个项目完整的Release Lifecycle,然后把这个种子团队的成员分散到不同的开发团队中,由此在整个组织中传播推广敏捷开发的实践。
经过两年多的实践经历,我们有所收获也有经验教训。
以下就分享一些在实践中遇到的问题和我们的认识反思,供大家学习借鉴。
没有分析和设计
敏捷开发强调简单设计,团队每个成员都从接触客户到分析设计,到编码,全部承担。但是实际上团队成员的素质参差不齐,如果只有简单设计、立即编码,而没有后续的持续重构等实践,将导致设计混乱不一致,尤其是对老系统的功能升级,如果Impact分析不够,弱化了分析设计,将导致很多工作在后期频繁变更,使得团队的挫折感增强,产生较多的重复工作和浪费。
必要的系统架构和设计从来都是非常重要的。只是这里的分析设计有别于传统的开发模式,应该应用敏捷的思想,简单设计,持续重构,尽快反馈等。
敏捷拥抱变化,所以变化可以随时随地发生
因为敏捷的导向,可能造成的问题是,前期需求比较随意,对需求质量的控制弱化,需求变更更加频繁。
(1)需求质量的审核,仍然需要改进,需求方向性的错误将导致后续一系列的工作浪费,所以团队内部应该设定里程碑和review标准,从而确保基本的需求质量。
(2)在Iteration里需求尽量不要变更,明确 Iteration 的边界。否则频繁的变更导致团队没有成就感,方向和目标不明确。
(3)敏捷讲求业务价值导向,有些变更从业务价值上看,可能并非真正需求急切变更。
有些变更通过更好的Impact分析和设计应该也可以避免。BA和SA等不同的角色应该一起配合来做出Impact 分析,以供决策。
一些敏捷实践容易实行,一些比较困难。所以割裂敏捷实践的关联,孤立地实践少数的敏捷实践
其实上面的很多问题都是由此导致的,敏捷开发之所以可以替代以往传统开发模式,是因为一组(系列)的开发实践来共同代替以往开发模式。孤立的引入少数实践,通常不能给团队成员感觉有大的改进,从而也放弃对敏捷开发的信心。
例如Stand-up Meeting. 这是一个比较容易的实践,但是如果没有背后的需求转化为比较容易衡量的Story-base, 没有BA、 QA 等共同参与基于Story-base去沟通, 没有Offline of Meeting更多的面对面沟通交流,没有大家彼此知道对方的工作内容(Code Ownership),那么可以设想这种Stand-up meeting和以往的传统的开发模式,Leader 布置任务检查任务进度没有任何区别。
再如简单设计实践,如果没有背后的结对编程、重构等实践,必然导致比较混乱的代码,很难维护的架构,难于扩展,重复实现类似功能等弊端。
再如持续集成(CI),即使这是公认敏捷软件领域内相对没有争议的一个实践,但是如果没有与TDD结合,没有与持续重构,没有与小的Story,快速频繁Deliver等实践结合在一起,并且坚持保持CI的健康,也会让团队成员觉得CI效果不如宣传,从而对敏捷实践等产生质疑。
以上是我们在敏捷开发实践中遇到的几个典型问题,以及部分经验教训的反思总结。
相关链接: