©2016-2024 Matools All rights reserved,
粤ICP备17059708号
开发过程管理，主要面向开发人员的管理。其核心目的，是通过一个项目管理软件，来管理不同项目，然后通过项目的里的工作项，了解开发人员的工作量，效率，从而来管理开发人员，合理调配开发人力。
名词解释
项目：一系列 <https://baike.baidu.com/item/%E7%B3%BB%E5%88%97>独特的、复杂的并相互
<https://baike.baidu.com/item/%E7%9B%B8%E4%BA%92/1534412>关联
<https://baike.baidu.com/item/%E5%85%B3%E8%81%94/165901>的活动，这些活动有着一个明确的目标
<https://baike.baidu.com/item/%E7%9B%AE%E6%A0%87/6450>或目的
<https://baike.baidu.com/item/%E7%9B%AE%E7%9A%84/10924745>，必须在明确的起止时间
、预算、资源限定内，依据规范完成 <https://baike.baidu.com/item/%E5%AE%8C%E6%88%90/103816>。
迭代：重复反馈过程的活动，其目的通常是为了逼近所需目标或结果。是产品开发时，对项目的拆分
。每一次对过程的重复称为一次“迭代”，而每一次迭代得到的结果会作为下一次迭代的初始值。开发项目中的迭代，往往是指产品版本的迭代，比如要实现一个产品最终版可能要三次迭代，第一次迭代实现基本原型，第二次迭代实现能用，第三次迭代的目标就是好用，这种情况下，迭代就和
阶段、冲刺类似，而大多情况下，一个迭代，往往指一个产品已经具备了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:
进行冲刺安排工作项时，优先安排一整个完整业务单元的相关工作项。如果时间点确定（基本也是冲刺的出发点，短时高效），那工作项安排上宁多勿少，可以将下轮冲刺的部分工作项安排进来。因为安排工作项也是个费时费力的活，宁可到时间点，开发人员对于部分工作项未完成，也不可提前完成冲刺（除非该冲刺是最后一轮）。
4.项目报告该怎么写？中期报告关心哪些内容？
A:这里提供一个我使用的范本。总共就报告三个方面：1.目前项目进度 2.后续计划 3.总结。其实和像老板汇报工作差不多，具体怎么汇报，有在如何向老板汇报工作？
<https://blog.csdn.net/ZYD45/article/details/80039321>
介绍过。这里说下，项目经理在汇报时，总结可以当部分问题反馈写，但是在你写问题反馈时，如果是具体的问题，一定要将自己的处理方案写入
5.在敏捷开发过程中，前期的分析时，对于一些很细小的操作业务点可能没有提及，开发时才暴露这个业务问题。而且询问时，也是琐碎的询问。可能是问题类别也可能是询问时间，东一榔头，西一棒槌的。
A:
问题的产生，由于分析时没有分析那么透彻，详细。当然要想避免这个问题，就要很牛逼的分析师，庖丁解牛的那种。不过，大多数情况下，都难以做到。我们采取的方案就是，
将问题先记录下来，每个冲刺里都建立一个业务问题的记录文档，出现的问题记录后，在回答，同时再在文档里记录处理方案，等到站立会或中期汇报时再讨论。
简单来说就是，（如果问题很小）先拿出一套解决方案，把项目继续进行下去，后期再细究这种问题。如果是很核心业务，那一定要验证真正需求，征求拍板人意见。
部分参考资料：
arnoldwang，《创业团队的项目管理，如何面向开发人员优化》
热门工具 换一换