敏捷开发在软件开发中的应用

1 实现敏捷在软件开发中的应用

1.1 敏捷方法和企业架构和谐共舞

一份来自Cutter Consortium的报告向我们提出了这样一个问题:“敏捷方法和企业架构兼容吗?”并且也给出了这样一个答案:“是的, 但需要付出努力”。该报告的作者推荐运用特殊技巧以允许敏捷方法和企业架构互相受益。此外, 他们的观察结果、分析和建议也直接是适用于敏捷方法和“面向服务的架构SOA”之间的结合。

企业架构 (EA) 和敏捷方法 (AM) 拥有共同的目标——交付能够跟业务需要对齐的软件, 并响应对这些业务需要无可避免的变更。然而, EA和AM在达成这个目标时却采用了截然不同的方式。

一个曾经使用过其中一种但因为缺乏对另一个的使用而失败了的项目会最大程度拥有使用两者的经验。例如, 一个重要的文档处理系统可以使用最好的AM实践开发出来, 但不能协调好系统的EA需要如跨越需求、接口、和操作性问题等。作为选择, 一个采用瀑布方式的项目会准备妥当它的所有的企业架构, 但是却不能向及早的向客户展现它的价值, 或者不能够通过有意义的迭代来解决风险问题。所以, 这些paper都是来自于经验的, 例如:项目是如何因为忽略了其他可行的规程才陷入这种境地的, 有效的处理方式是什么等。

一个意义更加深远的案例可能是在项目启动时均衡EA和AM。然而, 这其实非常难, 很少发生, 主要是因为组织性问题, 以及谁在过程的哪个部分被涉及的角度。你会看到很多的失败, 例如架构师跟客户 (更惨的是在根本没有客户) 但没有开发团队参与的情况下整理需求, 然后开发团队脱离开架构师进行接管。

一个推荐的方案是, 对一个AM团队而言它被当作架构的一个包含部分, 作为每个团队的成员与EA组进行联络。当被要求阐明推荐Architect Reloadus或是Architect Oryzus (其定义见Martin Fowler的Who Needs an Architect) 中的哪种架构类型时, Michael Rosen建议哪种也不采用。所以, 拥有E A组和A M团队的组织不必要互相容忍, 虽然他们拥有共同的目标, 他们的缺省操作模式是不与其它成对的并且 (成对使用通常会) 产生问题。因此这些实践等对达成企业的战略目标和交付战术性的软件项目非常有用。

1.2 走向敏捷三模式

敏捷联盟创始人之一、咨询师兼图书作者Mike Cohn最近根据其自身经验将“如何帮助团队采纳敏捷”总结为三对核心模式, 当团队向敏捷过渡时, 可以利用这些模式。Mike建议, 团队或者组织在逐步采用敏捷的过程中, 应该从每对模式中选出一个最适合他们自身情况的模式。

范围有多广:“小步前进”还是“全面推广”。

“小步前进”是指最初在一个试航团队中尝试敏捷的转型, 然后逐渐推广到整个组织中的方法。Mike建议, 这种方法在以下几个方面具有优势:最小化因错误而导致的成本、将最初成功的可能性最大化、培养内部的“专家”, 以协助后期推广过程的顺利进行。Mike紧接着提及三个隐患:团队在试验阶段产生的早期的成功, 可能会给整个组织带来错误的期望;组织推广所用的时间会更长;一旦失败, 怀疑者将把其视为公司无法实现承诺的一种信号。

与其相反, “全面推广”的特征是从一开始就让所有团队进行转型, 它可以在以下方面让企业受益:展现管理中的各种承诺, 组织会变得更加灵活, 避免同时使用两个过程带来的不一致, 以及减少总体上的抵触感。Mike同时也指出了“全面推进”的缺点:高风险, 高开销, 可能需要机构重组, 会遇到来自于组织的很大压力。

1.3 如何对待技术:“技术实践优先”还是“迭代优先”

“技术实践优先”要求团队接受敏捷是从关注XP的诸多实践开始的, 比如简单设计、测试驱动开发、结对编程、持续集成以及短迭代周期。它带给团队的好处是:转型的启动非常迅速而且平滑。Mike指出这种方法的不足在于:通常较难做到, 而且会导致开销激增, 同时还可能将团队带离以用户为中心的思考, 从而失去了敏捷的真正意义。

相反, “迭代优先”方法, 它最初只关注“团队以迭代方式工作”, 一旦这个目标受到阻碍, 才着手改变技术实践。它的优势可能在于:它很容易实现, 而且遇到团队成员抵触的可能性很小。但也有另一个风险:团队可能永远也不会采用对于改善敏捷而言最基础的工程实践。

1.4 可见性怎样:“秘密行动”还是“公开推广”

“秘密行动”是指团队在采用敏捷实践过程中积累的大量知识只保留在团队的内部。它允许团队在受到其他人关注之前就能获得成功, 这就是它给团队带来的好处;那些关注即来自于希望模仿他们的人, 也来自于可能会反对他们的人。其缺点包括:难以获得组织所能提供的必要的支持, 同时, 即使这个团队成功了, 也不容易说服怀疑者们去信服。

“公开推广”是指团队在采用敏捷过程中所做的努力对于团队以外甚至组织以外都是公开的知识。它的优势在于:它会激励团队去坚持采用敏捷之路, 帮助团队得到外部的支持, 更早地发现怀疑者们的疑虑, 并证明高层管理者支持这种变迁并希望它成功。其可能引起的不良后果是, 假如公开宣布开始做某件事, 最终却没有成功, 别人会认为这是非常鲁莽的, 也就是说, 此时反对者的质疑声就彻底抵消了这种方法的优势所在, 而这正是“公开推广”的劣势。

2 敏捷开发中常见问题

2.1 在软件开发中, 人的因素要远远大于过程和技术, 人是有缺陷的

(1) 容易犯错误, 因此必须在错误扩散之前找到并改正错误; (2) 当觉得可能失去较多的时候, 不愿意冒险; (3) 重新构造而不愿意重复使用已有的东西; (4) 难于坚持一个习惯。

2.2 针对个人因素的几个建议

(1) 具体的模型较抽象的模型更容易理解; (2) 从一个例子开始是容易的; (3) 通过观察他人的成果学习; (4) 要有足够的不受打扰的时间; (5) 分配的工作要与个人意向, 能力匹配; (6) 不正确的奖励会有坏作用, 从长期看个人兴趣比奖励更重要, 培养在工作中的自豪感; (7) 鼓励关心其他人的工作和整体的工作。

在一个团队之间, 交流是最重要的, 实践证明面对面的实时的交流是最有效的, 对交流的延误会损失信息, 白板是最好的交流工具, 交流工具的先进并不能提高交流效果。文档的作用是记录和备忘, 不能通过文档交流。

2.3 敏捷开发方法要避免的过程设计的几个常见错误

(1) 对所有的项目使用同一种过程; (2) 没有弹性; (3) 过于沉重; (4) 增加不必要的“必须完成” (“should do”is really should?) ; (5) 没有经过实践检验。

摘要：敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。它采用项目拆分的手段, 从旧的“瀑布式”开发转变为“并列式”开发, 形成了“敏捷开发”所倡导的精干而灵活的开发方式, 并将开发阶段分成若干周期, 进行“冲刺”, 从而有效提高软件工程项目团队的工作效率, 提高了交付产品的质量。敏捷开发能使项目团队在更快地获取投资回报的同时, 构建出更高质量的系统, 从而在软件开发过程中有着较高的应用价值。

关键词：敏捷开发,拆分,并列,企业架构,敏捷方法