tapd类似的项目管理工具
如何用一篇文章了解清楚acp敏捷项目管理？
如何用一篇文章了解清楚acp敏捷项目管理？
我们使用各种各样的敏捷软件来编写特性，循环和跟踪任务，谈论敏捷，但是我们真的在正确的轨道上吗？
很明显，敏捷是绝对以结果为导向的，去文档化、去流程化，高效的沟通协作，是极其有意义的。
为了记录，敏捷经理需要维护一个更详细的需求池；去流程化，口头交流成为常态，团队耦合度更高。
首先，让我们 让我们先看一看
敏捷性的一些概念
产品Backlog:
积压是需求池。待办事项列表。
积压工作说明了什么:
1.有待发展的任务。
2.任务优先级。
敏捷需要维护一个详细的需求列表。这个列表通常要求scrum持有者(通常是产品经理)对所有要开发的东西有深刻的理解，并且能够将它们分解成更详细的任务。
故事board:
在开发领域，故事版本是任务流的可视化窗口，一般有 待开发 ， 正在开发中， 待测 ， 待返工 和 待发布 。所有的任务都由任务操作者转移到下一步，这样任何人都可以看到任务的完成情况。
▲在开发中，故事板展示了所有需求的工作流程。
烧毁图表:
在短跑中，人/小时是一个相对固定的值。在这个时间框架内，充分安排开发任务，每天定好时间，画出时间燃尽图。项目成员通过燃尽图了解时间进度。如果项目的烧完时间与预计时间重合，则估算需求时间并合理安排；如果没有，需要在接下来的冲刺中进行调整。
这些概念定义了敏捷各方面的工作，这些流程和节点是敏捷开发的基础和保障。
第二，离开敏捷工具
我们是如何敏感的？
一个误区:当我们使用敏捷管理工具时，我们是敏捷的。
随着敏捷在业界的不断融合，各种工具产品层出不穷。国外的吉拉、redmine、Axosoft，国内的leangoo、禅宗都有自研工具，比如百度的icafe，阿里的aone，腾讯的tapd。
(▲来源: 开发商 )
我们在敏捷管理工具上构建迭代，构建需求，研发，测试，等等。，然后在收到需求流转的邮件后开始工作...任务在测试和研发之间流动，bug被提交给研发，研发解决bug...我们声明我们是敏捷的！
我们习惯了敏捷软件的便捷，习惯了通过拉组来解决一切，但是我们已经失去了敏捷的初衷，scrum的初衷。
▲吉拉 的名字来自哥斯拉。
假设我们没有。;没有任何项目协作软件，如何实施敏捷？
设置一个环境，现在没有协作工具。是的，但是大家都坐在一起。有人站起来说，既然如此，我们就 让我们变得敏捷！
▲敏捷工具消失了。
敏捷路径中必须有项目负责人来制定计划，把握项目的方向。这个下午王，我很惊讶地看到你的骨头，所以你应该承担这个责任。
还有一个关键人物SM。SM的全称是scrum master，中文是scrum master。一般来说，SM需要一个对技术开发和当前项目有清晰认识的技术经理。
虽然缺少网上工具，但至少要准备一些简单的材料:一卷双面白纸或者一叠便利贴；一支笔，一面平墙或者一块黑板。
如果还有电脑可用，excel或者word，甚至写字板都可以。如果没有电脑，那将是一张白纸。总之，你得找个地方写下你的积压。
需求池示例(任务名称、平台、详细描述、优先级根据P0-PX逐渐降低)
确定冲刺周期的自然日。我们可以用月/旬/周的概念作为一个周期，我们选择一周(五个工作日)作为冲刺周期。
根据优先级，从需求池中拉出你认为应该添加到你可怜的第一个sprint中的需求。唐 不要太贪心。你可能认为大约一周。;的发展就够了。拉SM，单独开个小会。
▲当然，我不 我不希望你们两个站在一起。你们两个要开会。
你们一起看需求，SM根据经验先分解需求。比如一个需求在开发层面需要分解成ABC三个部分，这三个部分形成三个开发任务。
分解之后，你得到一个更详细的待开发列表。
在正式开始冲刺之前，产品、研发和销售。ampd和测试需要一起召开scrum会议，讨论这个sprint的功能点。
会上讨论了什么:
1.需求讨论或技术讨论；
2.成员估计需求所需的开发时间；
3.需求是否与人的时间匹配，需求是否排入冲刺；；
4.交流感情。
▲每个任务的预计时间最终由scrum master判断。
scrum会议后你的工作:
1.组织这个sprint中的需求列表；
2.安排每个需求的预期开发时间；
3.在故事页上写一个小纸条；
4.在故事页上贴一张小纸条；
5.制作一个燃尽图。
注释的改进版本，说明开发人员、任务描述、预计时间和每日耗尽时间。
故事版的布局如下:
一个标准的故事版本:开始时，所有的小笔记都在 待开发 专栏。
那个 就是它。可以开始冲刺了。
以为这就完了？天真。
接下来，你一定要来参加每天举行的项目短会。为了缩短会议时间，我们通常站着开，所以也叫 常务会议及会议。早上上班后或者晚上下班前，我们花十到十五分钟完成。
▲每日常务会
展辉都谁将出席:
1.你(项目持有人)
3.其他scrum成员
车站将做什么:
1.昨天大家都做了什么，遇到了什么问题，如何解决或寻求解决方案；
2.昨天 的完成情况。;的任务，还剩下多少时间，是否需要修正时间(增加或减少时间)，将完成的任务转移到下一个环节(从一项中撕下纸条，粘贴到下一项中)；
▲任务进行中的小纸条示例。
3.功能测试后是否有返工；
4.交流感情。
你会后的工作:
画一张烧坏图
▲冲刺的任务时间随着冲刺的进度逐渐减少。
一次又一次，在完成一次冲刺后，你召开了第二次scrum会议。这个时候题目在echo3上加了一个冲刺-@ . com ;的恢复。
任务未能完成；过度研发。ampd返工；测试需求淤积.....
讨论解决问题的方法，根据实际情况安排下一次冲刺的任务。
从此，我们在没有任何敏捷工具的帮助下，开始了敏捷之旅。
3.唐 敏捷需要文档吗？
敏捷一段时间后，产品步入正轨，项目获得资金，公司获得投资。你必须扩大团队规模。新同事想了解产品和技术细节。你告诉TA:
为什么唐 你不检查一下积压的工作吗？你想看看这个实现的代码吗？我不 我不记得这个字段是否存在...你能把包拿过来看看吗？
新同事一脸迷惑。唐 我们没有任何文件吗？你自豪地指出:
我们是一个敏捷的团队。
经过十几个人把枪的阶段，产品趋于稳定，团队逐渐扩大。无论是从内部协调还是外部沟通，对产品过程的标准化和文档化的需求越来越大。
从短期利益来看，文档对于敏捷开发来说并不是必须的，而且很可能会拖慢进度。在一次冲刺中，口头交流显然效率更高，每个人都有精确到工作时间的任务，没有人有时间等文档更新。强调文档化就等于放弃了灵活性。
从长远和宏观的角度来看，文档对于敏捷团队和敏捷实施的好处大于坏处——节省了一些标准问题上的沟通成本，降低了出错的概率。对于一个将长期实施敏捷的团队来说，文档化使得后续工作更加高效。
▲一个传播虚假信息的过程。
那么，谁来维护文档，如何维护？
我们选择其中一个重要的文档:产品文档。
产品文档:尽管PM维护backlog，与SM一起传播需求，召开scrum会议，写小笔记，召开工作站会议，绘制燃尽图，并且没有外部交流.....你应该小心保存这份文件。
▲没错，又是你。
产品文档包括:
1.需求；
2.加入日期；
3.开发版；
4.演示和详细方案。
从长远来看，文档是提高效率的好方法。利器
文件的时效性和灵活性远低于口头交流，但它有其现实的好处。
1.在空间上，文档传播得更广。标准化、常规化的内容形成文档，可以大大降低沟通成本。尤其是在多系统合作的情况下，跨scrum、跨团队甚至跨部门的沟通时有发生，文档的重要性和便捷性不言而喻。
2.随着时间的推移，文件有了更好的流通。团队不是一成不变的，有人离开，有人加入。在升级中，新人很快理解系统，而老手继承研发；ampd概念；在更长的时间跨度内，文档的存在就是产品历史的完整痕迹，不需要别人的帮助你就会知道产品的大部分外观甚至全貌。
四、如何将敏捷引入大型项目？
看来敏捷方法特别适合产品定期迭代。一种可能是你的产品需要插一个巨无霸模块，这个模块几乎可以变成产品而不是模块。你想想，这么大的项目，从产品、设计、研发到测试，完全投入也就一两个月的时间。
还能敏捷吗？
注意你的项目时间。有期限的Scrum是带着锁链跳迪斯科，时间节点和sprint的大小有关。
在一个大项目变得敏捷之前，你必须采取一些步骤来变得敏捷。
可能有一个或多个需求讨论。
团队必须努力理解需求或纠正产品经理的错误。;标准普尔天真的幻想 ，产品经理使用不断改进的原型与团队沟通。在最终评审中，项目成员和所有协作团队被邀请获得一些初步结论(例如 我们能做到吗？)除了最终确定的产品功能。
在大规模项目敏捷性中:
1.将截止日期前的时间偏差分成多次冲刺。(某 出血时间 必须在截止日期前留出，以解决时间估计不足的任务、返工任务和bug)
2.将所有需求分解成任务，召开一次全球scrum会议。估算时间后，把任务分成各种冲刺。时间紧的时候，sprint的容量也会相应增加。
▲一场需要加班的冲刺。
3.进入敏捷过程，定期scrum会议，站立会议，燃尽图，故事版本。未完成的任务将在scrum会议上重新评估，滚动到新的sprint中，以此类推(按时完成sprint中的任务是目标。真的，我们还有 出血时间 )
4.唐 别忘了文件。
虽然备受推崇，但敏捷并不是一种完美的开发方法。敏捷最大的优势是灵活性，敏捷问题的根源是灵活性。
第五，在文末总结本文的重点。
1.敏捷是一个过程，一种方法，一种理念，甚至是一种信仰。
使用敏捷管理软件不一定是敏捷的。敏捷的初衷是团队成员可以更紧密的合作来完成工作。如果线上流通削弱了这种合作，就背离了敏捷的初衷。其实只要有白板纸和笔就可以了。您的团队可以开始变得敏捷。
4.我们是敏捷的，但是我们没有。;我不想要文件。在对外交流多，世代跨度长的情况下，文档的必要性显而易见。长时间的面对面交流最终会导致效率低下，这也是敏捷缺陷的根源。
5.大型项目的开发可以采用敏捷，具体问题需要具体分析，需要根据项目的特点制定敏捷方案。