敏捷开发不是管理者的万能药
1. 引言 #
在今天的数字化浪潮中，软件不仅仅是一种工具，而是企业血脉的重要组成部分。不管是作为核心产品出售还是用来提高内部效率，软件无处不在。正如一份 麦肯锡的报告 所指出，“每个公司都是软件公司”，这强调了软件在商业成功中的核心作用和数字化转型的重要性。然而，许多企业虽然迅速跳上了数字化的快车，却发现道路并非想象中那么平坦。软件研发领域的技术管理人员面临的困境颇多：
- 精心设计好的产品在交付给用户的时候甚至无法解决用户的核心痛点和满足用户的核心诉求，甚至导致产品功能无法交付研发失败
- 精心安排的产品开发计划，总是收到各种需求变化，从而打乱开发节奏，使得团队疲于奔命，甚至导致大幅延期
- 精心挑选的项目参与人员积极性不高，配合不畅，沟通成本高，甚至导致士气低落，在跨职能团队协作开发时表现尤为明显
而敏捷开发和数字化几乎是成对出现的，随着“敏捷”这个词在互联网上经过多年的发酵以及各类咨询和布道者的不懈推广，技术管理者似乎找到了指引他们走出困境的方法和解决问题的万能药，在一知半解下，被“敏捷”这个词深深的吸引，纷纷带领团队将任务管理切换到了JIRA，把项目计划按照一、两周进行小周期排期，每天组织站会，并满怀期待的希望的认为之前遇到的问题都将会迎刃而解，他们也随之走出泥潭，在几个月过后，他们发现似乎项目还是像往常一样延期，团队还是在疲于奔命，用户的抱怨也并有多少改观，他们回过头来说“敏捷就是狗屎，一点用都没有”。慢慢的在互联网上对敏捷似乎越来越多的出现了两极分化的观点，狂热者不停地讲述着敏捷如何如何解决企业和团队的困境，而怀疑者则持续说着各种各样敏捷失败的故事。这让我们不由的思考“敏捷开发到底有没有用？”
2. 敏捷开发的最大误区 #
敏捷开发的本质常被误解，许多技术管理人员视其为仅仅一套流程或工具集。在互联网上，对敏捷的讨论往往围绕着与传统瀑布模型的对比展开，多数文章从Scrum开发模式切入，详述如产品负责人（PO）、Scrum Master、开发者等角色，以及如何利用需求管理工具和任务追踪工具来处理用户故事、产品待办列表（Backlog）、冲刺（Sprint）等概念。这些文章或教程，尽管出发点良好，试图以最流行的Scrum方法为例，将敏捷开发描述为一套标准化的角色、活动和流程，告诉读者只需遵循这些规范就能顺利实施敏捷开发。 然而，这种方式在推广敏捷的同时，也误导了很多技术管理人员。他们开始认为敏捷开发仅仅是一种开发流程，仿佛一套模式套用下来就能够解决所有问题。这种对敏捷本质的误解是许多敏捷实施失败的根源之一。敏捷不仅是流程的改变，更是思维方式和组织文化的转变，它要求团队不断适应变化，快速响应，以及高度的团队协作和自我管理能力。
技术管理者对敏捷开发的误解往往是推广敏捷失败的一大障碍。其核心职责应是结合企业目标，引领团队以最适宜的方式协同工作。然而，一些管理者不深入分析具体的企业状况和组织需求，而是机械地将某些开发模式硬套在组织结构上，这种做法显然是不理智的。若想通过敏捷开发解决前文提到的管理困境，管理者需要：
- 深刻理解敏捷的本质：敏捷不仅是一种工具或方法论，更是一种思维方式和文化。理解这一点，能帮助管理者更好地评估敏捷开发是否适合自己的团队和项目。
- 评估敏捷的适用性：管理者应评估敏捷开发是否能解决当前企业和组织面临的问题。这需要对组织的运营模式、团队结构、项目类型等有深入的了解。
- 组织必要的调整：如果确定敏捷开发符合组织需求，接下来需要考虑的是组织需要进行哪些调整以成功落地敏捷。这可能包括改变团队配置、调整工作流程、培训员工理解和接受敏捷思维，甚至可能涉及更广泛的企业文化改革。 通过这些步骤，管理者不仅能避免盲目跟风敏捷的陷阱，还能确保敏捷开发在组织中的正确实施和有效运作。这样的方法更有助于敏捷开发真正成为解决问题的有效工具，而不仅仅是一个流行的概念。
3. 敏捷开发的本质 #
敏捷开发是一种积极拥抱变化，构建具有用户思维和组织内在活力的开发文化
作为敏捷宣言制定者之一的Martin Fowler在他的博客中曾经指出"Agile is people-oriented rather than process-oriented"，这一观点跟我们前边提到敏捷开发最大误区，即敏捷开发是一种流程的理解是截然相反的，Martin强调的是敏捷开发是一种以人为本的工程思维，它跟流程导向的开发模式有本质的不同。同时他还在文章中着重比较了以人为本和流程导向的开发模式的差异，比如流程导向的开发更注重计划性和可预测性，这种开发模式相对僵化、害怕变化，而敏捷开发则更注重人员活动和交付的价值，这种开发模式主动拥抱变化、管理变化。
我更倾向于敏捷开发是一种文化，而像Scrum这些流程模式是对这种文化的承载和最佳实践，他们有参考意义，但是作为管理者需要看到敏捷开发的本质，让我们一起回过头来看看敏捷宣言
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观： 个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 响应变化 高于 遵循计划 也就是说，尽管右项有其价值，我们更重视左项的价值。
正如敏捷宣言所阐述的，敏捷开发不是简单地摒弃传统方法，而是一种重新定义的价值观。宣言中明确地提到，尽管右侧的事项（如过程和工具、详尽的文档、合同谈判、计划遵循）依然有其价值，但我们更应该关注左侧的事项（个体和互动、工作软件、客户合作、响应变化）。这种重视并不是完全抛弃右侧的实践，而是强调在面对变化时左侧的事项更为关键。 许多网络论调如“敏捷就是追求速度”、“敏捷不需要文档”或“敏捷没有计划”等，都是对敏捷宣言的误读和片面解释。敏捷开发实际上是鼓励在必要时创造有价值的文档，制定灵活的计划，并且通过高效的团队协作来提高开发速度和质量。
接下来，让我们详细分析敏捷宣言中的每一条，深入理解其背后的价值观，这将为管理者提供清晰的管理方向：
3.1 个体和互动高于流程和工具 #
本质上是在提醒我们，虽然有成熟的工具和详尽的流程可以支持软件开发的各个阶段，但这些都不应该成为我们关注的重点。关键在于团队成员之间的有效沟通和互动。成功的软件开发依赖于团队成员能够如何有效合作，进行需求澄清、任务排期、开发交流、测试验收、以及最终的产品交付等。 有效的团队互动促进了信息的充分交换，这是确保工作以高效和高质量完成的关键。管理者在这里扮演的角色是促进者和支持者，而非仅仅是流程的执行者。他们应该利用工具和流程作为辅助手段，来支持团队的自组织和自我管理能力，而不是作为固定不变的规则来限制团队的创造力和灵活性。 在实践中，这意味着管理者需要更多地关注如何去除团队沟通中的障碍，提高团队成员之间的交流效率，以及如何建立一个开放和包容的团队文化，使得每位团队成员都能在相互尊重和信任的环境中自由地表达自己的想法和意见。 因此，构建团队的策略应更侧重于人和他们之间的互动，而不仅仅是遵守预设的流程和使用工具。这种以人为本的管理方法更符合敏捷开发的精神，也是确保敏捷实践成功的关键。
3.2 工作的软件高于详尽的文档 #
在软件开发过程中，交付一个可运行、能够为用户带来价值的产品远比拥有完备的文档更为重要。这并不意味着文档本身无关紧要，而是要求我们在文档编制上应当追求实效性和必要性，避免文档工作变成过度繁琐且偏离了项目核心目标的活动。 这一原则强调的是优先级的问题：当文档能够显著提高软件的可用性、便于维护或帮助新团队成员更快地上手时，它就是必需的。例如，用户手册可以帮助用户更有效地使用软件，关键算法的注释可以帮助维护团队理解和迭代产品，这些都是对项目有直接益处的文档。 因此，敏捷开发并不是反对制作文档，而是反对无目的的、形式化的文档积累。我们应该根据文档对于项目成功的实际贡献来决定其编写的深度和广度。这样的处理方式既保证了文档的实用性，又避免了资源的浪费。 总结来说，我们应将重点放在如何通过工作的软件来实现价值交付，同时在确保项目的可持续发展和团队的有效协作方面，合理地利用文档的支持作用。通过这种方式，可以确保敏捷开发的实践更加贴近其核心价值，即创造对用户真正有用的产品。
3.3 客户合作高于合同谈判 #
这一原则核心在于提倡一种基于合作的关系，而非仅仅是基于合同的交易关系。这种思维转变是敏捷开发中非常关键的一环，它强调了与客户的持续互动和合作的重要性。在这种模式下，开发团队和客户不再是对立的，而是成为合作伙伴，共同致力于创造最大的项目价值。 通过这种合作关系，团队可以更直接、更实时地了解客户的需求和期望，甚至帮助客户发现他们未曾意识到的需求。这种深入的合作使得产品更能贴合用户的实际需求，例如，通过定期的迭代反馈会议、共同参与产品设计思考会等活动，可以有效地将客户的即时反馈转化为产品改进的动力。 此外，这种密切的合作关系还有助于建立信任和理解，减少因误解或沟通不充分导致的需求偏差。它促使团队在整个开发过程中保持灵活性，能够适应需求变化和市场动态，从而更有效地服务于客户。 因此，将客户视为合作伙伴，而非单纯的需求方，可以大大提高软件产品的相关性和价值，同时也增强了项目的适应性和创新性。通过这种方式，敏捷开发确实能够为客户提供更高质量和更具个性化的解决方案。
3.4 响应变化高于遵循计划 #
强调了在面对快速变化的软件开发环境中，灵活和适应性的重要性。现代软件产品通常功能复杂且需求多变，客户在项目初期往往难以完全明确他们的所有需求，甚至他们的需求会在开发过程中发生变化。这就要求开发团队不仅要接受变化的现实，更要积极拥抱这种变化。 管理者和团队应该建立一种文化，在这个文化中变更被视为是正常的。这种文化鼓励团队成员保持开放的心态，随时准备调整方向，以适应新的或变化的需求。通过采用迭代的开发方法，团队可以经常性地展示进展，收集反馈，并根据这些反馈快速调整产品方向。这不仅有助于更好地满足客户需求，也提高了团队应对未知和不确定性的能力。 此外，管理者的角色也应转变为一个更加动态的领导者，他们的任务不再是严格执行计划，而是引导团队通过不断学习和适应来优化工作方式。这种领导方式更强调视野的广度和对变化的快速反应能力。 因此，拥抱变化并积极响应变化不仅是一种策略，也是敏捷方法论中核心的哲学思想。这种思想认识到，在不断变化的市场和技术环境中，持续适应和改进是成功的关键。通过这种方式，团队能够持续创造出最符合市场和客户当前需求的产品。
4. 对管理者的几点建议 #
正如前文所述，敏捷开发的真正本质在于积极拥抱变化，并构建一个充满用户思维和组织活力的开发文化。在团队中推广敏捷开发，其核心就是建立这种敏捷文化。我们当然不能只停留在讲述文化的层面，还需要通过具体的方法将团队成员团结起来，并用流程来指导大家协同工作。 管理者必须认识到，真正的挑战在于如何把握行业的最佳实践，同时时刻牢记我们的终极目标是构建一个敏捷文化。这意味着我们需要在实施敏捷的具体技术和工具时，始终保持对文化建设的关注。这种文化是支撑敏捷实践持续成功的基础，它鼓励团队成员不断地学习、适应变化，并且在面对挑战时能够灵活应对。这样，敏捷开发才能真正地在组织中落地并发挥其应有的效力。
4.1 耐心和氛围 #
管理者在尝试建立敏捷团队的初期通常都是会选取一个特定的敏捷流程最佳实践，以最为流行的Scrum为例（参考Scrum官方说明 ），管理者会在团队内以PO，Scrum Master, Developer等等角色调整团队结构，因为很多团队没有办法转为敏捷招聘额外的人员，因此从当前人员中进行培养，管理者需要意识到不同的角色需要掌握一些额外的技能，如PO需要能够很好的撰写用户故事和管理优先级，Scrum Master需要是团队中对敏捷认知最深的人等等，总而言之，他们必须意识到敏捷开发对团队成员的综合能力要求相较传统的方式是要更加高的，他们需要能够准确识别到团队成员的擅长和不擅长的地方（通常可以使用SWOT方法进行分析），并想办法改善和补足。
管理者需要有意识的构建敏捷开发的氛围，另外他们还需要具有足够多的耐心，愿意同团队一起成长并帮助团队成员构建敏捷开发所需要的思维和能力：
- 用户思维：团队成员都能站在用户角度思考问题，理解自己所做的每一个方案、每一个功能都将最终能够产生用户价值，如前文所说，软件的唯一价值是被用户使用，因此理解用户痛点和需求，而避免陷入闭门造车敏捷开发中对团队的整体要求
- 开放和信任：团队成员都能站在团队角度思考问题，理解团队是一个整体，任何的困难都可以通过互相协作和帮助解决，比如Sprint计划中，有一种任务分工方法是让团队成员自己去挑选自己想去完成的任务而不是通过分配，这种方法有助于培养任务开发者对任务的Owner意识，将潜在的让开发者更投入，但是这也有一个问题，如果在一个缺乏相互信任的团队中，团队成员可能会倾向于选择简单容易完成的任务，但是如果团队成员之间互相足够开发了解并充满信任，一个初级工程师可能就会主动承担一个相对复杂的任务，因为他知道自己不是一个人在战斗，当他自己搞不定的时候，团队的其他成员总会伸出援助之手，在不担心任务无法返程的同时，反而他能够得到更快的成长
- 敏捷认同感：团队成员需要认同敏捷开发，当下在许多企业，开发者下意识的抵制敏捷开发，他们认为敏捷开发就是噱头是额外的工作量和无意义的会议、是管理者的一时脑热、是管理者压榨员工的一种手段（无视排期，希望每周都有交付），诚然这里边有很大一部分原因是管理者本身就没有对敏捷形成良好的认知，导致他们机械式的模仿和不切实际的预期，但这恰恰说明敏捷文化是需要包括管理者在内的团体成员认同的
4.2 目标感和用户故事 #
一个健康的敏捷团队最主要的特点就是团队是自组织的，自组织的团队有一个显著的特点就是他们有一个统一的目标，因此培养团队的目标感非常重要，培养目标感的方法有很多，例如
- 为敏捷团队起一个特别的名字，这个名字可以是由团队成员共同起的，要尽可能有趣，我所见过的如：Rockstars、Flash、Speedy等等
- 所有团队成员一起为制定团队的一些规则，比如定义做到什么程度Sprint就算成功、成功以后可以怎么样庆祝，再比如任务工作量评估方法等等
- 为敏捷团队负责的工作定义一个统一描述说明，形成一定的产品概念，所有的需求都将站在这个产品给用户带来价值的角度撰写用户故事
好的用户故事是健康运营敏捷团队的重中之重，这是需要引起管理者特别重视的，虽然说敏捷团队是自组织的，但是团队需要做什么事情，需要以什么样的优先级做一件事件，某个迭代中需要完成什么样的工作，这都来自于用户需求，而用户故事就是精准表达用户需求的方式，我们可以不夸张的说，团队是靠用户故事驱动运转的，没有用户故事团队将无事可做，不好的用户故事则让团队交付的价值大打折扣。
4.3 教条主义和吐槽大会 #
构建敏捷开发文化是一项重实践的管理活动，最应该避免的就是教条主义，许多的管理者将团队内的角色、流程、工具都构建起来以后就认为敏捷团队就搭建完毕了，他们没有重视过程管理，忽视了收集反馈并根据实际运营情况及时做出调整，这也是使得很多企业风风火火的开展敏捷运动却最终只能黯淡收场。 我推荐管理者定期组织吐槽大会，让所有敏捷团队的成员参与其中，进行面对面的吐槽，在这个会议上不要有级别、角色的预设，鼓励每位成员发自内心的讲出他对这个敏捷团队运营的感受，说出自己觉得运营的成功和不成功的地方，说出自己的期望，收集到每一位成员的吐槽以后，我们还可以安排成员对问题进行投票，管理者需要引导将关键问题和敏捷文化进行关联，确保团队向着敏捷文化方向发展，然后每个周期我们选择投票最高的若干问题进行重点解决，经过不停地吐槽和问题解决迭代，团队就会逐渐发展成为管理者和团队成员共同希望它成为的样子，只有这样的团队才能实现真正的自组织和形成内部活力。