<br />任务板和站会可能是应用最为广泛的敏捷实践。通过任务板上卡片的移动，团队成员、管理者和客户都可以清晰地看到团队的进展。那么问题来了：<br />①任务板应该分成哪几列？划分列的原则是什么？<br />②某团队把任务板分为“To-do | Doing | Done”三列，这个分法可能带来什么问题？<br />③某团队把任务板分为“需求 | 开发 | 测试”三列，这个分法可能带来什么问题？<br /><br />在日常开发模式中，会涉及在任务板上进行工作，那么具体任务板应该如何划分呢？<br />回答这个问题之前，我的看法是任务板是由团队的实际情况决定，不是固定的。<br />往往在实际使用的过程中，我们会从下面几列中挑选或者添加：<br />backlog、Todo、doing、dev-done、ready-for-test、testing、showcase、done、pending。<br />在我的团队里，大家一开始使用了以下列：<br />backlog、Todo、doing、dev-done、ready-for-test、testing、done。<br />后续改进为：<br />backlog、Todo、doing、ready-for-test、testing、done。 <br />后续又改进为：<br />backlog、Todo、doing、pending、ready-for-test、testing、done。<br />最终只用到：<br />backlog、Todo、doing、showcase、done。<br />我的感觉是，在具体使用中，如何划分这些列要取决于：
- 和团队工作方式；
- 使用每一列的时候都需要清晰定义每一列的状态是什么；
- 如果多了或者少了某列造成了团队的问题，就应该删除或者添加；
- 将团队的实际工作可视化出来。
总的来说，我认为大的原则是，通过变动任务板上的列让团队问题尽可能可视化，做出改进，让所有人从板上看到每个卡的状态和流转情况，更好管理，尽可能反应真实情况。
至于有的leader会把任务板分为“To-do | Doing | Done三列，他的重点则在于是否能反应团队真实过程。
如果不能完整的反应卡片状态，则应更加细化。这就不应该开始就定好，而是在和团队磨合的过程中不断反馈。具体可以分为：
- 有新的需求应该放置在哪里，放置在todo中会有两个问题，是否是sprint的内容，若不是，todo中就包含了sprint中要做的和sprint之外的；
- 若需要测试，任务卡应该放在doing&done，不管放在哪里都让那一列承载了很多隐形的内容；
- 团队外的人通过看板无法知道团队的进度具体是什么样的，需要人为沟通；
- 出现pending的状态时任务卡应该如何方式；
- 每一列都无法将任务的当前状态可视化出来；
- 每一列都无法将任务卡的问题暴露出来；
总之只用三列可能会有一些规则和状态被隐藏起来。
第三种情况，留个思考题，如果把任务板分为“需求 | 开发 | 测试”三列，是不是就万事具备了呢？友情提示一下，可能存在的问题是：
1、列的职责不明确：
- “测试”没有状态，是表示可是测试的，还是侧重的，还是测试完成的；
- “开发”没有状态，是表示要开发的，开发中的，还是开发结束的；
- 需求表述的是已经可以开发的需求，还是正在分析的需求；
2、类的职责不清晰，团队在项目进行时团队的实际状态无法做到可视化。
灵魂拷问，任务板应该分成哪几列？划分列的原则是什么？你的公司是怎么做的？欢迎进群or在评论区留言，分享你的经验。
以上内容整合自【极限编程中国 | 实践者】 微信群19日（昨天）讨论，内容贡献者是：
极客学院原文链接：https://mp.weixin.qq.com/s/UfrPhhr15X0YoVWS4-aOmg
若有收获，就点个赞吧
0 人点赞
