开放原子开发者工作坊

       互联网时代是多变的时代，小步快跑、快速迭代可以让我们聚焦最有价值的需求，以最小的代价去适应变化，而背后的原则就是敏捷。

       敏捷可以理解为一组原则与价值观，我理解主要有三点：

1.   强调尽早并持续交付可执行的产品

2.    强调产出的价值 

3.   强调人与人的沟通协作

       实现敏捷原则的方法有很多，比如Scrum、XP、看板、精益等，可以根据实际情况进行选择。其中Scrum的使用率相对较高。

      Scrum简介

      Scrum简单来说就是拆分产品、拆分团队、拆分时间。将一个需要较长时间、功能较多的版本，按功能优先级拆分成短时间实现较少功能的若干版本，保证可用产品快速上线验证。同时，团队为了更高效的沟通，理想状态中也打破传统产品、设计、开发、测试的团队横向分割，而是将人员进行纵向分割成若干小团队，每个小团队中包含了产品、设计、开发、测试等各岗位同学。

      Scrum的主要开发流程由一个Product Backlog开始，这个文档可以理解为一个按优先级排列的需求池，需求池可根据实际情况变化。每一次迭代称为一个Sprint，时间一般在2-4周，每个Sprint会从Product Backlog中取出排在前面的若干需求，组成本次迭代的Sprint Backlog，确定本期迭代功能。然后通过一个2-4周的Sprint，输出一个可用版本，供老大或市场验收。同时对之前的Sprint进行回顾总结，将问题记录并改进，再从不断变动的Product Backlog中抽取优先级高的内容开始下个Sprint。

       Scrum框架的3个角色

       Scrum框架中的主要角色有三个：Product Owner、Scrum Master、团队。

       Product owner是产品的主要负责人，定义产品的愿景与方向，决定Product Backlog的内容及优先级，拍板各种问题，并为最终产出负责。在实际情况中，Product Owner可能是部门老大或者负责业务的产品经理，要与整个团队在一起。

       Scrum Master像是项目经理，对开发流程与生产力负责，控制项目节奏，通过合理排期、使用高效辅助工具、召集成员解决重要问题、组织聚餐等各种方式提高团队凝聚力和效率，保证团队按计划完成任务。

        其余人员均为团队成员，主要的任务就是实现自身的价值，在自我高效的前提下尽可能与其它成员良好沟通协作，共同完成目标。

        我们这一次团队合作共有6个人，负责人龙啸宇，控制人张宇辉，成员黄婧婧，刘琴，王彤，龚雪莉分别负责反馈，沟通，测试，建模。

        Scrum框架的3个文档

        Scrum框架中的主要角色有三个：Product Backlog、Sprint Backlog、任务板。

        Product Backlog是待开发功能列表，也就是需求池，特点如下：

1.   按优先级排序，可根据实际情况动态维护。

2.   内容来源可以集思广益，但新增、删除或排序更改等变动，只由Product Owner负责修改。

3.    由于需求池内容较多，优先级靠后的功能往往需要等待很久才能做，做的时候需求又可能产生变化，所以高优先级的需求会更加细化，而低优先级的需求往往粒度较粗。

4.    Product Backlog内容一般是一个个的用户故事，由Product Owner完成。

        Sprint Backlog是团队承诺在一个Sprint内应该完成的用户故事，特点如下：

1.   来源于Product Backlog优先级最高的几个用户故事。

2.   承诺由团队根据Sprint时间及用户故事复杂程度估算后给出，而不是由Product Backlog一人拍板决定。

      任务板上是Sprint Backlog中用户故事进一步拆分而成的任务，每个任务代表开发同学要完成的内容，特点如下：

1.   任务板依然按照用户故事的优先级排序，优先级最高的用户故事拆分出的任务排在最上方。

2.   任务状态为：未开始、进行中、被阻碍、已完成。

3.   每日的站会对任务板进行更新，任务板公示，团队成员随时可见。

4.   理想状态下，优先级高的任务应优先进入已完成状态，优先级低的任务处于未开始或进行中，而不是全部任务均同时处于进行中状态。

       成员确定后，这次的项目为大学圈

      项目导图：

      Scrum框架的5个活动

      计划会

      类似需求评审，时间为Sprint的第一天。按照Backlog的优先级，与团队成员初步确定本期的Sprintlog，经过用户故事拆分和估算后，给出最终的承诺，锁定本期功能。从实际情况来看，一般计划会会包含了需求、交互与视觉，评估的时间一般也会延后1-2个工作日给出。

      每日站会

      每日准时开始，事先约定迟到者惩罚措施，15分钟内结束，把控会议节奏。

      Product Backlog梳理

      对于周期为两周的Sprint，在第一个周五进行Product Backlog梳理，主要是调整优先级，澄清并细化需求，预先为后续的2-3个Sprint做准备。一般来说，进行Backlog梳理时应该已基本确定下个Sprint完成大致需求的交互，视觉可在此时间点介入，利用第二周完成视觉，从而在下个Sprint的计划会时直接可用视觉稿进行评审与估算，避免开发等待设计的时间。

      演示

      Sprint的最后一天向老板/用户演示产品新功能并收集反馈，保持演示流程的简单，不要因演示增加过多额外工作。实际情况中，最后一天往往是上线日，在这一天完成上线并等待用户反馈。也可以为了避免周五上线，而将上线日移到周一，从每周二开始Sprint。

     回顾会

     完成验收或上线后，团队对上一个Sprint中出现的问题进行回顾，对事不对人，对于需保持、需改进的问题进行梳理并找到解决方案，在下个Sprint中开始执行。

      Scrum小结、

      上述内容基本就是Scrum的相关要点，听上去很简单，但实际落地过程中一定会有非常多的问题。比如是否能挡住来自各方的需求、Sprint过程中可能出现各种未预期到的问题、比如计划会的评审中出现未考虑到的问题导致视觉需要返工等等，只能在不断磨合和优化中去将这个方法理念融入自己的团队。