[敏捷开发]研发管理开发过程管理

开发过程管理，主要面向开发人员的管理。其核心目的，是通过一个项目管理软件，来管理不同项目，然后通过项目的里的工作项，了解开发人员的工作量，效率，从而来管理开发人员，合理调配开发人力。

名词解释

项目：一系列独特的、复杂的并相互关联的活动，这些活动有着一个明确的目标或目的，必须在明确的起止时间、预算、资源限定内，依据规范完成。

迭代：重复反馈过程的活动，其目的通常是为了逼近所需目标或结果。是产品开发时，对项目的拆分。每一次对过程的重复称为一次“迭代”，而每一次迭代得到的结果会作为下一次迭代的初始值。开发项目中的迭代，往往是指产品版本的迭代，比如要实现一个产品最终版可能要三次迭代，第一次迭代实现基本原型，第二次迭代实现能用，第三次迭代的目标就是好用，这种情况下，迭代就和阶段、冲刺类似，而大多情况下，一个迭代，往往指一个产品已经具备了1 2 ..5...项功能，下一次迭代就是优化或追加功能。

冲刺：敏捷开发里的名词，和迭代类似。时间周期更短的阶段，一般在开发中为了快速出部分原型效果。

积压板：微软的tfs里的工具，主要可以用于在项目里存放idea，各种需求或想法。简单来说，记录一些idea的便签。

工作项：将需求分拆为一个个小的具体工作名词，开发任务。比如 “首页-导航栏”，“首页-登录按钮”。基本工作项就是一个开发的最小单元，当然这是理想化的时候，很多时候分不到这么细。简单来说，就是一件件要做的事。

一个项目，可能被拆分为多个冲刺，每个冲刺里的需求，被拆分为多个工作项。

项目>冲刺>工作项。（需求可被直接存放在项目里，也可以在冲刺里）

生命周期：

项目干系人：参与该项目工作的个体和组织。简单来说，就是项目里干活的，和管理干活的那拨人。

一次冲刺的相关流程

整个敏捷开发思想核心，是为了快。

快速的迭代，快速出一个版本，先用一个有核心功能的版本出来，然后再在后面的冲刺里，丰富这个功能。每次聚焦一个核心，然后不断迭代，扩充这个核心。

有的公司团队，使用的敏捷开发是按照，功能点拆分的方式，不同团队开发不同模块之类的，最后拼装在一起，类似于拼图模式。

而我们采用的是一种滚雪球的方式：把所有需求列出来后，抓住最核心的需求优先开发。到了下一冲刺，再根据已开发的核心需求，看其周边需要或配套的需求进行开发。在冲刺1，团队开发出一个，基础可以用的产品，冲刺2后，弄出一个略微丰富的产品。到了冲刺3，开发出一个好用的，功能丰富的产品。

个人经验

以下这些经验，主要偏向作为项目经理的思考的。

不过现在是这些想法，过个一段时间，可能我就不这么想了。

在冲刺或迭代启动会时，那份启动文档，一定要写明此次迭代（或冲刺）的目标。比如：为了让XX功能使用起来、将XX页面展示、显示xx信息等。这么做的好处是，在冲刺总结会时，可以用来评审此次的冲刺是否成功，也有利于总结文章。

偏差管理。如果项目组员在执行工作项（尤其是开发人员），后来发现和项目指定计划有偏差，不要立即“批评”组员的开发错误。而是，先询问其处理偏差的原因，若是反馈因为沟通理解的原因，可以记录下来（主要记录在哪个点上沟通出现问题），防止下次项目再犯。若是由于组员有自己的思考理解，“有意”处理成这样。要先鼓励他，项目经理表明自身的态度，欣赏他有独立思考能力，然后再沟通，进行“纠偏”。若是当时不小心气上头，骂了组员，后面私下抽空（最好是次日），可以沟通下“自己回去又想了下，你说的也有道理。不过，目前的项目应该是xxx”。道理很简单，每次做完一个项目，项目成员都应该有成长，无论是你引导的，还是他自发的，否则他永远不成长，你就永远要每次划分很细工作项，时刻盯着他。

以下是我们在执行敏捷开发时，遇到的问题：

1. 工作项在实际开发拖拽使用时，由于开发人员对单独模块不了解，所以几个项都一并开发（比如，把一个页面拆分成了四个工作项：顶部工具栏、中部banner显示、左侧tab面板、中间状态列。开发人员，在开发时，非先单独开发完【顶部工具栏】，再去开发【中部banner显示】，而是在搭建整个页面时，每项都有涉猎）。造成项目经理在看迭代版（故事墙）时，看到某个开发人员有好几项都在并线开发，然后这几项周期显得很长。

A:我们考虑，在开发某些工作项时，尤其是有关联关系的工作项，优先将目前手上，正主力开发的工作项拖动到【开发中】故事列，等这一项完成了，又着手关联的那个工作项时，再将其拖入到【开发中】

2.工作项优先级和开发顺序的理解。在分析阶段，某个工作可能就是一个需求点A，觉得比较重要就会用高优先级标识。而在后面开发时，为了实现【工作项A】，要先去开发优先级低的【工作项B】。如果一个冲刺里，有大量的这种A/B矛盾，后面在时间点不够下，对于需求砍断很棘手

A: 在将需求点进行设计，并拆分为工作项时，要有个技术把关，知道哪些工作项要拆分的重点。并且，在项目时间不充裕的情况下，要进行每日站立会议，目的就是为了及时反馈开发人员，真正在开发的工作项，帮其处理这些A/B优先级问题。

3.前期项目经验不足，或者对开发人员能力评估不够，冲刺里工作项如何合理安排？才能按时高质量完成项目？

A:进行冲刺安排工作项时，优先安排一整个完整业务单元的相关工作项。如果时间点确定（基本也是冲刺的出发点，短时高效），那工作项安排上宁多勿少，可以将下轮冲刺的部分工作项安排进来。因为安排工作项也是个费时费力的活，宁可到时间点，开发人员对于部分工作项未完成，也不可提前完成冲刺（除非该冲刺是最后一轮）。

还有一点补充下：工作项的划分，尽量是按照适度完成时长来安排，比如每个工作项都是2-3天即可完成，太长一个工作项一周不可取，太短，两个小时就完成了也不可取。所以有时候，一个工作项里可能有两三个功能点，有时一个功能点又被拆分为若干个工作项。

4.项目报告该怎么写？中期报告关心哪些内容？

A:这里提供一个我使用的范本。总共就报告三个方面：1.目前项目进度 2.后续计划 3.总结。其实和像老板汇报工作差不多，具体怎么汇报，有在如何向老板汇报工作？介绍过。这里说下，项目经理在汇报时，总结可以当部分问题反馈写，但是在你写问题反馈时，如果是具体的问题，一定要将自己的处理方案写入

5.在敏捷开发过程中，前期的分析时，对于一些很细小的操作业务点可能没有提及，开发时才暴露这个业务问题。而且询问时，也是琐碎的询问。可能是问题类别也可能是询问时间，东一榔头，西一棒槌的。

A:问题的产生，由于分析时没有分析那么透彻，详细。当然要想避免这个问题，就要很牛逼的分析师，庖丁解牛的那种。不过，大多数情况下，都难以做到。我们采取的方案就是，将问题先记录下来，每个冲刺里都建立一个业务问题的记录文档，出现的问题记录后，在回答，同时再在文档里记录处理方案，等到站立会或中期汇报时再讨论。简单来说就是，（如果问题很小）先拿出一套解决方案，把项目继续进行下去，后期再细究这种问题。如果是很核心业务，那一定要验证真正需求，征求拍板人意见。

6.敏捷开发的项目看板里，要把缺陷独立循环在体外吗？

A:原本在初版设计时，我们也是这么想的。像很多SASS产品一样，把缺陷独立于敏捷开发的项目看板外，项目看板仅是开发需求。但是，在实际使用过程中，如果一开始做了足够的分析，或者把工作项拆的合理点，那看板中的工作项，就是当前迭代（冲刺）的功能说明列表，测试人员也仅需根据此列表比对测试，并在里面填写测试描述就行了。

所以，一个工作项就三种类别：开发、缺陷、改进。整个团队人员只要关注一件事务即可，相关人员也可以直观地看清，哪些有缺陷，哪些要改进，在站立会议上，也不用切来切去了。但是，这样也有缺陷，在不以缺陷为绩效考核的公司，可以这么干，如果涉及到缺陷跟绩效挂钩，那这相关，在后面统计绩效时，就可能比较麻烦。

7.在敏捷开发的过程中，优先关注哪些？是bug？是需求？还是用户反馈？

A: 大多数人第一反应是【需求】，包括我自己，第一反馈也是如此。但经过这次我们自己去做敏捷开发的工具（加上听了某大厂产品经理的分析），感觉用户反馈真的是第一位。首先，做出产品就是给用户用的（无论2C，还是2B，亦或是自己家用的）。因为是给自己做工具（自己做，更顺手），所以对公司内使用员工感受，信息反馈更注重。根据他们的反馈即时调整下一轮冲刺的开发方向，才会使产品做出来的，让大家觉得更方便，好用。

部分参考资料：

arnoldwang，《创业团队的项目管理，如何面向开发人员优化》