记录下我们在敏捷开发实施中使用的一些工具，主要说下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已经顺利完成。