建议先阅：https://blog.csdn.net/Su_Levi_Wei/article/details/89313778
建议先阅：https://blog.csdn.net/Su_Levi_Wei/article/details/94206222
无数疑问
在互联网行业中，我们常常会听到敏捷开发这个词，但敏捷开发是什么，我们是否真的需要敏捷开发这个东西？即便真的需要敏捷开发这东西，要怎么去用好这个东西？用这个东西之前有没有条件？和以前的瀑布流开发有什么区别？
最重要的是这东西是否真的适合当前的团队？
……
瀑布流开发（传统）
在这种管理方式中，可以发现，就跟工厂的流水线那样，一环扣一环，因此我更喜欢称为流水线。
在这种管理方式中，可以发现有着很严重的问题。后面的人要等待前面的人做完，在前面的人没有做完时，后面的人就会一直空闲着，前面的人做完了，后面的人就会很忙碌，这时就变成前面的人很空闲。
有人会想，这个问题很好解决。
前面的人做完了，就给下一个项目的任务给他，或者是给别的任务给他，问题在于这个人做完了，空闲下来了，此时你分配别的任务给这个人时，测试刚好测出了问题，这时又问题，刚分配的这个新的任务如果没有做完，后面的人又要等待。如果测试测出的问题不去解决，在这个问题涉及的流程中就要停下来了，因为测不了了……
就这样一直循环时，就会造成测试很累、开发很累。
随着如此循环的次数越多，等待的时长也相应的增加，最后项目顺理成章的延期了。 项目管理者很头疼，要去忽悠忽悠客户，解释解释原因。
当然了，一个项目造成延期的因素是由很多，这里只讨论管理模式的不同造成的问题。
在来看看一个开发的例子：
需求：在年底时统计过去一年的信用卡账单时。
环境：单月的账单存储在MongoDB数据库，双月的存储在MySQL数据库。
最简单的实现：如果是先查询出第一个月的，再查询出第二个月的账单，第三个月……如此循环。这种实现方式的问题在于每次都要等待，12月要查询12次，会产生12次的等待间隔时间。
优化：采用多线程工作的方式，开12个线程同时进行查询，只有12个线程都执行完了，在执行12个月的累加逻辑。（JavaAPI：CountDownLatch）
现实生活：企业年底财务报告，一个财务人员要先计算出过去每一个月的开销，最后累加得出结果。这样的效率自然是很慢，如果是让12个财务人员，每个人都负责计算出那一个月的，最后把大家计算出来的数值进行累加，这样总比一个人来统计要快。
需求变更：
在现实生活的例子，如果在统计到一半时，财务主管说，企业年底财务报告中不需要统计今年企业开销的总金额了，改为统计企业今年在出差补贴中的总金额。
如果是一个财务人员的话，假设此时统计到了三月份的企业开销总金额，只需要重新来过就可以了，只影响到她一个人。
如果是12个人来统计的，影响的是12个人。
在这些例子中，我们可以发现，效率很低下，已经无法适应现在节奏越来越快的商业环境了。特别在互联网企业中，对企业内部管理运营效率的要求性是非常高，因互联网企业中，人员就是最大的成本。（一家200人的互联网企业中，每年的固定支出最少是5000万）
在类这些情况下，作为项目管理者自然会想，既然这样，是否可以用类似开发的这种多线程的方式的呢？
很快就有人提出了敏捷开发，我更喜欢称为快节奏管理模式或敏捷管理方式。因为这是针对一个互联网项目的全生命周期的一种管理方式，难道一个互联网项目的全生命周期的关联仅仅只有开发？
或许有人说，这只是一个名词。不需要在意，但作为一个项目管理者，科学性、严谨性是非常重要，这将是你能否掌控好一个项目的基础。
敏捷管理方式
在这张图中，似乎就跟上面的例子那样，变成同步去做一件事。
上面那张看的大家可能会有点懵，那么看下面那张，在统计一年的账单中可以发现，每个月的账单计算是同步进行，最后做一个总金额的累计。不在向之前那样，是一个月计算完了，在计算下一个月的。这样的速度自然是快了。
所以，一直在说的敏捷开发就是把一个项目进行拆分，尽量的以小任务同步进行，减少中间等待和停顿时间。
敏捷管理方式会导致的问题有哪些？为什么会导致这些问题？
没有什么比实际项目应用更有趣的，下面我们就用一个模拟项目实例来看看。
商城项目
项目计划（以下仅为模拟，实际的项目计划中是细到如添加、更新等功能的开发时间）：
| 负责人 |
功能模块 |
时间 |
说明 |
| 前端人员A |
订单管理 |
20191111 ~ 20191113 |
1、按照与后端人员A约定的接口进行开发，20191115进行联调 |
| 后端人员A |
订单管理 |
20191111 ~ 20191116 |
1、按照约定提供数据给前端人员A，20191115与前端人员进行联调 2、20191116这一天需要与后端人员B进行联合调试，走通订单流程 |
| 后端人员B |
支付与物流 |
20191111 ~ 20191116 |
1、先模拟假定数据进行开发 2、20191116这一天需要与后端人员A进行联合调试，走通订单流程 |
| 测试人员A |
订单管理UAT用例文档 |
20191111 ~ 20191113 |
1、按照产品要求编写测试用例（预知条件、验证步骤、期望结果等等） 2、编写的测试用例需要产品、开发保持信息同步 |
| 测试人员B |
支付、物流UAT用例文档 |
20191111 ~ 20191113 |
1、按照产品要求编写测试用例（预知条件、验证步骤、期望结果等等） 2、编写的测试用例需要产品、开发保持信息同步 |
窥见：
项目开始时间几乎都是同步进行的（这只是模拟，一般项目会分期进行）。
需要时刻的保持信息同步，即每个人都需要知道对方的进度，这也是为什么会有晨会的原因（建议争取10分钟内结束晨会）。
项目所有成员需要不止需要了解自己的功能需求，还需要了解项目内其他成员的需求。
对每一位成员都要求有清晰的沟通能力，及对成员之间的默契（建议阅：https://blog.csdn.net/Su_Levi_Wei/article/details/103276666）。
每一位成员之间的关联度非常高，项目成员可能都会异常的紧张，这可能会导致团队内部和谐问题或个别问题。
……
影响：
需求更改：由于已提前分配好任务了，在这个过程中出现的需求更改将会影响到涉及这个业务的所有人员（前端、后端、测试），甚至是整个项目团队，而后各自还要进行信息同步，及确认项目计划是否变更，计划变更的影响范围……因此对产品经理有较高的要求，需对项目行业市场、背景、需求理解需要较为深刻。
休假/出差：人员休假/出差，将会影响整个项目计划，如有必要需要进行整个项目团队的计划变更，并进行信息同步（目前大部分都是让请假的开发周末跑回去加班）。项目经理在进行项目计划规划设计时，就需要充分考虑这方面的问题，建议在做项目计划时每周预留出空闲的一天（提前完成还可以领工）。
其他事故：开发数据库服务器出问题了，修复花了某位开发人员半天的时间，目前大部分都是让这位开发加班去完成当天的任务。这体现出对项目经理的要求更高了，因此这也是为什么谷歌在招募产品经理时会要求产品经理必须有编码经历（对于整个项目周期和某需求周期产品经理了解是最清楚的，产品经理通常会担任项目经理）。
任务拆分的不够细：将会导致项目计划所设定的时间与实际需要的完成的工时是不一致的，这种情况通常是发生在项目经理没有对团队人员有充分的认识、认知，对领取到这个任务的成员的能力不够了解（每家企业评级标准不一），或是对需求理解偏差。也进一步解释了为什么产品经理会担任项目，产品经理最好是有过编码经历，及需要对项目每一位成员的能力非常清楚。
标准不明确：没有标准，即没有方向。开发人员和测试人员是否可以理解为只是做了这个功能就可以？不需要去考虑效率等其他问题？可能有的会说这也是成员个人积极性的问题，但这难道不是产品经理及架构师与项目方沟通时，忽略了性能标准？项目经理对缺少的这部分也不觉得疑惑吗？作为一名管理者，反省自身问题比寻找他人问题更重要。
……
敏捷管理方式模板
基本功课：
每日晨会（建议争取10分钟内结束晨会）：对昨日的工作进度、问题的总结，也是了解其他成员的工作进度机会（特别是这种团队同步进行的工作），及清晰的描述今日工作。
每周周列会：对这种的工作进度、问题的总结，也是了解其他成员的工作进度机会（特别是这种团队同步进行的工作），及清晰的描述下周工作
成员周报：清晰的描述这周及下周的展望。
清晰的里程碑目标：每一位成员都要清楚的知道自己做的事情有什么意义？
清晰的项目目标：每一位成员都要清楚的知道这个项目的目标？在这个目标面前，自己能够做的了什么？自己能够有什么成长？只有自身获益，才能令自身全身心的投入。
……
敏捷管理方式-需求下放涉及内容
总结
敏捷开发就是一个不断拆分需求任务，尽量让每一个需求任务能够同步进行。
产品经理的要求较高，不仅只是出个高保真和PRD文档，还要求对此产品市场、背景及对产品、市场的敏感度都有一定的要求。
项目经理的涉及的知识面要求较广，对项目的把控灵活度能力较高。
团队的默契，及对团队每个成员都有需要具备一定的要求（如沟通能力、清晰的文档撰写表述能力）。
团队每位成员都需要清楚、清晰的知道项目计划的弹性，及项目方在实施、运营此项目时的过程。
在如此紧张的情况下，对整个项目团队内部气氛的调和，更显得异常重要。
在国外和国内都有很多敏捷管理方式的成功案例，但只要仔细观察，可以发现这些成功案例的共同点，都在于团队的兼容性、默契性、成员素质高。
作为一名基层人员，常常看到很多文章，某某大牛又在说敏捷管理方式的好处了，但敏捷管理方式是否真的适合你们的团队，这个有待商榷。目前为止看到过的大牛在讲敏捷管理方式时，都没有讲到怎么去判断这个管理方式是否适合你的团队。
因此，我认为如果你把仅仅是以上列出来的问题解决了，那么你可以尝试去使用。否则在这些显性问题都无法解决的情况下去使用，在使用过程中在去解决，可能整个团队的心都散了。
