加载中…敏捷开发-Scrum学习记录
(2015-09-15 00:40:23)
标签：
it敏捷敏捷开发scrum产品 |
分类： 项目管理 |
上周五参加了公司组织的敏捷开发零基础培训，一下午的时间感觉还是收获颇丰，简单跟大家分享一下，也算自己做个记录。
敏捷开发
互联网时代是多变的时代，小步快跑、快速迭代可以让我们聚焦最有价值的需求，以最小的代价去适应变化，而背后的原则就是敏捷。
敏捷可以理解为一组原则与价值观，我理解主要有三点：
1.
产品可用是衡量进度的主要指标，只有在短周期中产出可用的产品，才能迅速收集反馈，以最小代价灵活应对可能的变化。
2.
在快速产出的前提下，更要求产出的高价值，这对需求管理提出了更高要求，确定好优先级，只做最重要的，精简掉一切不必要工作。
3.
团队成员的高效沟通优于流程和文档，无论是团队结构还是座位划分，均以促进同团队成员高效沟通，降低沟通成本为目标。
实现敏捷原则的方法有很多，比如Scrum、XP、看板、精益等，可以根据实际情况进行选择。其中Scrum的使用率相对较高，后面会着重介绍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像是项目经理，对开发流程与生产力负责，控制项目节奏，通过合理排期、使用高效辅助工具、召集成员解决重要问题、组织聚餐等各种方式提高团队凝聚力和效率，保证团队按计划完成任务。
其余人员均为团队成员，主要的任务就是实现自身的价值，在自我高效的前提下尽可能与其它成员良好沟通协作，共同完成目标。
Scrum框架的3个文档
Scrum框架中的主要角色有三个：Product Backlog、Sprint Backlog、任务板。
Product Backlog是待开发功能列表，也就是需求池，特点如下：
1.
2.
3.
4.
5.
Sprint Backlog是团队承诺在一个Sprint内应该完成的用户故事，特点如下：
1.
2.
任务板上是Sprint Backlog中用户故事进一步拆分而成的任务，每个任务代表开发同学要完成的内容，特点如下：
1.
2.
3.
4.
Scrum框架的5个活动
计划会
类似需求评审，时间为Sprint的第一天。按照Backlog的优先级，与团队成员初步确定本期的Sprintlog，经过用户故事拆分和估算后，给出最终的承诺，锁定本期功能。从实际情况来看，一般计划会会包含了需求、交互与视觉，评估的时间一般也会延后1-2个工作日给出。
每日站会
每日准时开始，事先约定迟到者惩罚措施，15分钟内结束，把控会议节奏。会议只允许回答3个问题，其余问题线下沟通：
（1）
（2）
（3）
Product Backlog梳理
对于周期为两周的Sprint，在第一个周五进行Product Backlog梳理，主要是调整优先级，澄清并细化需求，预先为后续的2-3个Sprint做准备。一般来说，进行Backlog梳理时应该已基本确定下个Sprint完成大致需求的交互，视觉可在此时间点介入，利用第二周完成视觉，从而在下个Sprint的计划会时直接可用视觉稿进行评审与估算，避免开发等待设计的时间。
演示
Sprint的最后一天向老板/用户演示产品新功能并收集反馈，保持演示流程的简单，不要因演示增加过多额外工作。实际情况中，最后一天往往是上线日，在这一天完成上线并等待用户反馈。也可以为了避免周五上线，而将上线日移到周一，从每周二开始Sprint。
回顾会
完成验收或上线后，团队对上一个Sprint中出现的问题进行回顾，对事不对人，对于需保持、需改进的问题进行梳理并找到解决方案，在下个Sprint中开始执行。
Scrum小结
上述内容基本就是Scrum的相关要点，听上去很简单，但实际落地过程中一定会有非常多的问题。比如是否能挡住来自各方的需求、Sprint过程中可能出现各种未预期到的问题、比如计划会的评审中出现未考虑到的问题导致视觉需要返工等等，只能在不断磨合和优化中去将这个方法理念融入自己的团队。不必要完全拷贝Scrum的每个细节，适当根据自己团队进行优化也是非常合理的。
工作反思
回到目前的实际工作，小版本往往需要一个月左右，而大版本则可能达到两个月甚至更长，想想原因，大概也是三点：
1．
经常拼命给一个版本里塞功能，希望尽可能完成更多功能，尽可能提高用户体验，但实际上缺乏对于需求价值的梳理，铺了很多价值一般的功能导致版本臃肿。
2．
即上个版本需求确定进入开发阶段后，产品忙于确认一些未想到的细节或处理其它紧急事情，没有及时确定下个版本的需求，导致上一版本上线后，产品与设计还在确定下个版本的内容，而开发同学处于空闲状态，引起时间浪费。
3．
一个问题可能涉及iOS\Android\H5等多个终端，如果一端改动未能同步其它端，往往会引发更多问题导致重复开发。
其中问题2已经着手改进，产品与设计前置，与上个版本开发并行，所以近两个版本基本是上个版本上线，立即可以进行视觉评审，不浪费开发同学时间。问题3也有所改善，每次有改动时拉着各端相关同学及测试一起过一下，同时在原始需求中也考虑清楚三端因实现逻辑不同而不同步的情况。
但最重要的问题1依然做得不好，经常由于控制不好导致需求膨胀。刚入职时会抱怨有些功能挺简单，为啥不在这个版本赶紧加上，非得等到下一版，现在慢慢理解了，如果需求一直膨胀，这个版本永远也上不了线，更别提快速看效果看反馈了。理想中就是版本周期尽可能段短些，这样有任何新变化能快速反应，对于拥抱变化的业务这非常重要。
小结
敏捷开发的培训，学习敏捷的概念及Scrum框架是个很大的收获，同时也让我对需求梳理有了进一步认识：
1.
2.
3.
4.
整体来看，敏捷开发对于产品与整个团队都提出了更高的要求，但这也符合互联网时代多变的节奏。快迭代、强调价值、重效率，运用在各个团队会有不同的反应。现在我也只是纯理论上的记录，后面会逐渐在工作中将这个思路落地，有了更深的体验或更多的问题，再写出来与大家分享，应该会更有价值！
ps. 可以关注微信公众号“产品新人小白”，会持续更新各种工作中的感悟哦~
参考资料：公司内部培训PPT
喜欢
0
赠金笔