【IT168 专稿】

    从Agile方法论的诞生，到IBM Jazz的大力推广，一切都在貌似按部就班的以一种科学的开发方式来生产我们的软件，一切都看起来那么美丽而高效。作为一个普通的Developer，暂且还没有纵观全局的能力，只能就自己所担当的角色对Agile+Jazz发表只言片语，权当是自己一点经验积累，只代表个人看法，文笔晦涩，还望见谅！

    Agile自始至终就致力于如何高效的开发咱们的软件，它的宣言也是简单易懂：1.着力于加强一个开发团队中个人和个人之间的交互；2.着力于加强软件开发过程中所有参与者（开发工程师、测试工程师、文档工程师、销售工程师）的讨论；3.勇于接受变化。

    而对应于Agile的宣言，IBM Jazz的口号也相映成辉：团队协作平台，无缝整合工作！

    单看以上的宣言和口号，在我这个层次的人看来更多的是虚无缥缈的东西吧，任何理论都要经过实践的验证！

    团队从这个版本开始，尝试使用Jazz，经历了一个季度的开发，几个迭代周期的调整，自我感觉是有利有弊。有利方面通过以上口号和宣言中就能体现出来，在此不多叙述。弊端还是要说说的，可能看法比较片面，请勿较真！

    1.Agile是方法论，Jazz是对这种方法论的实现，而应用于实践就是如何运用这套工具。而在我们的开发中，更多的是去学习工具，添加UC、Work Item、更改状态等等，过于繁琐的操作，过于眼花缭乱的状态信息。

    例：每个参与者需要一定周期去学习工具的使用。

    2.团队之间的交互并没有实质性的变化，频繁的电话会议还是充满整个日历列表。

    例：电话会议的时间浪费了更多思考需求的时间，也许这并不是Scrum的初衷。

    3.各种参与者之间的互动更多的是形式化，开发、测试、文档、Reviewer、Approver更多的是通过工具更改状态信息，而不是其本质的内容。

    例：并没有通过更多的交互来提高产品质量。

    4.过于恪守工具所定义的状态，随之而来的就是不敢接受变化。

    例：Agile所尊崇的是敢于变化，它允许出现异常，而不是去死板的定义迭代周期，而不是死板的认为所有的一切都必须在Dcut之前完成；

    总而言之，相对于Wiki，Jazz确实让用户更方便地去浏览，提交信息。但是在目前的开发模式中，我们所用到的也许只是其表面的东西——一个人性化的IDE，相对于Eclipse而言。

    方法论是理想的，工具却不是功能较多的，而目前我们更倚重的是工具的便利，更多的是死板套用理论的条条框框，更多的是在电话中讨论要做什么，做了什么，而不是讨论应该怎么做。

    但是，没有工具也是万万不能的，所以我相信，在不久的将来，科学的利用Jazz,一定会提高整个团队的开发效率。