tapd项目管理流程
你们都在用什么敏捷的软件开发平台？
你们都在用什么敏捷的软件开发平台？
相关的平台有很多种，推荐一个我们正在使用的，Gitlab jenkins。其中gitlab用来进行代码管理和代码review，而jenkins用来进行自动化构建，后台使用分布式结构，从而保证反馈的实时性。
如何用一篇文章了解清楚acp敏捷项目管理？
我们使用各种敏捷软件写feature，流转、跟踪任务，言必谈敏捷，然而我们是否真的走对了敏捷？
显而易见，敏捷是绝对的结果导向，去文档化，去流程化，高效沟通和合作是究极奥义。
去文档，敏捷管理者需要维护更为精细的需求池；去流程，口头沟通成为常态，对团队的耦合度要求更高。
一、让我们先来了解一下
敏捷的一些概念
Product Backlog:
backlog 即需求池。待办事项列表。
Backlog里面写什么：
1.待开发任务。
2.任务优先级。
敏捷需要维护一份详尽的需求列表。这份列表常常要求scrum持有人（一般是产品经理）对所有待开发事项有深入了解，并且能够把待开发事项分解成更为细致的任务。
story board:
在开发领域，故事版是任务流转的可视化窗口，一般有“待开发”“开发中”“待测试”“返工”“待发布”几个区块，所有任务由任务操作者负责流转至于下一个步骤，这样任何一个人项目成员都能看到任务的完成情况。
▲在开发中，故事板展现所有需求的工作流
burn down chart（燃尽图）：
一个sprint内，人/时是一个比较固定的值。在这个时间框架充分安排开发任务，每天进行时间结算，绘制时间燃尽图。项目成员通过燃尽图获知时间进展，若项目燃尽所用时间与预期时间契合，则需求时间预估和安排合理，若不契合则需要在下一个sprint进行调整。
这些概念定义了敏捷各个环节的工作，这些流程和节点是敏捷开展的基础和保障。
二、离开敏捷工具
我们怎么敏？
一个误区：我们用了敏捷管理工具，就敏捷了
随着敏捷在行业内的不断融入，各种工具产品层出不穷。国外jira、redmine，Axosoft ，国内的leangoo、禅道，三大家则都有自研的工具，百度的icafe，阿里的aone，腾讯的tapd。
（▲数据来源：“中国开发者白皮书”）
我们在敏捷管理工具上建迭代，建需求，研发、测试等着收到需求流转的邮件之后开始干活...任务在测试和研发之间流转，bug提给研发，研发解决bug.....我们宣称：我们敏捷化了！
我们习惯于敏捷软件的便利，拉群解决一切，然而却丧失了敏捷的初衷，scrum的本意。
▲Jira的名字来自于哥斯拉
假设我们没有任何项目协同软件，敏捷怎么实施？
设定一个环境，现在没有任何协同工具可用，但是所有人都坐在一起。有人站起来说，既然这样，我们不如敏捷吧！
▲敏捷工具消失了
敏捷路径里必须有一个项目持有者，制定规划并把握项目走向。这位PM汪我看你骨骼惊奇，你就担负起这个责任吧。
另外还有一个关键人物SM。SM全称scrum master，中文称敏捷教练。一般说来，SM需要由对技术开发以及当前项目明晰的技术经理担任。
虽然缺少线上工具，但至少要准备一些简单材料：一卷双面胶 白纸或一沓便利贴；笔，一面平坦的墙或一块黑板。
如果还有电脑可用，excel或者word，甚至写字板都可以，没有电脑那就白纸好了，总之你得找个地方写下你的需求池（backlog）
需求池示例(任务名称、平台、详细描述、优先级按照P0-PX逐渐递减)
确定一个sprint周期的自然天。可以用月/旬/周等时间概念作为周期，我们选择一周（五个工作日）作为一个sprint周期。
按照优先级，从需求池中拉出你认为应该加入你们一穷二白的第一个sprint里面去的需求，别太贪心，大概觉得差不多一周左右的开发量就够了。拉上SM单独开一次小会。
▲当然不是让你俩傻站着，你俩要开会
你们一起通览需求，SM根据经验对需求先行分解一遍，比如某需求在开发层面需要分解为ABC三部分，这三部分就形成三个开发任务。
分解完成后，你得到了一个比较详细的待开发列表。
正式开始一个sprint开始之前，产品、研发、测试需要一同开一次scrum会议，共同讨论本次sprint的功能点。
会上讨论什么：
1.需求讨论或技术讨论；
2.成员预估需求所需开发时间；
3.需求是否match人力时间，需求排入sprint；
4.交流一下感情。
▲每个任务的预估时间在最后由敏捷教练综合判定
scrum会后你的工作：
1.整理这个sprint内的需求列表；
2.整理每个需求的预期开发时间；
3.撰写故事版上的小纸条；
4.把小纸条贴到故事版上；
5.制作一个燃尽图。
一个改良版的小纸条，写明开发者、任务描述、预估时间和每日燃尽时间
故事版布局如下：
一个标准的故事版：最开始所有的小纸条都在“待开发”一栏
到此为止，你可以开始run起一个sprint。
以为这就完事了？天真。
接下来你必须来参加每日举行的项目短会。为了缩减会议时间，我们一般站着开——所以也叫“站会”，早上上班后或晚上下班前，抽出十到十五分钟时间，完成它。
▲每日站会
站会都有什么人参加：
1.你（项目持有者）
3.其他scrum成员
站会干什么：
1.昨天大家分别做了什么事，遇到了什么问题，如何解决或寻求解决方案；
2.昨天任务的完成状态，剩余多少时间，是否需要进行时间修正（增加时间或减少时间），把已完成的任务流转到下一环节（把纸条从一个item内撕下，贴到下一个item里去）；
▲任务进行中，小纸条的示例
3.功能测试后是否有返工；
4.交流一下感情。
站会之后你的工作：
绘制燃尽图
▲sprint的任务时间随着sprint的进程逐渐减少
周而复始，完成了一个sprint后，你们开了第二次scrum会。这时议题多了一项:复盘上一个sprint。
任务未能燃尽；研发返工过多；测试需求淤积.....
针对问题讨论解决方案，根据实际情况进行下一个sprint的任务安排。
自此，我们在没有任何敏捷工具的帮助下，开始了敏捷的旅程。
三、敏捷不需要文档吗？
敏捷了一段时间之后，产品进入正轨，项目拿到拨款，公司拿到投资，你们要扩大团队规模，新入职的同事想了解下产品和技术细节，你告诉TA：
你要不翻下backlog看看？这个实现你要不看一下代码？这个字段我也不记得有没有了....你抓包看下？
新同事一脸懵逼，难道咱们没有文档吗？你自豪地指出：
“我们是敏捷团队。”
十几个人八九条枪的阶段之后，产品趋于稳定，团队逐步扩大。无论从内部协调还是外部沟通上对产品流程的正规化和文档化要求与日俱增。
从短期收益上看，文档对于敏捷开发是非必须品，并且很有可能会拖慢进度。在一个sprint中，口头沟通显然效率更高，每个人都有精确到工时的任务，没人有等待文档更新的时间。强调文档就等于放弃灵活性。
从长期和宏观上看，文档对于敏捷团队和敏捷的实施利大于弊——节省在一些常规问题上的沟通成本，同时降低错误的发生概率。对于一个将要长期实施敏捷的团队来讲，文档让后续的工作效率更高。
▲一个以讹传讹的过程
那么——谁来维护文档，怎么维护？
我们挑选其中一个重要的文档：产品文档
产品文档：PM虽然维护backlog、跟SM分解需求、开scrum会、写小纸条、开站会、画燃尽图、还有什么外部沟通啊......但你要认真把这个文档维护好。
▲对又是你
产品文档包括：
1.需求；
2.加入日期；
3.开发版本；
4.呈现和详细方案。
长久来看，文档是提高效率的一大利器
文档的时效性和灵活性远低于口头沟通，但却有它实在的好处。
1.空间上，文档传播范围更广。规范化和常规化的内容形成文档可以大大减少沟通成本。尤其在多个系统协作的情况下，跨scrum、跨团队甚至跨部门的沟通时有发生，文档的重要性和便捷性不言而喻。
2.时间上，文档流传性更好。团队不是一成不变的，有人离开有人加入。更新换代中，新人快速了解系统，老兵传承研发理念；在更大的时间跨度上，文档的存在就是对产品历程的完整追溯，你将不用他人帮助就可以了解到产品的大部分面貌甚至全貌。
四、大项目怎么引入敏捷？
看起来敏捷方法特别适合产品常规迭代。有一种可能性是，你的产品需要插入一个巨无霸模块，与其说是模块倒不如说它几乎可以成为一个产品了。你想了想，这么大个项目怎么说产品、设计、研发、测试全情投入也得个一两个月。
还能走敏捷吗？
注意你的项目时间。有deadline的scrum是带着镣铐跳迪斯科，时间节点关乎sprint的大小。
大项目敏捷之前，先得不敏捷几步。
可能会发生一到多次需求讨论会。
团队必须不厌其烦地理解需求或修正产品经理“天真的幻想”，产品经理使用不断完善的原型同团队进行沟通。在最后这次评审邀请项目成员和所有协同团队，除了敲定的产品功能，技术上需要得到一些初步结论（比如“能不能做”）。
大项目敏捷中：
1.将deadline之前的时间分解为多个sprint。（deadline之前必须留出一定“出血时间”用以解决时间预估不足的任务、返工任务以及bug)
2.将所有需求分解成任务，开一次全局scrum会。预估时间之后，分散任务到各个sprint中。在时间较紧的情况下，sprint的容量就要相应增加。
▲一个需要加班的sprint
3.进入敏捷流程，常规scrum会、站会，燃尽图，故事版。未完成任务在scrum会上重新预估时间，滚入新sprint内，以此类推（按时完成sprint内的任务是目标。实在不行我们还有“出血时间”呢）
4.别忘了文档。
虽然被推崇备至，但敏捷并不是完美的开发方法。敏捷的最大的优势是灵活，而造成敏捷问题的根源也正是灵活。
五、文末再总结本文重点
1.敏捷是一种流程、方法、理念，甚至信仰。
2 用了敏捷管理软件不一定就是敏捷。敏捷的初衷是团队成员能够更加紧密地配合完成工作，线上的的流转如果削弱了这种配合性，反倒背离了敏捷的本意。实际上只要有白板纸张和笔，你的团队就能开始敏捷。
4.我们敏捷了，不是不要文档了。在外部交流多、世代跨度长的情况下，文档的必要性显而易见。长期的面对面沟通最终会导致低效，这也是敏捷缺陷的根源。
5.大项目开发中可以走敏捷，具体问题具体分析，需要根据项目特点制定敏捷计划。