【实操演示】敏捷 & 精益开发落地指南原创

Hello，大家好，我是coding adventureenture，今天我给大家介绍基于coding项目协同的敏捷和精益实践。首先我们在敏捷里面比较经典的有SC框架，有非常重要的3355特点，即三个角色、三个弓箭、五个事件和五个价值观。那么三个角色分别色product sc masterster和开发团队。那么在coding的项目设置中，可以选择项目协同以及项目与成员里面去设置我们的成员、用户组以及对应的权限，这样就可以轻松的完成对product honor sc masterster和开发团队等角色的设置。设置完角色之后，那么我们对应到有三个弓箭，分别是我们的productga spring和产品增量。在coding的敏捷项目协同模式下。

Product law则对应着是back，那么spring bag law，那我们就需要创建出具体的迭代，然后呢，将我们的product law通过P及spring的计划会议把它纳入到迭代里面，然后呢，进入到一个开发。那么我们的需求或者说我们的用户故事可能来源于多方面，一方面是产品自身的迭代，另外一方面有可能是来自于业务客户或运营侧。那么我们当需求录入到我们的项目的时候，我们会将需求放在分隔符以下，即在待规划的未评估区域，而这种情况下的需求它是粗力度的，并且它并没有设置明确的处理人以及具体的迭代故事点，还有开始时间和截止时间等。那么随着我们对需求。

的进一步细化、细分和完善，那么我们就会把需求纳入到已规划里面，那么就可以在我们的待规划已评估里面。那么我们可以呢，第一，通过分割服务的方式去移动。随着我们对需求不断的去完善，那么我们的需求会逐逐步的纳入到以评估区域，以便于在计划会议之前能够将他们进行丰富和完善。那么在这个过程中，我们会基于高优先级驱动的方式将需求纳入到我们的以评估区域，以便将我们高优先级、高价值的需求尽快尽早的交付给客户。所以此时我们可以对纳入到已评估的需求设置它的优先级。

这里面我们可以对每一个需求设置它的优先级，默认情况下优先级为中，那么我们采用高优先级的方式去驱动，所以呢，优先级呢，我们优先会去将紧急和高的需求把它纳入到以评估区域，以便在近期中对它进行一个实现。当我们在进一步把需求纳入到高优先级的时候，其实这个过程中我们也是不断的在细化我们关于需求的一个信息的完善，这里面我们也可以添加评论相关的信息。如果对需求我们需要做进一步的细化以及协作的话，可以发起快速的腾讯会议，以便对需求进一步的沟通和完善。OK，当我们把需求已经确定好我们的优先级之后，那么我们就要基于高优先级驱动的方式，将高优先级需求纳入到已评估区域。

我们已经将所有的紧急和高优先级的需求纳入到已评估区域以及部分。中优先级的需求也纳入到已评估区域，此时这个需求经过评估之后，那么我们就需要对它进行一个近期的实现，那么意味着我们就需要去创建一个迭代。OK，我们创建迭代之后呢，其实可以看到，因为之前呢我有其他迭代，所以呢现在呢，我们是进行到1.4这个迭代，这是我刚刚创建的迭代，那么在我们迭代里面呢，我们呢，可以呢进行呢进一步的一个设置。我们可以指定迭代的负责人。我们也可以指定它的一个开始时间和截止时间，这里面我选择我们的开始时间是3月7号，那么它截止时间是一个spring的双周迭代，就固定的时间和两周，那么它将在21号结束。那么我们可以输入本次迭代的目标，例如优化商品管理模块，提升商家。

体验第二步，优化直播间功能，提升用户体验，这是我们本次迭代的目标，当我们确定这个时间之后，那么我们就可以保存，意味着我们迭代创建好了。那么我们这里面如果要从待规划到迭代，那这过程中我们就需要通过spring p及计划会议或者需求澄清会，我们会将高优先级的需求纳入到迭代里面，此时这些需求已经经过了细化，但是它并没有指定处理人和故事点，以及它的开始时间，截止时间等等。那么这个过程中，我们在纳入的迭代过程中，我们就需要将这些信息把它给补全。

在这个过程中，我们可以将视线纳入到迭代里面，这个过程都是通过我们的。计划会议实现的，在计划会议，我们可以通过发起腾讯会议的方式来进行快速的实现。当然我们也可以选择在这里面选择规划中的迭代，这样呢也是比较快一点。两种方式都可以将我们的事项纳入到迭代里面，即将我们的用户故事纳入到迭代。

当我们把事项纳入到迭代之后，可以看到本次迭代呢是有26个事项，为什么会有26个事项呢？是因为随着我们敏捷团队的进行，我们的产能生产力是相对稳定的，也就意味着我们能够做的故事点是相对固定的。那么我们这里面选择这么多事项，是因为我们知道我们的团队大约的一个产能大概是有300个故事点左右，也就是双周迭代里面，以十人的团队每一次迭代能够产生300个的故事点，所以在我们的每一个事项过程中，当我们纳入到迭代的时候，这个过程其实是我们整个团队在做我们的故事点就工作量大小的一个评估，所以呢，这里面我们会把我们的工作量进行评估，这里面我选择的是八或13个故事点来进行评估。

因为当我们要把事项纳入到迭代的时候，我们必须要能够对它进行一个故事点大小的评估，以便于我们的工作是能够尽可能的均衡的，不会过载，也不会不饱和。这里面采用的故事点的方式呢，是斐布纳气列的故事点的方式，大家可以看到后面一个数是前面两个数的之和。故事点的评估是团队共同投票的结果。除了斐布纳系列数列之外，呢科点还支持T恤码的方式来进行故事点大小的评估。一个稳定产能的团队，他们的每次迭代在固定时间和范围内的故事点的总量是相对稳定的。能够正确评估出。一个团队在迭代内的一个产能需要经过七到九次迭代，也就意味着大约需要一个季度到半年左右的时间，就能够评估出这个团队的一个稳定的产能。

OK，那我们可以看到这里面我们本次迭代共有298个故事点，就约等于我们的300个故事点，那意味着我们团队的产能是相对固定的，所以我们在进行需求澄清会的时候，我们在每一次将需求纳入到迭代的时候，都需要对它进行一个故事点大小的评估，当他已经达到我们团队产能的一个预定值的时候，我们就不能够再将需求纳入到迭代里面了，那么意味着我们的本次迭代的主要的呃任务就是完成我们这接近300个故事点下的所有的用户故事的一个开发，那么在这个过程中，我们目前已经做了故事点的一个。分配，但我们并没有指定处理人以及开始时间和截止时间。在敏捷里面，我们强调按迭代开发，按需发布，也就意味着我们创建了一个迭代之后，我们是可以进行多次部署的。按需部署的，我们可以每周或者每个独立的用户故事进行部署。所以呢，这里面我们首先需要设置的是为需求分配给具体的处理人。

这里面我统一分配给我们的QD演示账号，以便大家能够去查阅，正常情况下会分配给我们的开发团队，这个分配的过程中也是会在我们会议上来选择和指定，同时也可以由我们的开发组长来进行一个委派。整个计划会议将事项纳入到迭代，以及为每一个事项，为每一个用户故事去评估故事点大小和指定处理人都会在本次会议上进行，那整个会议的持续时间大约是二到四小时，以双周迭代就两周的一个固定时间和为例的话。

当我们把故事点和处理人都添加完之后，那么在我们迭代开始之前，我们是希望迭代能够持续、高效、渐进式的方式进行交付的，并且是用户价值拉动的方式。那么在这里面对于我们每一个需求或者用户故事的实现的顺序就变得至关重要。所以我们需要为我们的每一个需求去设置它的一个开始时间和截止时间，以便于让我们的状态流转，或者说在交付过程中速度和效率能够最大化，以及达到更可靠的稳定性和持续性。因此我们需要去设置对应的开始时间和截止时间，这里面我们的迭代是从3月7号到3月21号的，所以在这里面呢，我们呢可以呢去进行对应的设置。

为了能够稳定持续，这里面我们假设每三个需求都是在同一天开始，并且呢，每个需求它采用的是八到13个故事点，在第三天后结束，因此第一个故事点我们按顺序来设置，可以设置为从3月7号开始，截止时间是3月10号，那么这个排序也是根据我们的就要会议中对每个需求它的实现的顺序进行一个评估，由整个团队来进行确定。可以切换到我们的迭代模式下，能够去看我们的视线。这是我刚刚设置的。我们为每一个需求通过会议的方式设置开始时间和截止时间。

因为12号13号是周六周日，他不是工作日，所以我们应该是设为3月14号。顺延两天。那我们把需求的开始时间和截止时间都加入之后，或者说都经过评估之后，那么我们将进行开始迭代，那么在开始迭代的这个过程中，我们如何进行高效的项目过程管理呢？首先我们可以基于看板模式来进行高效的项目协同和管理。那么首先将看板模式之前，我们可以看到我们定义了我们的工作流，也就是说我们的价值流分别由待开发，开发中已开发，待测试，测试中已测试，待验收，已验收，待发布，已发布，还有异常带来的终止，那么在这个过程中我们可以怎么做呢？首先我们可以在。

项目设置里面进行工作流或者价值流的设置。可以选择用户故事选择工作流。刚刚看到这个工作流及我们的迭代看板也就通过此工作流进行设置的。首先我们定义了在工作流的卡片的状态，第二，我们定义了它的流转的状态，第三，我们可以在每一个状态中进行约束。也就是说对精益看板而言的五个步骤，首先就是要定义价值流。第二，显示化流程规则。那么我们可以将我们的规则包括限制步骤、权限、附加属性、更改处理人、更改属性值等规则进行强制的显示化，达到团队的一种约束和纪律，进而去提升大家协作的一致性和效率。

在这里面，我们可以在限制步骤中限制由当前步骤流转到下一步的过程中，允许什么成员或什么用户组能够执行该步骤。在。附加属性中，我们可以在状态流转的时候选择我们的属性，当然这些属性也可以进行自定义。在更改处理人中，当状态流转的时候，可以将处理人更改为指定的某个成员。在更改属性值中，在状态变更后，可以自动的修改属性的值。这样就能够达到我们基于看板的精益管理和约束，从而实现价值流动的有效性、可靠性和稳定性。当我们配置好我们的。

工作流之后，那么看到的效果就是我们在迭代中的看板视图的效果。大家可以看到，因为本次迭代为了能够更加真实，所以我选择是处于进行中的一个迭代，也就是说从3月7号开始的，那么在今天这个看板的状态是怎么样的呢？那么我们就需要通过用户价值拉动的方式把它给还原到今天的位置，一个今天的一个正确的一个显示，那么我们设置的这个时间是我们设置的截止时间，所以呢，我们会根据我们设置的开始时间和截止时间，让我们的事项尽可能的少，并且让他们的流动尽可能的快。

OK，当我们的需求已经进行到第四天的时候，那么意味着我们的部分能力是已经交付了的，这就我们说的产品增量，即按需发布。我们规划好我们的开始时间和截止时间，即每个用户故事对他进行精细化的排期管理之后，那么意味着我们就可以每天的按需发布，或者我们可以根据每个特性都可以进行一次发版，那么意味着我们每天都可以持续的进行一个发版，那么已发布需求就是我们的产品增量，那么在这个过程中，我们需要对它进行一个管理，首先要进行的就是我们的一个精益的需求的管理，那么对于需求这一块的管理，首先我们需要能够对我们的需求进行一个详细的可视化，这也是看板里面做的第一个点，就我们显示化价值流，我们可以通过定义我们的价值步骤把它显示出来。

可以看到在每一个阶段正在进行的故事点有哪一些？第二个我们定义了我们的规则，即显示化了我们的规则，要形成团队的共识和约束。在可视化价值流里面，我们是可视化了用户的价值，产品的目标是我们交付用户价值，所以呢，我们的可视化是从用户的视角来进行可视化的，同时我们可视化是端到端的一个价值流动，即从我们的需求待开发到我们的需求上线，整个过程可视化问题和瓶颈，那么我们可以通过看板这个问题来进行每日战会的时候，把我们进行的工作进行可视化，并且把问题和瓶颈暴露出来，例如我们需求不明确，技术障碍、外部依赖等等。如果我们有需求已在开发中得到了过多的一个积压，那么意味着开发。

本源此时的工作压力是非常大的，因为他们已经呃负载过重，那意味着测试人员可能处于一个等待的状态，也就意味着测试资源的闲置和浪费。所以我们通过每日战会来进行问题的检视和调整，以适应我们目标的一个达成。那么第三个点就是我们要做到控制在制品数量，也就意味着我们在规划我们需求的时候，我们需要对每一个需求，每天每个人的产能以及团队的产能进行正确的评估，然后呢，进行科学的排期，排期之后让我们的每一个列在进行过程中尽可能的稳定，并且它们的数量和大小接近于一致，这样让我们的这个流动过程才是最高效的，也就意味着如果能够匀速的、稳定的、批量的。

流动效率是最高的，所以我们需要去控制在制品数量，因为当我们某一个列里面的事项过多的时候，意味着我们这里面会造成该列的角色或者成员之间的工作负载过重，以及下游对上游这一块会造成资源的一个闲置。并且在经济里面特别强调均衡生产、匀速流动、小批量以及避免过载或资源的分配不均。那么在这里面我们就需要通过看板的方式进行我们在制品的一个限制，通过限制我们的在制品，那么可以去加速我们用户价值的流动，对产品开发的敏捷性会比较重要，同时控制在制品能够帮助团队去暴露问题和瓶颈。

例如，如果昨天应该需要发布的需求处于已验收待发布的一个状态，那么意味着我们这个需求就已经延期了，那么就可以把我们的问题的瓶颈暴露出来，然后通过五个为什么进行更新的分析，同时我们通过这制品的方式形成一个拉动机制去在精益看板里面。第四个实践通过用户价值拉动，而不是我们通过推的方式去实现我们价值的一个过程交互，而是通过拉的方式，所谓拉的方式就是由下游去拉取上游的进度，这样能够始终围绕着我们这个需求的一个最终交付的目标为导向。例如今天我们需要发布，那么我们就需要将需求将它拉入到发布的过程中。我们正在发版的话，那么我们会将我们的需求把它给进行一个发布。

这些都是在我们的需求去定义我们的开始时间和截止时间的时候，我们可以对我们的需求进行一个科学的排期。这是我们今天需要发布的需求。那么对于我们下周一需要发布需求，那么这个过程中，在我们待发布之前这一天，我们需要有哪些需求到达，那么这个时候我们就可以通过拉动的方式进行拉取，因为我们的需求都进行了一个。科学的一个排期在局部范围内，所以我们就把它进行一个拉动，这个拉动过程就是我们价值在持续流动的过程。如果我们在周一需要进行发布的时候，那么在今天他都没有处于待发布的一个状态，此时我们的发布人员或者我们的验收人员对应的负责人就去查看为什么这个需求并没有到达我们预定的今天的这个状态，那如果我们会去往前回溯测试，它会往前回溯，回溯到我们的验收人员，验收人员说目前测试没有把需求把它给诶交过来，那我们再回溯到我们的测试人员，测试人员说我们还没有收到需要测试的指令，那么这面定位到是我们的开发并没有完成这个需求，原本需要上线的需求仍然处在开发中，那么在这个过程中，我们就需要对为什么在开发中耗费了高于计划的时间。

进行一个分析，这就是我们对问题和瓶颈的暴露和分析开发。通过分析发现我们对这个需求它的评估过于理想化，也就是说我们故事点的估算不准确，现实的复杂度，需求实现复杂度远高于我们故事点，以及这个需求的一些不确定性带来了一些额外的一些负担，导致需求延期。当我们定位到开发之后，那么由发现了瓶颈之后，我们可以针对瓶颈进行修复或解决，那这个解决的过程中是需要我们团队制定好我们问题瓶颈的发现解决措施，也要去问为什么我们会评估不正确，以便于我们在评审和复盘的时候去不断的提升改进。

那么通过这种方式，我们就有效的去避免了由人员去将需求推入到下一个流程，而是由下一个流程让我们的需求能够去满足我们的进度范围，如果不满足的话，那么我们通过责任回溯的方式迅速的找到问题和瓶颈点，通过对问题和瓶颈点的分析，然后进行改进，从而达到我们的过程管理可控并且持续的提高。所以我们是以交付目标为导向的一个拉动过程，而交付的目标这个过程就是我们的用户价值为导向，而不是以我们的产业的工作过程为导向。

当处于我们这个状态的验收人员需要进行验收的时候，如果没有到达，那么将由验收人员去催促，或者说由验收人员去拉动上游，去看上游为什么没有在预期时间范围内将需求到达此处。通过这种方式，我们就实现了能够按需的、小批量的、持续的发布，这也就是敏捷里面手提上的迭代开发。我们以双周迭代为一个核心，并设立我们的迭代目标，然后团队成员对目标做出承诺，用勇气做出承诺，并且专注于迭代目标的实现，并且尊重团队和文化，能够以一种开放的心态让大家参与进来，保持透明和信任。

所以我们每日账会的时候，我们就可以在看板里面，在账会之前，我们就可以将我们的需求把它慢慢的进行一个拉动，让我们的价值或者说让我们的交付流程，让它流动起来，并且快速的去发现问题和瓶颈，那么在这个过程中，我们可能会涉及到每日账会，所以呢，在我们每一次发布的时候，我们可以批量发布，也可以按时发布，发布过程中我们都可以进行评审会议，无论是我们的每日战会、计划会议，还是评审会议和复盘会议，我们都可以基于模板的方式把它给定义出来，例如我们的计划会议，我们可以定义出我们的计划会议的一个模板，然后呢，以及参与者。第二个我们可以定义我们的每日战会的模板，我们也可以定义评审会议的模板。

以及我们回顾会议的模板，那么每个模板我们都可以选择我们模板里面具体的内容、目标以及我们的一些事项。在评审会议里面，主要是对大家工作的一个认可，以及工作价值的一个肯定，和我们工作交付量的一个成果的一个展示。评审会议和回顾会议正常情况下都会在同一天进行，或者当迭代结束的时候，如果我们是按需发布的话，那么将会在最后一次发布同时进行。那么在回顾会议里面也是我们持续改进的好机会，这也是SC里面所强调的三大基石，检视、调整和适应。那么我们可以通过回顾会议去看我们哪些目标已经达成，再去看我们哪些问题没有解决，以及产生这些问题的原因和未来将如何进行改进，这样就能够实现我们团队的一个持续改进。

所以基于SC和基于看板在coding的实践就是这些，谢谢大家。