Scrum手语之看板管理

为何一定要用传统墙上看板？

看板，乍一眼看上去像是上个世纪的产物，和当下信息化的潮流不太应景。无非是工作的跟踪与管理，相关的产品不再少数。但是这种传统的纸质看板无可替代，整个团队簇拥在一起为了共同的目标而激烈地讨论，众目睽睽下拖动任务卡片，这种议题结果达成的感觉是一个人闷头在电脑前动动鼠标无法比拟的。在看板前，即使隐匿再深的问题也可以暴露无遗。看板不仅仅可以追踪迭代，同样可以总结与计划。
看板通常由以下几个模块组成：Idea，表示尚在构思的需求；Backlog表示已经分析后的需求；Next，细化Backlog可以进入迭代内的任务；Develop，开发的工作；Test，测试的工作；Deploy：部署上线。
在实际迭代中会发现如下问题：1.任务由于特殊原因需要个签，如业务临时暂停；2.任务由于不可抗力而取消。故而看板除Idea、Backlog、Next、Develop、Test、Deploy外，再增加Pennding、Waste列，表示挂起和废弃。
细化任务看板，Develop & Test都需要细化为Todo、Doing、Done，以细化表示开发和测试。
何时才可挪动看板？如Backlog如何可以进入Next？Next如何进入Develop？开发本地完成了编码就可以直接放入Test吗？可见在每个环节需要Define of Done。
Backlog进入Next前，需要产品经理、测试和相关开发人员，一起就用户故事做细致的拆分。起码对业务理解达成共识，进一步对架构的设计达成一致，定义好数据库结构及接口。细致到可以着手开发的地步。---磨刀焉误砍柴功？把大部分开发和产品、测试之间可能存在的分歧在萌芽处解决。这样前提下写出的测试用例文档，往往更加准确。
Develop进入Test前，需要junit自测完成。并且邀请review代码，review代码通常从junit和业务点的对应性开始。之后需要配置测试环境，包括数据库准备、配置文件准备，缺少任何一项，都不能叫做开发完成。
测试到部署上线，同样需要的checklist检查，缺一不可。严格规范每个环节，可以避免很多没必要的沟通，如开始测试时bug是由于缺失测试环境的表结构，上线发布后才发现配置文件忘记了修改等。