背景
在2017年时公司决定对一项经过市场可行性验证的业务进行重新定位，以重构软件产品功能从而可支撑公司未来3-5年的资本定位。
围绕着这规划，公司将我调派为此业务的研发负责人，新团队可从现有团队中挑选或重新招聘。
目标
且谈只谈对于产研团队而言的目标是：
第一个目标：在4个月内交付出可进行试运营的软件产品成果。
第二个目标：在试运营两个月后可正式面向市场推广使用。
面临的挑战
1、需求的不确定性大虽然业务已初步市场验证，但只是证明市场存在商业机会，而商业机会周期和真正规模有多大并不完全掌握。 在接受公司任命时，对4个月内交付出的产品成果还未有详细定义。
2、原有开发模式存在滞后性面对需求的不确定性，技术是确定性的情况下，按照原来的开发模式是否满足以上两点的目标要求。 原有开发模式，可认为是小型瀑布的开发模式，开发人员会等待详细需求说明文档后再进入评估和开发……。
3、团队成员配合程度未知虽然是新团队成员可从现团队中挑选，避免了完全陌生的情况。但原来每个团队的开发方式存在一定的差异性，如何将所有团队成员短时间调整到最高效的状态，也是面临的其中一个挑战。
什么是敏捷？
敏捷是一个术语，用于描述软件开发方法，强调增量交付、团队协作、持续规划和持续学习。 敏捷术语是在 2001年在敏捷宣言中创造的，宣言开始建立原则，指导更好的软件开发方法。
无论在网上、书籍或与专业人士沟通时，讨论对敏捷进行明确的定义，感觉都不够具体和直观。 我认为当无法以更为简单的文字描述一个词语时，更应该看当时产生此词语的背景，则是敏捷宣言和敏捷十二大原则。
敏捷宣言
- 个体和交互胜过过程和工具。
- 可以工作的软件胜过面面俱到的文档。
- 客户合作胜过合同谈判。
- 响应变化胜过遵循计划。
- 虽然右项有价值，但我们更重视左项。
敏捷的原则
- 我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。
- 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
- 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
- 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
- 以简洁为本，它是极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自自组织团队。
- 团队定期地反思如何能提高成效，并依此调整自身的行为表现。
什么是Scrum?
Scrum 是团队用来管理其工作的框架。 Scrum 将敏捷原则作为一组具体的项目、做法和角色来实现。
Scrum 生命周期
整个生命周期在称为冲刺的固定时间段内完成，冲刺通常长达 2-4 周。
Scrum “三三五五”
- 3 个角色（产品负责人、团队、Scrum Master）
- 3 个工件（产品待办事项列表、迭代待办事项列表、产品增量）
- 5 个会议（迭代计划会议、每日站会、迭代回顾会议、迭代评审会议、产品 Backlog 梳理会议）
- 5 个价值（承诺 、专注、开放、尊重、勇气）
敏捷 · Scrum · 看板 · XP 等的关系是是什么？
建立敏捷联盟的 17 位大师就创立了一些敏捷方法，这包括极限编程、Scrum、特征驱动开发、动态系统开发方法、自适应软件开发，以及水晶方法等等，这些方法被统称为敏捷方法。
指的是符合《敏捷宣言》价值观和原则的任何方法、技术、框架、手段或实践。它们都是精益思想的具体实例，都反映了诸如以下概念：“关注价值”、“小批量”和“消除浪费”。
关于实际中参考哪种敏捷方法去推行，则需要根据团队、业务、公司等等实际情况去分析，比如：Scrum在新软件开发中更适合，而看板在维护类软件开发中更适合。
敏捷项目管理0-1实践
在整个团队中包括我而言，在当时对敏捷管理都还没达到专家级别，通过书籍和周边朋友交流经验迁移到我们的软件开发流程中。
也发现敏捷管理在其他公司实际落地中，因为各种各式的原因，Scrum敏捷方法推进起来存在巨大阻碍或"变形"。
排除其他考虑因素，当时决定无论我们是否能达到敏捷成熟最高等级，只要认为Scrum敏捷方法能给我们项目开发带来收获，在这个过程中持续改进，则敏捷项目管理在我们团队中推行就是成功的。
在敏捷项目管理从0-1过程中，我主要在六个重点方面进行思考：
一、敏捷团队
产品负责人
围绕着谁担任产品负责人经过多轮激烈的讨论，就简单是从现有团队抽调一名经验资深产品经理担任新项目产品负责人。但这样存在一个风险点，此产品经理在前期也存在战略及产品模糊的情况，这样并不能满足团队围绕着需求快速沟通开展研发工作。
最终我们决定在前期(3个月内)由发起人直接担任产品负责人，要求其需频繁参与产品需求的沟通，在此期间有两位产品经理协助输出原型图等关键产品设计成果，并为其3个月后担任产品负责人腾出过渡周期。
团队
针对于团队所有的成员培训主要集中两方面：
- 敏捷 和 Scrum 基本知识理论相关的培训。
- 读书分享会，每个虚拟小组根据章节进行每次不超过15分钟的分享。
Scrum Master
主要由我进行担任，除个日常团队管理及技术方案实现以外，Scrum Master最为重要的还是：
- 保证团队资源合理利用。
- 保证各个角色及职责良好协作。
- 解决团队开发中的障碍。
- 作为团队和团队外部的接口，协调解决沟通中的问题。
- 保证开发过程按计划进行，组织 Scrum Planning Meetings（Sprint 计划会议）, Daily Stand-up Meeting（每日站会）, Sprint Review Meeting（Sprint 评审会）和 Sprint Retrospective Meeting（Sprint 回顾会）。
- 保护团队不受外来无端事件影响。
二、项目管理规则
敏捷管理并不等于无管理，在敏捷中因无明确规定需要详细怎么做，恰恰需要团队在一开始之前就定下规则，相关规则可能在开始不完善，但这并不重要，重要的是团队认可且保持持续改进。
我们项目管理规则案例为：需求必须100%按照用户故事模板方式录入、所有对软件系统的更改都转换为需求包括技术人员所做技术优化的技术需求、交付给测试成员时所有开发人员必须保证功能是基本可用的状态、所有严重级别以上Bug的处理人必须当天对Bug进行反馈进展、任何会议不得迟到如有特殊情况必须提前说明……
三、产品需求范围
需求是敏捷项目管理最为重要一环，必须将大需求拆解成一个个小需求，评价标准则：一个需求是可以独立交付测试，开发周期大概不超过3天。 除个拆解需求外，产品还需要确定大方向，不拖研发节奏：
- 项目战略性里程碑计划。
- 项目高层级别需求范围。
- 最近 2 个迭代要开发的用户故事。
四、软件架构
软件架构需遵守：合适原则、演化原则、简单原则。
我们不能一开始就以造航母的方式去准备基础性工作，但实际上是在做小船。但也要避免一年后要将现有软件架构全部推倒从来的情况，这对原有开发人员的打击较大和公司成本损失也不小。
对于如何做好演化级别的软件架构，又一篇工作量不小的经验总结，但有一些方向性可去思考：专家经验、标杆参考、分而治之、多标准决策、主题会议等等。
为了应对此项目未来2-3年的规划，我们做了容量规划和结合团队情况，软件架构采用前后端分离：
- 前端使用Vue + 混合式轻APP方式
- 后端使用Spring Cloud生态，微服务在前期只区分核心服务、非核心服务、支撑基础服务，但代码上需确保解耦性，可快速对服务进行拆分。
对架构图，我们只设计且保持更新是三种设计图：逻辑架构图、物理架构图、核心业务流程图。
五、敏捷工具
“工欲善其事，必先利其器”，这个在于团队协作中也是极为重要。从大的方面软件协作平台到小的方面文档共享，都需要找到最适合团队协作的方式。
每个工具各有优缺点，多去了解不同产品的特点，打开自己视野，但不变的核心是：寻求自动化、情景闭环。
六、办公环境
在确定项目成员后，第一时间向公司申请集中区域给予团队进行办公。
因前期项目团队成员不多，办公区域中间就有大屏显示器、随手画板、项目管理规则等，也充当会议室，大屏显示器没有会议时则固定展示故事墙。
总结
以开放心态接受新事务，那怕它可能颠覆团队现有的工作方式，只要相信对项目开发带来收获，那么就坚持去做，只要在此过程不断PDCA，那么结果一定会变好。
我们所处在一个易变(Volatility)、不确定(Uncertainty)、复杂(Complexity)和模糊(Ambiguity)的世界，敏捷快速响应变化、允许试错、小步快跑的特点是很能应对时代变化的。
在使用什么工具管理项目