技术开发 频道

Agile+Jazz,真的提高开发效率了吗?

【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,一定会提高整个团队的开发效率。

0
相关文章