关于敏捷开发，你应该避免的几个误区

回顾软件工程发展史，就是管理和技术并行的历史。了解敏捷开发管理，有助于将软件工程的管理与技术相结合，让研发团队发挥更大的战斗力。

近期刚开始管理一百人左右规模的团队，希望能借此机会，将自己的管理心得进行记录和整理，同时也给大家多一份参考，一起提高。

敏捷开发管理背景

1. 康威定律：系统设计受限于组织自身的沟通结构。组织的规模越大，灵活性就越差，这种现象就越明显。

从组织架构的角度上来说，敏捷开发管理需要合适的团队规模，以便发挥最大的战斗力，这个依据来自康威定律。

所以如果将团队以项目组或者产品线的方式划分，从组织架构的角度来说，有利于敏捷管理，可以充分利用产品线的组织架构优势。

2. 解决软件开发“效率、速度”的需要。需要关注敏捷，精益，推崇DevOps、CI/CD等工具和方法。

随着软件技术的不断提升，软件开发除了质量之外，还需要“效率和速度”。

在业务为主导的企业，有时对软件研发速度的要求，甚至会超过对质量的要求。并不是说不需要质量，而是说有些业务的验证需要很快，否则会错失商机，所以需要用最快的速度进行验证。如何平衡速度与质量的关系呢？需要从敏捷、精益等角度进行进行分析，在工具层面，可以使用DevOps、CI/CD进行探索。

所以敏捷开发管理离不开业务对软件研发进度的“逼迫”，敏捷的价值观也印证了这一点，即：认同软件变更，也认为能工作的软件是优先级较高的。此外，适合的工具和方法，也是敏捷成功的要素。

3. “三步工作法”的需要：流动、反馈、学习。

三步工作法出自《DevOps实践指南》，也是我见过的最简洁和最有效的的工作方法之一。

显然，“流动、反馈、学习”与敏捷方法中的价值观是一脉相承的，因为两者均提倡快速推进、快速反馈、快速调整。

上述的一些理论，我认为是选择敏捷开发的前提知识，也是后续在遇到障碍时的参考依据。

敏捷开发管理的理论

由于敏捷开发的理论知识，在网上资料比较多，所以这里就简单罗列一下，为后续作为实践的依据。

敏捷开发是一种以人为核心，迭代，循序渐进的开发方法。

敏捷 = 价值观 + 准则 + 符合价值观和准则的方法
敏捷方法强调以人为本，专注交付对客户有价值的软件。在高度协同的环境中，使用迭代的方式进行增量开发，经常使用反馈进行思考、反省和总结，不断的进行自我调整和完善。

敏捷的价值观：正确理解敏捷的初心。下面的是标准的敏捷价值观：

1. 个体和互动 高于 流程和工具
2. 工作的软件 高于 详尽的文档
3. 客户合作 高于 合同谈判
4. 响应变化 高于 遵循计划
5. 虽然右项有价值，但我们更重视左项

敏捷的准则：正确理解敏捷的基石。下面是标准的敏捷准则：

1. 我们最优先要做的，就是尽快持续交付有价值的软件，让客户满意。
2. 在开发期间，均欢迎需求变更，敏捷过程利用变化来为客户创造竞争优势。
3. 持续交付可以工作的软件，交付的间隔允许自定义（1周到4周），交付周期越短越好。
4. 在项目开发期间，业务人员和开发人员必须在一起工作。
5. 个体需要被激励，并为其提供合适的环境和支持，并相信他们能够完成工作。
6. 在团队内部，尽可能面对面的沟通。
7. 可工作的软件，是首要的进度度量标准。
8. 敏捷过程倡导可持续开发，相关干系人要能够共同维持其步调稳定延续。
9. 敏捷能力的增强，可以通过注入优秀的技能和好的设计来实现。
10. 敏捷的根本就是简单，即：尽量减少不需要的工作，但是并非鼓励去除合适的工作。
11. 最好的构架、需求和设计出自于自组织的团队。
12. 团队定期反思如何提升效率，并依此调整自己的行为。
    凡是符合敏捷价值观和原则的方法论，都可以称为敏捷方法。Scrum、看板、精益开发等，这些方法被统称为敏捷方法。

为了更好的与团队推动项目进度，团队成员必须对“完成”的定义有相同的理解，这样才能保证透明性。如果在每个迭代，我们对“完成”的标准要求过低，那么这会导致在每个迭代，我们都会遗留一些完成外的工作。

敏捷开发在软件生命周期中只占了一部分，所以需要与更多的团队共同探索和实践，才能真正用好敏捷方法。

如何做好敏捷开发管理

先说一下精益开发与SRCUM的区别：

• SRCUM关注的是价值确定的情况下，如何通过小步快跑的迭代方式按节奏交付价值。（快速迭代）
• 精益关注的则是在价值并不确定的情况下，如何用最小成本，快速定位到真正价值点。（减少浪费）

所以，敏捷是允许试错的。敏捷的规模化推广方法可以通过下面的方法进行探索：

1. 选择合适的规模化推广策略：激进式变革？渐进式改革？这两种策略没有优劣之分。
2. 做好敏捷文化铺垫，培养好敏捷的中坚力量：要做好全员敏捷基础培训和核心敏捷人员的能力培养，以便支持更多团队开展敏捷。
3. 搭建适合敏捷的工作环境，做好必要的工具和自动化准备。
4. 组织级别的敏捷度量以及持续改进：做好组织级别的敏捷度量，从效率、质量、成本等方面收集敏捷相关的数据，并借由这些数据辅助企业做持续改进。
5. 重视大型团队的敏捷导入与推广：定制度、建立沟通机制，对齐团队目标。

常见的误区和解析

用了敏捷，我们只负责开发软件就够了，不用做文档，也不用做设计

分析：敏捷并非完全不用写文档，而是不需要无效文档。

敏捷就是快，原来要1年才能完成的项目，用了敏捷后，3个月就可以完成了

分析：敏捷不是加快研发速度，而是加快反馈，加快最优业务价值功能的快速实现。

用了敏捷后，由于在迭代开始时在约定时间完成交付，所以我们比原来加班更严重了

分析：敏捷离不开科学的基础原则和方法论，对工时的估算也需要不断优化，敏捷是不提倡持续加班的。

开始敏捷管理后，自组织团队想干什么就干什么

分析：管理层决定团队目标，团队决定如何实现目标。

团队没有真正理解到底什么是敏捷，所以不知道敏捷能给他们带来什么切实有效的帮助

分析：
1、不了解和分析现状就直接推进敏捷是非常不靠谱的，必须看清现实，摸清项目的痛点，在解决痛点的基础上导入并推进敏捷才是可行的。

2、需要让团队共同分担工作压力，并让能力强者放下心中芥蒂，让更多的新手参与核心工作。

把一个大项目分成若干个阶段（需求、设计、研发、测试），仿照“敏捷”的做法，每四个迭代做一个阶段（需求、设计、研发、测试）

分析：
1、小瀑布依旧是瀑布。
2、应该先把客户的需求拿来看一下，挑选好并先从有价值的、优先级最高的需求开始做。
3、做需求拆分的目的，都是把大需求拆成一个个能够独立开发测试的完整小需求。

业务部门的需求太多而且每个都非常紧急，怎么处理？

分析：
1、从业务部门拉一个人对需求按价值进行排序；
2、需求收集理性化，主动收集，需求有一定的清晰度；
3、回顾哪些需求不重要，是否可以排后。

敏捷开发过程管理总结

在本文的最后，请您跟我一起思考以下如下几个问题的答案。

• 为什么需要做敏捷？
• 敏捷=价值观+准则+合适的实践方法，价值观和准则有哪些？
• “完成”的定义如何定义？
• SRCUM与精益开发的区别是什么？

如果不能马上回答上述问题，可以把上面的文字再复习一遍。