如何成为一个出色的敏捷开发者?

没有人希望自己交付出去的软件充斥着大量的漏洞和性能问题，而且还没能让客户满意。持续集成和代码审阅可以防止这种情况的发生，但问题是谁有时间干这些事，对吧？今天，敏捷团队就能挤出时间。

敏捷开发者关注的是项目的可持续性发展——而不是个人英雄主义。可持续性关乎项目周期的估计是否准确，代码管理分支策略的有效性，自动化测试对代码质量的保证以及能快速获得用户反馈的持续部署。践行可持续开发需要大家都认可的规范，但实际上，当大家各自为政时就很难达成共识。因为没人能凭空搞敏捷开发，它一定需要整个团队文化作为后盾。这就意味着得让项目负责人明白质量可远比范围和进度重要，这通常就是践行敏捷开发最麻烦的地方。

「CODING 企业版」作为企业级软件研发管理系统，助力团队敏捷开发转型升级。

不过这么做是值得的。开发人员可以因此获得解脱，从而开发出更可靠的软件，还能一直保持与业务的密切联系。而业务层面则可以向市场推出更高质量的产品，进一步增强业务与开发之间的联系。另外（这是敏捷开发最好的地方），敏捷开发者很少会面临“死亡之旅”（译者注：这是个软件工程领域的玩笑，指项目要交付的最后几个月大家拼死拼活加班赶项目）。我们有时为了保持项目的高质量而付出了比预期更多的努力，导致开发落后于预期进度，这种情况下项目管理铁三角的“实现范围”部分可以适当改变，这样大家都能轻松些。

所有软件开发人员都了解项目管理的“铁三角”即：范围，进度和质量。我们大多数人都参与过那种实现范围死板，进度混乱并且工作量因技术债不断增加而不堪重负的项目。还有比这更糟糕的，有时最终交付的产品根本不是市场所需要的。这些事想想就让人深受打击。

别担心：这有个好消息。

在敏捷开发中，实现范围是可以动态变化的，这可以使团队保证开发质量并营造出充满活力的氛围，同时还能兼顾与业务层面的密切联系。我们有充分的理由认为，敏捷是每一个开发团队（也包括很多非开发团队）的核心。

敏捷不仅仅是一系列套路，它更是一种文化和技术哲学。

它可以使开发者个人在自己的产品中建立坚实的技术基础，并在团队中树立协作文化。敏捷团队的开发者更加乐意于投入工作，编写的代码质量也更高，获得的乐趣也更多。

「CODING 企业版」提供强大又易用的 Code Review 代码审阅功能。

牢靠的团队关系就意味着更好的产品

敏捷是关乎团队合作的，这并不奇怪，因为今天的大多数软件都是由团队开发的。开发人员要与产品管理，设计，质量监控以及运维建立牢固的联系，编写可持续代码即意味着与项目的各个方面保持联系。鼓励开发人员直接和业务层面其他部门合作的公司，在代码质量和开发人员满意度方面获得了显著的成效。比如：代码质量变得更好， “徒劳的努力”变少了（即重复工作或者工作流冲突），以及各部门之间有了更多的交流。

交流意见是很重要的。敏捷团队会进行交叉训练，以确保整个团队都能理解代码的基本理念。这样做的一种常见方式就是代码审阅，它不仅能保证代码质量，还可以使整个团队都熟悉代码。无论以什么方式推广这种理念，敏捷团队不会因为由于只有某些人能理解特定代码导致负责这些关键部分的开发人员没法休息，谁也不想当这样的程序员。

与瀑布模式开发的同行相比，敏捷开发者能够更轻松地在产品技术栈的上下游切换工作，因为敏捷团队可以自我组织，让成员们有更多机会学会新技能。实际上，让开发人员接触从 UI 到数据库的完整特性，可以让他们对代码有更好的掌控。在提倡分享知识的团队或公司，我们更能培养全栈工程师。