优酷敏捷项目： 做敏捷项目管理时应该注意什么？

从历史上看，无论谁是项目的技术负责人，也需要做项目管理的工作。尽管我们的系统和流程变得更加相互依存，然而，我们却开始看不到未知的依赖关系和涟漪效应。当我决定使我的IT团队能够胜任项目管理时，我想这将是非常简单的：培训或聘请一些好的项...展开全部

优酷敏捷项目： 什么是敏捷开发

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，...

其他答案:敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。 除了原则和实践，模式也是很总要的，多研究模式及其应用可以使你更深层次的理解敏捷开发。 建议看一看大神的作品：《敏捷软件开发原则、模式和实践》

优酷敏捷项目： 如何提升个人敏捷项目管理能力

首先，拥抱变化，克服抵触，做好实施敏捷的准备。敏捷不是洪水猛兽，既然企业决定引入敏捷的变革，一定是敏捷项目管理方法有可取之处，何不加以尝试，再做决定，而不要拒绝变化，盲目抵触。正如传统项目管理中提倡的——沟通是项目经理的基本素质，...展开全部

优酷敏捷项目： 敏捷项目管理都有哪些阶段？

目前项目管理流程分为6大阶段：1项目计划、2需求调研、3概要设计、4详细设计、5开发、6测试（并且每个环节会有审核）。用日事清把紧急重要的事情罗列在最前面，把重要不紧急的事情排在后面一些，把重要不紧急的事情排在后面一些，实施了项目管理流...展开全部

其他答案:它适用于软件，因为软件是软的，可以改。要是硬件，改起来就没那么方便了，它适用于客户不知道自己要啥的情况，其实，这样的客户占绝大多数。因为客户不知道要啥，所以你需要不断帮客户弄明白他到底想要啥，换句话说，你需要和客户沟通，合作，倾听反馈，持续改进。 它适用于快速变化的市场，你在埋头造一辆汽车的时候，客户已经想开飞机满天飞了，这就需要你能一步步的把汽车改成飞机，还能按时交付。它适用于在一个地方办公的小团队，一般10个人以内。这样能使敏捷中主要的沟通方式“face to face” 是可行的。 日事清是以gtd时间管理方法为主导的管理工 具，收集、整理、组织、回顾、执行，让你每天的日程管理安排都会井井有条。

优酷敏捷项目：敏捷项目管理是什么？

软件项目管理的两大主流管理模式分别是传统项目管理和敏捷项目管理。

传统项目管理通常采用的是瀑布式、部分迭代开发模式，要求在项目建设时，需求足够明确、文档足够规范，迭代过程中需求变更越多、越晚，对项目影响越大，会影响到项目的交付质量。

敏捷项目管理作为新兴的项目管理模式，简化了传统项目管理的繁琐流程和文档。以 Scrum 为代表，欢迎需求变更，在客户需求不明确的时候，以在较短的周期内开发出可用的软件为目标，来帮助客户描述自己的需求。迭代过程中的需求变更会加入到项目继续迭代需求池，丰富项目的产品功能。

一、管理流程

完整的项目管理流程可以总结分为五个过程组：启动、规划、执行、监控、收尾

1、传统项目管理

传统的项目管理要对项目的所有过程进行管理和风险把控，并要求在不同环节的有文档输入和输出。比如，PMBOK 第五版对项目整合管理的过程组做了文档输入和输出的整理，如下图。

但是，项目管理主要是对范围、进度、成本、质量、人力资源、沟通、风险、采购和干系人进行管理，每个环节都存在启动、规划、执行、监控和收尾过程。

如果采用传统的项目管理模式，每个环节都必须要进行严格的规划，一旦出现规划以外的变更，都需要经过批准后才能执行改变。

2、敏捷项目管理

敏捷项目管理简化了繁琐的流程和文档管理，主张团队内部的面对面沟通和交流。以 Scrum 为代表，简单、持续集成、不断交付、价值优先、拥抱变化的原则在面对时刻变化的市场经济和不断发展的技术时变得十分友好。敏捷项目中，项目管理计划分不同的等级，可以用一个洋葱图来表示，也就是洋葱计划图，如下图。

战略和投资规划在敏捷项目管理的最外层，由更广泛的组织管理系统来处理。由外往内，不断切分项目计划，最后实现最小周期的可行性版本迭代。对复杂或不明确的客户需求进行合理的分割，最终实现总体上的统一。

二、风险控制环节

项目风险在任何项目中都存在不确定性，一旦发生，会对项目造成积极或消极的影响，如范围、进度、成本和质量。

1、传统项目管理：

传统项目管理要求项目在规划过程中规划风险管理、识别风险，并且对风险进行定性/定量分析，给出风险应对方案。虽然已知的风险可以在被识别和分析后采取应对措施，但正是因为风险的不确定性，要求项目风险管理必须给未知风险或者已知却又无法主动管理的风险分配一定的资源储备。

所以，传统项目管理会要求提供风险登记表，并且记录风险应对措施在处理已识别风险及其根源方面的有效性，完成风险再评估和风险审计，直到风险被降到最低。

2、敏捷项目管理：

敏捷项目管理不同于传统项目管理，开发评估是以工作量为导向而非时间导向。所以，在进行开发任务评估时采用的是相对估算而不是绝对估算，为风险留足了应对空间。同时，Scrum集合了一线人员的参与，经验分享，集思广益，将小型团队转化成独立的管理者，更有利于问题的解决。

敏捷项目管理在项目没有正式结束前，交付的可用软件是允许风险存在的，并且是根据风险的优先级来进行排期修复。

三、第三方业务风险控制服务企业项目管理分析

1、项目管理模式：外瀑布内敏捷（有人称为“信封法”）

第三方业务风险控制服务行业目前还没有发展出固定的行业标杆，大家都在竞争中追求最大范围的满足行业需求。在这样的背景前提下，大部分项目都没有明确和长久稳定的需求，Scrum 管理模式很好的满足了这个行业的项目管理现状。

但是，作为行业客户，在大部分的商务场景下客户都会希望通过固定成本合同来实现自己的利益最大化，问题是现在合同双方都很难在项目开始时明确约定需求和最终实现方式。所以，在客户不能接受 Scrum 时，通常会选择外瀑布内敏捷的项目管理模式，满足双方的利益。

2、举例：

如果把拍婚纱照作为一个项目，摄影师和新人作为项目主要成员，项目基本流程满足：

• 选婚纱照的套餐（固定成本，确定基本需求）

  

• 拍摄（项目启动）

• 挑照片（提交测试，开始验收）

• 根据底片修图（修复）

  

• 拿到照片（项目结束）

>>>>以上就是顺序执行，瀑布式的结果。

然而，拍摄的过程中新人通常都会要求：

• 较短短时间内提出新增造型、内景换外景的要求（切换pose的任务）

• 配合摄影师完成拍摄环节的工作（通过迭代，完成项目）

>>>>以上就是内部快速迭代，敏捷式的结果。

很显然，新人在拍婚纱照之前并不知道自己最终拿到的照片穿的会是哪套衣服，摆的会是哪个pose；但是，很清楚的是哪天拍照、哪天挑照片、哪天可以拿到照片，这套流程同时满足了内部和外部需求。

只是，为了项目顺利结束，可能在内部和外部需求时，并没有要求完全以相同的速度前进，就像你不能以你配合完成摄影的速度去要求摄影楼马上提供婚纱照。

四、第三方业务风险控制服务企业产品服务流程

其实，作为第三方风控服务的企业，项目服务流程基本上和拍婚纱照一样：

五、传统 VS 敏捷 ？ 适者生存

敏捷项目管理只是一个灵活的实践框架，提供的是一套清晰游戏规则，根据不同的环境可以提供一系列不同的途径。

传统项目管理却是一套中央集权制管理法，要求按计划行事，任何环节发生变更都必须获准后才能进行改变。

我们知道的是，第三方业务风险控制服务行业目前还没有发展出固定的行业标杆，没有一套可称为标准的、行之有效的流程打通各个环节。更重要的问题——合同双方都很难在项目开始时明确约定需求和最终实现方式。

在市场经济不断发展、时刻变化的现代互联网环境下，适应变化、拥抱变化的第三方业务风控服务企业的项目管理，才是友好的、可行的管理模式。

六、阅读参考

一个很有趣的“敏捷和瀑布”对比例子，给大家作为阅读参考：

1、敏捷开发

• 客人到餐馆来点菜（新项目）

• 不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）

• 根据图文菜单，客人点了是个菜（根据原型和设计稿，基本确定了需求）

• 后厨开始准备（项目启动）

• 配菜、炒菜，先上了两盘，让客人尝了尝味道（先提供可用实例给客户用）

• 客人说还不错，后厨继续准备后面的菜，陆续上菜（不断迭代，不断测试）

• 上菜过程中，客人突然发现有个菜的味道太淡了，让后厨加了点盐又端上来了（敏捷的好处，可以不断测试和需求变更）

• 又上了两盘，不够辣，又拿到后厨加了辣（敏捷的坏处，需求没有提前明确，反复迭代，增加了工作量）

• 到最后两盘时，客人要求换两个菜，还好没炒（迭代的好处，随时接受需求变更）

• 客人吃完，很满意（基本满足了全部的要求）

2、瀑布模型开发

• 客人到餐馆来点菜（新项目）

• 不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）

• 根据图文菜单，客人点了十个菜（根据原型和设计稿，基本确定了需求）

• 后厨开始准备（项目启动）

• 根据客人的下单配菜，炒菜（基本上不会主动去了解完整需求）

• 半个小时了，菜还没上桌，客人饿极了（项目启动后很长一段时间客户什么都看不到）

• 再过了二十分钟，十个菜都一起上来了（项目最终一次交付）

• 客人说，有几个菜挺好的，但是有个菜味道淡了，有两个不够辣，还有两盘重复了想换掉（我是买单的，我要变需求）

• 这时候大堂经理来了，说，“味道淡了可以加盐，不辣可以加辣，但是换菜不行，已经炒好的那两盘菜也是要算成本的”（瀑布的坏处，需求变更比较麻烦）

• 于是，后厨只给客户加了盐，加了辣

• 客人吃完，不是很满意，下次不来了（没有满足需求）

关于“敏捷项目管理”的话题，我们就谈到这里，欢迎加入我的圈子——【精益管理圈】，持续的精益管理智慧传播、理念宣扬、心得分享、经验交流、培训提供，谢谢！

优酷敏捷项目：如何使用Worktile进行敏捷项目开发管理？

1. 开发Development

2. 产品路线Roadmap

3. 计划Planning

4. 缺陷Bugs

5. 收件箱Inbox

开发Development

是我们开发最主要的项目，由技术负责人负责，新的任务分别来源于计划Planning，收件箱Inbox，缺陷Bugs，其中的任务分为以下几个列表：

要做：每周的启动会上在确定新的一周开发计划时，都会向该列表中添加新的任务，并对新添加的任务进行优先级排序，我们并不在这个阶段进行任务的分配

进行中：正在进行设计或开发的任务，开发者会分配任务给自己，并拖动任务到当前列，并指定任务截止日期

待测试：开发完成的任务会进行到待测试列表，由测试人员负责质量保证。

待发布：测试人员检查没有问题的任务会移动到当前列，如果在后续测试中发现该列中的任务有问题，该任务也可能会重新进入进行核待测试列表，重复前面的步骤

已发布：对于已经发布的特性会进入到当前列，一般我们会把已发布任务在当前项目保留1个月左右，确保没有问题后，归档已发布的任务。

在开发项目中，我们对于任务的标签使用如下：

其他几个项目

产品路线Roadmap

由产品经理负责，根据用户需求制定产品路线图，列举每季度每个月要做的功能和版本规划，其中的任务既可以按照功能模块划分，也可以按照版本进行划分，目前Worktile团队按照功能模块进行划分。

计划Planning

由项目经理负责，有时候也会由产品经理兼任，其中的任务分为以下几个列表：

要做：列举要做的功能列表，来自于收件箱项目和产品路线产品路线Roadmap项目

产品设计：产品经理（交互设计师）对某一个功能特性进行UE/UX设计，拖动任务到该列

UI设计：需要UI设计师做UI设计时，拖动相应的任务到该列

就绪：拖动到该列的任务意味着已经经过了相关人员的评审，接下来可以进入开发Development项目进行开发了

缺陷Bugs

由技术负责人和产品经理共同负责，其中的任务分为收件箱、待确认、解决中，已解决，待测试，待发布，已发布几个列表。所有团队内部人员，任何人都可以随时向收件箱中报告缺陷，由产品经理确认或技术负责人确定并安排解决。

收件箱Inbox

由运营人员负责，从不同的来源收集用户的反馈，并整理在该项目中，任务按月进行分类，在每周的例会上会对本周新增的用户反馈进行评审，确认需要开发的，进入计划Planning项目。

经验分享

灵活使用任务列表和标签，对任务进行分类和进度表示

尽量做到每个项目的任务足够少，完成的任务归档，如果某个项目的任务只增不减，说明这个项目出了问题，需要调整

在周例会上直接打开Worktile，查看每个项目的简报，对项目完成情况做到一目了然

多使用日历视图，查看任务的安排情况

优酷敏捷项目：什么是敏捷开发？

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行 的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。