敏捷宣言12条原则的一次小实践

近日，领导给安排了指导某项目的需求分析工作，该项目面临时间紧、任务重、人员少的窘境。需求分析只有4人，几个复杂模块都压在1个经验丰富的老手身上，其他3人经验不足。目前最严峻问题是，团队产能不足、效率低下，项目需求分析很可能要延期的风险。

考虑到有2个重点复杂模块的需求分析仍未开始，今天组织了次小组会议，调整了下内部工作流程。将原来按照“原型->需规->客户确认”一个接一个模块串行推进的次序，改为将多个模块先做原型，需规再统一最后写的串行顺序来做。这样的好处是，尽快开工搭出架子，避免串行工作导致后续时间仓促来不及。

对照了下敏捷宣言12条原则，今天至少做到了其中5条，一个小小的改变，也许会改变目前的困境！

1、我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。

对策：小组会上，跟组员重申了当前形势下，尽快将多个模块需求分析并行推进的必要性。

2、欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。

3、要不断交付可用的软件，周期从几周到几个月不等，且越短越好。

4、项目过程中，业务人员与开发人员必须在一起工作。

5、要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。

对策：核心骨干反映每天上下班通勤要4小时，项目负责人特批允许近期他在家办公。

6、无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。

对策：疫情期间，电话会不直接，直接进会议室面对面谈，确实沟通效率高。

7、可用的软件是衡量进度的主要指标。

8、敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

对策：针对用户方分部门分不同岗位各自提需求，每人只负责自己一摊缺乏整体业务梳理，为避免需求设计被随意推翻，要求启动一个模块的分析前，要拉上用户端涉及到部门的所有相关人员参会，以便于后期的功能点统一确认，减少返工

9、对技术的精益求精以及对设计的不断完善将提升敏捷性。

10、要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。

11、最佳的架构、需求和设计出自于自组织的团队。

12、团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

对策：约定每周召开两次小组会议，汇报进展和问题讨论。