2.迭代开发的过程是怎么样的

    敏捷开发系列文章目录

    在讨论PO如何给团队讲好故事这个问题以前，先给你们了解一些基本的敏捷概念，而后讲讲咱们敏捷团队构成与整个敏捷开发的过程。

 

    当初敏捷老师讲课的时候就跟咱们所过，敏捷没有什么具体的形式，每一个敏捷团队可能作法都不同，表现出来的性格也不同，好比有挑战型团队、有保守型团队等。但敏捷有一个核心是不能变的，这个核心就是3355。

一、3个角色：SM、PO、开发团队（天然包括了咱们的开发人员和QA）。
二、3个产出物：Product Backlog、Sprint Backlog、交互的可用软件工件。
三、5个活动：计划会、sprint评审会、回顾会、每日立会、Product Backlog的梳理（发生在整个SCRUM周期的任什么时候间）。每个会议都有本身的时间盒，其长短在SCRUM中都有比较明确的建议。当你召开某一个会议的时候，超出了这个时间盒或者召开某个会议的时候出现一些问题，也是一种有问题的信号。一个团队在冲刺的周期内，去充分的暴露问题，而后在回顾会上去分析问题，再进行改进。在每日立会上比较强调的是，根据昨天完成的状况来作出新的调整，咱们每日立会上所描述的，必定是对有助于完成当前sprint目标的事情。同时，特别须要强调的是，在sprint评审会上，团队除了对当前sprint完成的故事进行show case还须要对剩余的任务卡进行梳理，可让团队有机会去回顾和识别版本发布的风险。
四、5个价值观：公开、专一、勇气、承诺、尊重。
    另外，还讲到了SCRUM最重要的时间盒，这个是我以前所理解的SCRUM里面，没有发现它居然是如此重要的。还学到一个新的理论：番茄工做法是一我的的SCRUM，SCRUM是一群人的番茄工做法；理解到跨职能是团队层面的概念，而一专多能是每一个团队成员层面的概念。如今回过头来看，发现曾经团队在尝试SCRUM的过程当中，对有些方面是理解得不够的，包括为何最终团队放弃了SCRUM转向看板，其原因也不彻底是曾经觉得的迭代周期的问题，须要系统的来看待这个问题。无论一套理论是如何的完善，结合到实际的工做中的时候总会遇到这样和那样的问题，但抓住最本质的东西才是最重要的，抓住其精髓的部分，而后再加以灵活应用，以问题为出发点，可以真正的解决实际的问题才能给你们带来信心。

 

    我所在的团队有11我的，1个PO（也就是我本身），1个SM（他有兼职好几个团队的SM），6个开发和3个测试，这算是一个比较大的敏捷团队了，通常6,7我的一个团队刚恰好。而后咱们团队开始开发一个系统，固然这个系统在分配到咱们团队以前在公司是已经立过项的，有一个基本的PRD文档，架构设计也都已经肯定下来（咱们作应用系统的架构通常比较固定）。这时候我就会把全部的需求整成一个故事地图，而后根据故事的紧急程序会把故事放到对应的Product Backlog，而后请求开发团队对这些故事作一个简单的估算，好让我知道这些故事大概须要多少个迭代完成。迭代开始，PO拿出第一个迭代的故事给到团队，咱们一个迭代是2个星期，10个工做日，通常第1个工做日开迭代计划，最后一个工做日作集成测试和迭代回顾，因此一个迭代真正作事的时间只有8个工做日。迭代第一天由产品经理给团队讲故事，而后团队对故事进行估点，这个通常都花费好几个小时，重点就是团队全部人都搞清楚这些故事有一些什么东西，再接着就是团队成员自由领用本身的故事，而后对本身的故事拆分任务排计划，这天最后团队一块儿给出一个本次迭代完成的信用值，信用值从1-5,5表示本次迭代确定完成，4表示努力一把仍是可以完成的，3表示可能加班才有可能完成，2表示加班都有可能完不能，1表示怎么搞都完不成。

    通常开迭代计划会以前PO会把本次迭代的故事都会提早发给团队，让你们都提早熟悉一下故事，这样能够速缩短迭代计划会的时间。开完迭代会次日不会立刻就开始动手编码，通常上午会开设计评审和测试用例评审两个会议，开发人员设计的产出包含用例图、概要类图、数据库表结构和界面原型，设计评审就是对这些东西就行讨论。测试人员编写的测试用例，开发人员参与评审，就是验证测试理解的功能实现与开发想的是否同样，与PO想表达的是否同样。

    评审以前开发人员能够准备一些资料，最好用图来表达本身的设计思路，没必要编写一个什么设计文档来应付评审。接下来就能够进入编码实现阶段，天天早上准时开每日站会，大概10分钟，由SM组织，简要说明一下今天要作的任务，有什么困难增强团队的沟通协助。迭代过程当中最重要的一张图就是燃尽图，基本上每一个人都会关注，若是发现这张图降低得不正常，那么SM通常就会找出问题并进行干预。第一周周五的下午会组织一次代码走读，而后迭代完成的前一天会再进行一次代码走读。而后全部故事开发完成后，测试进入集成测试。集成测试完以后，测试会给出一个DI值，这个值的大小会决定本次迭代的成功或失败。而后开sprint评审会，由PO来验收本次迭代的成果。接下来就是最重要的迭代回顾会了，回顾会中全体成员总结本次迭代遇到的问题，以及解决方法，还有团队好的方面也要记录并保持下去，还会对以前迭代制定的解决方法进行回顾是否有用。

    最后回顾会议中还会评出本次迭代的迭代之星，表扬表现最突出的成员，迭代之星最后会得到团队提供的一些小礼物。而后下周继续开始下一个迭代。

    PO对产品负责，开发团队敢于对本身承诺的故事，SM是团队的保护伞。

    敏捷开发系列文章目录