你知道敏捷开发实践中常见的误区吗？

随着市场的快速变化和软件行业的快速发展，传统的瀑布式软件开发模式由于开发和反馈周期长，在抓住市场机会和快速满足用户需求方面逐渐失去了竞争优势。同时，敏捷开发因其快速迭代和不断满足用户不断变化的需求而受到越来越多的关注。

尽管敏捷开发更适合现代和快速变化的软件开发行业，但真正实现敏捷思想并不容易。在敏捷开发实践中有许多常见的误区需要注意：

协作意味着更多的会议

会议，会议，会议！对于程序员来说，最烦人的事情是会议，敏捷开发会议太多了：日常例会、每次迭代开始前的需求讨论会、迭代开始时的规划会议、迭代结束时的验收会议、审查会议和无数小型会议。通常，迭代持续两周、十个工作日和 80 个小时。这些会议需要 20 多个小时。程序员怎么还能有时间写代码呢。更令人恼火的是，代码写到一半被叫去开会，一下午都没有效率可言了。

每个人都有这样的感觉，归根结底，他们没有改变自己的想法。敏捷思维是一种深刻的文化变革。真正的敏捷性需要团队成员和客户之间的及时沟通和密切合作。盲目地低着头写代码，然后你发现你所做的功能不是客户想要的；或者在编写了很长时间的前端代码后，发现后台的 API 发生了变化，无法使用原始参数；或者在调查了很长时间的 bug 后，才知道第二天整个功能都被删除了；你忍不住在心里怒吼：为什么不早点告诉我？敏捷是通过及时和频繁的沟通快速响应变化，最大限度地减少损失和风险。

一个完整的跨职能团队意味着许多人

理论上，一个完整的敏捷跨职能团队应该拥有完成业务目标的所有专业角色，包括产品经理、前端开发人员、后端开发人员、设计师、测试人员等。所有的团队不可避免地会组成一个庞大的团队。如此庞大的团队在一起时每分钟都会烧钱。

然而，尽管敏捷开发需要完整的角色，但在规模上应该严格控制。 Scrum 建议团队规模为 5-9 人。这样做的目的是：当需要做出任何决定时，团队可以直接做出决定，而无需征求领导或正式会议的指示。在办公桌旁找一块空地，或者在讨论时围着白板做笔记。决策可以在不超过 30 分钟的时间内做出，这既简单又高效，团队中的每个人都可以参与。

亚马逊著名的两个披萨原则相当于两个披萨能够吃饱的一个团队规模。简而言之，这是一个由大约十个人组成的团队。只有在这样一个小团队中，成员才是最有活力的，摩擦最小，沟通成本最低。这样的团队具有独立和独立的能力，因此最能产生创新。

项目经理应该发挥主导作用

正如第 2 条所述，一个完整的敏捷跨职能团队需要完整的角色，但专业角色的数量是严格控制的。所谓“一个萝卜，一个坑”，有时甚至一个人负责多个角色（如全栈开发者）。每个人都应该对自己的专业领域负责。这是一个没有层次结构的横向组织结构。程序员不仅要写好代码，还要与团队成员沟通——分析和理解需求，讨论解决方案，做好前端和后端以及其他接口，与测试人员一起分析和解决错误，向客户演示和解释产品的使用，等等。

项目经理在团队中的角色应该是协调和协助，而不是上级对下级的领导。一个好的项目经理应该鼓励程序员进行更多的沟通，而不是成为他们的发言人，更不用说给出指示了。即使对方是客户或设计师，程序员也应该直接与他们面对面交流。项目经理需要做的是帮助他们联系相关人员或安排会议（更像是助理的角色）；或者帮助他们在遇到困难时获得更多关注。

来源：快推 365 网站