敏捷之看板文化

1.序言

                            谈到敏捷模式就肯定得先说下瀑布模式

瀑布模式：瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。
那么传统的瀑布模式虽然能够很好的保证产品的质量，但是由于产品研发各阶段较为耗时，一般会有很长的开发周期，开发周期越久，不可控的因素和风险就越大，最终的结果就越容易偏离最初想法。与此同时，瀑布式开发还存在需求变更灵活度差的缺点，开发过程中不可抗拒的需求变更会对开发的架构、交付日期有非常大的影响，经常出现一个变更导致前3个月甚至更久的工作返工白做，浪费的成本是非常大的。
说了瀑布那么多缺点那就引入我们的敏捷模式，这里对敏捷模式就不做太多的介绍，后面会专门介绍敏捷相关文化，毕竟敏捷文化博大精深，不是一点点东西能讲清楚的。
这里就先讲敏捷的一个重要媒介—看板

看板文化

1．看板功能介绍

1. 看板是敏捷开发的重要载体，看板上用任务卡片（便签纸）将每个人的任务，以对应的状态展示出来，目的是做迭代进展可视化跟踪和协作沟通。看板（Kanban）开发方法是近年来最热门的敏捷和精益开发方法。越来越多的案例表明，它能够改善协作、优化管理，显著提高交付速度、质量和灵活性。看板开发方法的规则简单，但其有效实施依赖于对原理的理解、对原则的坚持和实践的应变。
   通常的软件开发项目组使用时分为，需求池、开发、测试、上线；也可以根据自己项目的特性来进行调整

   

2. 需求区划分为2个迭代周期，每个迭代周期我们定为2周（按照每个项目实际规划的敏捷迭代周期来，常见为2周）。将评估得出的用户故事写在任务卡片上，每个任务卡片将根据组员完成情况在需求设计、编码、测试几个阶段进行移动。
   事项区分为ToDo和Doing，顾名思义就是等待开发的任务和正在开发的任务，任务卡片从ToDo区向Doing区进行移动，可以清晰的展示出项目的进展情况。我们对于已经走完整个流程的功能（Done）并没有体现看板上，而是对其进行整理归档。
   除了以上两个区域，我们还设置了最近关注点和堵塞事项。最近关注点可以提醒我们近期需要注意的项目排期，帮助组员规划时间，调整开发进度。堵塞事项可以是因协调其他系统造成的堵塞，也可以是由于具体技术问题造成的阻塞等等，针对堵塞事项，我们会尽快协调解决，并在回顾会议进行分析，为之后的迭代做出调整。

2.看板的使用

1. 将物理看板至于工作区内，作为团队工作可视化的重要媒介，使团队成员能够清晰地把控工作进度，对项目敏捷开发起到了良好的管理与推进作用。围绕着看板，我们在迭代周期内会组织会议，分别是需求评审会、每日站会以及迭代回顾会。
2. 需求评审会，它的主要目的是做好本次迭代的需求分析、评估工作量、下发任务。会议上，组内成员需要明确清晰的迭代目标、澄清所有的需求及技术实现风险、划分用户故事（可以简单的理解为功能点）、评估工作量、确定交付时间点，为每位组员分配工作量，将评估的用户故事写在任务卡片上，贴到看板的需求设计区和事项toDo区。需求评审会上我们要求所有人对需求完全了解，并达成一致的认可。开发过程中及时沟通，组员应确保对功能的正确理解。

3. 整个迭代周期里，我们都会开展每日站会。每日站会，顾名思义，就是站着开会，大家围绕看板成半圈，这样做有两个目的，一个是高效，另一个是可以方便团队所有人都可以看见对方。站会上，由每个成员说明自己任务卡片的开发进展情况，发言主要围绕三个问题：昨天完成情况，目前有什么困难，今天的任务。之后组员根据实际情况移动任务卡片到对应的区域。站会可以监督个组内成员是否完成昨日的目标，对于未完成的部分，需要说明原因，若遇到技术问题，可在站会上及时进行讨论，这样可以培养成员的责任感，并在发生延期的时候，造成一定的压力，提高开发效率。另外，从看板的每日变化使项目进展情况一目了然，有利于团队及时调整开发速度，组内成员可以非常清楚的了解上下游任务完成情况，对互相可能产生影响的用户故事的开发进行沟通。看板前的每日站会不断更新物理看板上需求和故事的完成情况，团队视具体情况快速做出调整，整个过程使团队沟通更加快捷，思维更加活跃，合作更加紧密。
4. 在迭代周期的最后我们会开展迭代回顾会，会议主要是回顾此次迭代的整体情况，对完成的任务进行整理归档，对堵塞事项分析原因，保持此次迭代做的好的地方，对遇到的问题提出改进措施，不断探索更加适合项目组的敏捷开发模式。

3.看板使用注意事项

1. 用户故事的划分与工作量的评估
   看板是有一张张卡片拼接而成的，每张卡片都是一个任务。每个任务都有自己的生命周期，优先级，处理人，工作量，这就涉及到用户故事的拆分。
   用户故事拆解的粒度是很抽象的问题，很难用定量的指标进行描述，我们一般将其定为团队一个开发人员平均可以在1-2天内完成的工作内容。需求评审会上我们工作量这样进行评估：我们首先定义一个基准故事，基准故事一般选择比较简单又具有代表性的故事，比如我们可以将查询用户信息作为一个基准故事，它可以让每个组员一看就知道大概这个基准故事需要花费多久时间，基准故事作为故事点能够让组员清晰的评估每个用户故事所代表的工作量，每个组员对本次迭代的用户故事进行评估，将结果拿出来讨论，故事点评估差异较大的同事说明评估理由，评估少的可能是没有考虑到深层的工作，评估多的可能是将问题复杂化了，通过这样的讨论可以帮助组员更加细致全面的理解开发任务。用户故事评估之后，组员根据自己擅长的领域与技能去认领故事，我们主张主动认领，但是为了平衡团队，在这之后还需要项目经理进行适当的调整，以维持好团队氛围。
2. 如何保证敏捷开发的产品质量
   敏捷迭代中持续集成非常重，敏捷迭开发虽然能够让每个人专注在开发用户故事，充分调用组内成员的积极性，让任务能够在最短的时间完成并上线，功能上线并不意味着任务的完成，我们需要保证产品的质量，不能在生产上出现致命的bug。我们认为持续集成能够更好的解决这个问题，在迭代周期的后半程我们将本次迭代的功能代码提交测试版本给测试人员进行迭代内测试，经过了静态代码复查、单元测试、构建和自动化功能测试这么多持续集成阶段后，我们更加自信，也保证了产品的质量

4.物理看板还是电子看板？

无可厚非，敏捷项目的最终成败与看板本身是物理的还是电子的没有直接关系。所以本文不是讨论敏捷项目的成败，而是讨论：如果你用了看板，那么哪种看板更适合你？

物理看板的优势:
物理看板在一定的历史背景下确实发挥了很大的作用，大部分的敏捷教练一开始也是推荐物理看板

1. 启动快

只要团队统一意见，立刻就可以找一片“根据地”，花10分钟就可以布置好物理看板，立刻就可以把相关工作可视化。

2. 成本低

物理看板几乎不需要建设和维护成本，简单一点在某个墙上贴一些泳道条，买一些即时贴即可。100元能运行几个月。

3. 变动容易

团队刚刚开始导入敏捷，导入看板，在没有充分实践的情况下，极有可能会对看板进行变动，如：细分流程,增加“编码完成”。在物理看板上画2分钟即可完成。

物理看板的劣势:

1. 没有历史数据的沉淀，缺乏整体性

看板协助团队实施当前迭代，但是对于之前迭代的相关信息没有有效利用，使敏捷相关信息失去规模性、整体性。另一方面，质量管理人员可能因为缺少历史数据,

而逐步失去客观质量分析评价。

2. 管理层不容易看到、不容易看懂

特别是有地理区域限制的管理层，他们看不到团队的计划和进度；即使走到看板前，也仅仅是看到当前迭代的信息，没有了解到相关管理信息，如：趋势、风险等等。

这无形中会逐步失去管理层的支持。

电子看板的优势:
随着科技越来越发达，显示器成本的持续下降，电子看板越来越被企业所接受并应用。

这里所说的电子看板不是一套简单的传统的工作管理平台，而是需要充分继承物理看板的优势，并弥补物理看板的逆势的看板。具体讲它是：

1. 完全基于敏捷思想而设计的；

2. 方便团队操作的，无须复杂培训的；

3. 可以根据具体实践情况，灵活变动的；

4. 可以基于之前看板数据，智能分析，并提升团队操作效率的；

5. 可以自动根据团队操作，生成各种管理报告的；

6. 可以和组织其他系统无缝结合的