项目立项之后，我们会把项目看板分成待定需求，待分配需求 每周迭代 等待测试 bug 准备发布 已经发布等几个阶段。任务在不同的阶段进行流动，一目了然。
在计划会议之前，就需要把一些工作进行拆分，在计划会议上进行讨论沟通，落实到每周，至少落实好一周的工作量。
以下是我们常用的项目看板结构，不同的项目略微会有所不同。比如有些项目会有挂起阶段。
待定需求：这个里面是一些模糊的需求，需要去确定的需求。什么需求算模糊的需求？业务目的不清晰，业务场景不清晰，没有原型，没有设计稿，没有交互，需求不清晰，就不能让开发去动手开始开发。如果只是部分需求清晰，开发可以考虑先准备好一些公用的方法或者文件的结构。
待分配需求：这里是已经确定的需求，在会议上要一次性分配给相关的负责人，不要担心负责人记不住，既然已经写下来了，也已经沟通过了，记不住就反复多看几遍，肯定会记住的。
每周迭代：比如每周迭代7.20-7.26.后面要带着时间段，否则根本不知道上周做了什么？本周需要做什么？这里都是确定的需求或者功能点。按照模块进行推进，所有的需求都放在相关的模块下。但是这样也会有问题，会导致任务不好从当前阶段拖到下一个阶段。比如拖动到测试阶段，因为一个模块下面有很多人的工作。但是如果把模块的功能点进行拆分，又会导致太零散，将来不能对这个模块有整体的认识。这个地方比较矛盾，还需要不断的尝试。第一周的迭代里一定要加上一个准备工作，准备工作包括比如svn或者git的搭建，演示地址的配置等。
等待测试：当一个任务完成之后，拖到等待测试阶段。负责测试的同事重点就是针对这里的任务开展相关的测试。测试不需要后面写上时间段，无论是哪一周的任务，只要完成了，都可以放入到等待测试阶段。等待测试阶段每周都需要测试完毕。
bug：测试的模块如果有问题，就拖放到bug阶段。在会议上重新分配，bug必须当天解决掉。解决完的bug，重新放入等待测试中供测试的同事进行测试。
准备发布：测试完毕，没有问题的功能会拖到准备发布阶段。评审会议就可以对照准备发布阶段的任务进行演示和交流，没有问题了，就可以发布。发布完之后，将任务拖到已经发布阶段。准备发布的模块要进行全员测试，发挥每个人的力量，努力提高产品质量。
已经发布：这里是已经发布的模块，如果模块有新的问题，比如改动了其他模块导致已经发布的模块不好用了，就需要重新放入相关的阶段里。完成的任务不要去点击完成，放到已经发布里更加清晰，能够一目了然的看到哪些模块已经发布了。
学习总结：过程中遇到的问题，学习到的知识点，就可以记录到这里，分享知识，共同进步。
几个小技巧：
1 项目看板里混合着所有人的任务，通过过滤可以只查看和自己有关的任务。
2 需求的思考点，问题，参考资料等，统统录入到相关的模块下面。
3 评审会议一定要邀请客户参加，让客户知道每周的推进结果。
我们不能让工具绑架，工具一定要简单，handone要保持简洁易用，以客户的需求为中心进行迭代开发，有很多不必要的KPI考核统统去掉，要以价值考核做为核心，比如，很多公司喜欢统计bug的数量来考核开发人员，我觉得完全没必要，我们要相信没有人喜欢bug，没有人会故意制造bug，价值考核已经完全可以体现出问题所在。
