来源：CSDN
原文：https://blog.csdn.net/andy_5826_liu/article/details/88889359
记录下我们在敏捷开发实施中使用的一些工具，主要说下leangoo
工具不是敏捷开发及Scrum的必须品，但有了工具，可以让敏捷开发更好的实施。
因为篇幅及时间问题，这里先说下 Leangoo：
关于leangoo，我想讲的主要有三张图，PO的Product Backlog、Team的Sprint Backlog及Sprint的燃尽图。
Product Backlog
以下是我们PO使用的Product Backlog，基本与leangoo的示例一致，这个示例也是满足软件开发过程的。
PO-Product Backlog.jpg
这是一张PO的Product Backlog（如果看不清，可以放大），需要注意的都已经用红色标注：
1. 待梳理需求
PO从用户（包含领导、客户、自己）得到的需求，肯定是不完善的，大多都是需要做一个什么功能之类的“一句话需求”，对开发团队而言，这些都是不可执行的；但是PO可能也不能及时进行梳理，所以先把这种“一句话需求”放入该列记录起来。
2. 以后的Sprint
这些都是PO已经梳理了，可执行的需求，我们称之为Story（故事），一般这一列都是紧急度不是非常高，但是在后续需要做的。从这一列起，任务是带有时间点数的，这里一般是PO估算的大概点数，与迭代中团队估计的点数可能有差别，但是随着团队的默契度上升，这个点数应该能与团队评估点数越来越接近。
3. 下个Sprint
这些一般来自于“以后的Sprint”一列，是可执行的，而且紧急度较高的（紧急度由PO根据需求来源、商业价值、工作量等因素进行确定），而且这一列的Story都应该是紧急度排好序的，越往上越紧急。PO大概评估，这一列的Story点数一般略高于团队能完成的点数。这一列的Story需要PO在当前迭代开始准备，在迭代结束前整理好，这样才能让迭代不会中断。
4. 当前Sprint
这一列是当前迭代进行的Story，原则上是不允许替换的，除非是特别紧急的任务。这一列开始，Story的任务点数可以换为与团队评估的时间点数一致。
5. 已交付
这一列是已经交付的Story，是一些已经通过PO验收，已经上线或者随时可以上线的Story。
leangoo上主要的两张Backlog，PO一个人就需要维护一张，可见，在Scrum迭代中，PO处于一个能决定迭代成败的绝对核心位置，PO的任务及责任都是非常重的。
Team的Sprint Backlog
下图是我们团队的Sprint Backlog，这个需要整个团队都主动去维护，每天完成的Task和Story都主动去拖动。
Team-Sprint Backlog.png
这个Backlog我们与示例一些差别，我们分为了六列，这样更适用于软件开发，这哥Backlog一般在迭代的第一天（迭代启动会后）生成：
1. Story
这个很好理解，迭代中需要完成的故事，在故事都是标记好点数，标记好晚上时间，并标记好负责人的，而且每一个Story都应当有检验项供测试及PO验收。
2. Task
对应的Story拆分为可以执行的且短时间内可完成的小任务，每一个Task都有完成时间和负责人，这些Task都是待执行的状态。
3. Task-doing
Task的执行当天，负责人将该Task从Task列拖到Task-doing列，表示该Task正在处理。
4. Task-done
Task完成后，由负责人将Task拖入该列。
5. Story-testing
当该Story对应的所有Task都完成后，将该Story拖入Story-testing列，测试人员开始进行测试工作。
6. Story-done
当测试人员完成测试后，将Story拖入该列，表示该Story已经顺利完成。
一个迭代会有很多的Story，我们每个开发人员都会建立一个泳道，然后将自己的Story拖入泳道中（也有的团队是每个Story一个独立的泳道，这个看自己的需求情况而定）；在Task及Story完成后，团队成员需要主动、及时的拖动Task和Story，不然对应Task或Story会变为红色，而且整个Sprint对应的燃尽图会变得很怪异；在迭代的第一天，应该讲Story拆分为Task，并且Story完成时间不能标记到迭代的最后一天（最后一天应该是产品验收会及迭代总结会），开发Task完成时间不能标记到迭代的最后两天（给测试预留时间，并且需要进行回归测试）；在迭代正式开始后，Story和Task应该是不变的，不然很难保证迭代的顺利进行；
燃尽图
燃尽图是基于Sprint Backlog的，以下是一个迭代的燃尽图示例：
燃尽图.jpg
燃尽图能反馈一个迭代任务周期内的整体进度，一般这个图由SM来管理及分析，如果发现燃尽图偏离参考值，则应该考虑具体原因：在上方则应该询问团队是否出现无法解决的阻碍；如果在下方，则迭代式朝着良好的方向走着，如果下方偏离过多，则表示该团队这个团队战斗力有所提升，可以接受更多的Story。
以上是 Leangoo 中，我认为最重要的三个图表，这些做好了，可以让迭代更好的进行，迭代的执行更清晰，在迭代管理上也更轻松。