干货IT项目Scrum常用最佳实践！轻松入门！实战经验分享！
Posted 光环远程学友会Adi
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了干货IT项目Scrum常用最佳实践！轻松入门！实战经验分享！相关的知识，希望对你有一定的参考价值。
课程来源：孙选营老师
编辑：Lily
各位同学，上周六
我的主场听我说第7期
【IT项目Scrum之常用最佳实践】
直播课回顾干货来啦！
课程大纲
三大部分
1、Scrum概述；
2、Scrum日常会议；
3、Scrum流程管理与工具
Scrum是敏捷的一个框架
在谈Scrum之前先认识一下敏捷
说起敏捷我们也许会想起很多个标签
这是我脑海里浮现的标签
敏捷是90年代兴起的新型的软件开发方法
敏捷开发是以用户的需求进化为核心
采用迭代、循序渐进的方法来进行软件开发
敏捷主张：简单 拥抱变化
在敏捷开发的过程中，有很多同学很讨厌需求变更，因为需求变更会带来一些代码的重构，我们不能说这些同学喜新厌旧，虽然他们喜欢开发新的东西，不喜欢在旧的代码上改来改去，他们认为在同一个代码上翻来覆去没什么意义，浪费精力。
其实敏捷就是主张我们需要“拥抱变化”这样一个心态。如果没有了变化，敏捷就失去了变化，敏捷就是为了应对不确定性强、可能随时变化的用户需求。我们要做的就是快速响应用户需求的变化。
敏捷采用的是快速迭代的方法来实现给客户的持续交付，每个迭代一般的周期不会超过4周时间，一般现在的产品迭代周期都是2周时间。
如果说一个迭代安排的需求太多，跟现有的人力资源不符合，无法完成这个迭代安排的需求，这时候就需要我们和产品经理进行沟通，砍掉一些需求安排进下一个迭代。
每一个迭代、每一个进入迭代的需求，都是清晰明确的。
如果说迭代中进行的一些变化，我们可以重新安排或者是安排进下一个迭代
每个迭代我们安排的需求可以是已经开发完需要进行打磨的，也可以是新的需求，我们就是在敏捷里面这样快速迭代、快速响应、持续交付，这样一个不断的去完善产品的过程。
敏捷也需要团队之间去完成紧密的协作，也需要研发团队和客户之间进行紧密协作。
敏捷有很多很多框架，每个框架都有一系列实践，我们在项目中可以灵活地去选择合适的实践来完成项目的目标。并不是说选择了某一框架，就一定要按照这个框架去走。
91年的时候，Scrum的概念就已经诞生了。
而01年，敏捷宣言也诞生了。
许多听过博士直播课的同学是不是很有印象？
这里孙老师有不同的理解哦。
个体和互动高于流程和工具
我们知道在传统的研发过程中，一般都有一套的标准的流程和工具，属于流水线式作业方式。每个环节完成，交给下一个环节，每一个人都对自己的工作比较熟悉。
敏捷是把这些不必要的进行简化，有必要的进行加强。项目组的每个成员都是一个个体，敏捷就是把重心放在了个体之间的互动上，不建议大家按照流程、各干各的。敏捷主要是激发个体和团队之间的交流，激发个体的主观能动性。如果一个项目团队里面，大家都主动起来了，那么这个团队的战斗力、效率、产品指标都会跟着提高。
可工作的软件高于详尽的文档
在传统的研发当中，一般都是需求顾问用word出很多文档，一个需求就是一个word，内容又非常长（几十页甚至更多），需求顾问也会因此花费大量时间和精力。但是这样传递需求的效果却非常差，因为需求顾问认为自己自己写的非常明确了，但其实只有自己明确，看文档的人需要花费很长时间来阅读，还不一定能真正理解需求，极大地降低了传递交流的效率。所以通过需求文档这种方式，无论是给开发人员还是用户，都达不到准确高效的沟通要求。
我们这里说的“可工作的软件”并不一定是最终完成的软件产品，在需求这一层，我们一般在软件开发的时候使用原型法，这是做软件最常用的一个需求传递的形式。
原型法可以很直观的看到未来产品的样子，很好地和用户、开发人员进行沟通。
客户合作高于合同谈判
传统做软件的过程中，一般都会把用户的需求范围、需求细节点明确地列出来，作为合同的附件，这样的结果就是双方一般都没办法达到一个较高的满意度。
我们需要明确的是：客户不是敌人，我们和客户是合作关系，我们是因为客户的需求才有了项目目标，工作人员和客户都是为了同一个项目目标。
在敏捷里，客户是需要参与到项目互动中的。一般有了客户的参与，项目目标达成时往往有事半功倍的效果。有客户参与，我们在研发时的方向也不容易跑偏。最终，双方都会有一个比较好的满意度。
响应变化高于遵循计划
在互联网高度发达的今天，没有什么是一成不变的，用户需求也是一样。
我们做软件的时候经常会遇到一种现象：用户他自己本身都没想清楚自己想要的是什么，需求随时都在变。
敏捷提倡的是拥抱变化。我们做项目首先要立项，立项就要做计划。这个计划在实际工作中需要不断改进，并不是有了计划就可以一成不变地实行了。
我们以造车为例，
做一个敏捷与瀑布模型的对比。
横向的1-9月，我们可以看作是项目的研发周期
在传统的瀑布模型中，我们首先会有一个想法：“我想造车”。
然后，我们会进行商业论证、出方案、评审PPT等一系列方案评审，这个过程非常耗时。经过评审之后，我们再开始研发相关的流程（设计、开发、测试）。等我们耗时几个月，产品发布上线的时候，我们才发现中间有些环节可能做得不对，产品并不是用户想要的，甚至说是在产品评审、研发的中间环节，用户的需求就已经改变了。
那这么多个月的资源、时间投入，没能达到预期的价值，就是一种浪费了。
传统瀑布模型其实就是一个大的迭代，把产品完全上线。
而敏捷呢，其实就是通过一个快速迭代的方式，就是一个个小的迭代。比如“造车”这个想法，目的是解决人们的出行问题，就是要研发交通工具。
我们把这个目标分解成不同的小版本，最早我们给用户提供一个最小的可行版本来解决出行问题，也就是“自行车”。
用户在拿到最初产品后，在使用过程中可能会发现一些问题，比如说用起来比较费力。那么在下一个版本中，我们就可以加入电机来代替人力，也就是给用户提供了“电动车”。
用户使用了电动车，可能会反映“续航能力差”，那么我们就可以继续更新版本。下一个版本，我们就可以提供加油的发动机，为用户提供“摩托车”。
当然摩托车也有缺陷，比如天气不好的时候，用户可能会面临风吹日晒雨淋的问题，于是我们再加上顶棚的概念，这个时候就组成了一个“小汽车”。
随着产品的使用，也许用户在精神上会有一些更高的要求，需要造型、外观的更高配置，那么我们就可以把“小汽车”再次迭代升级，为用户提供“跑车”，这也是最终的一个“终极版本”。
所以我们可以看出，传统的瀑布模型中，这个产品的研发是一个大的迭代，在整个研发过程中是没有任何受益的，项目收尾的时候产品才真正的上市，并且在过程中很少会做改动，去考量用户的实际使用情况，因为在这个过程中用户是没有使用的。
而敏捷是在项目中会持续迭代，持续产生有价值的产品，每一个小迭代都会出来一个有价值的小产品。这样一来，首先就会有持续的收益，其次我们会给用户做一个增量的交付，然后我们还可以收集用户变更的想法，发现用户的真实价值，对产品进行一个持续改进。
Scrum是敏捷的一个框架
敏捷还有很多框架如极限编程、XP、DSDM等
我们就先来看一下Scrum的
一个“3355”模型：
三个工件：需求清单、迭代任务清单(看板)、迭代交付的产品增量
三个角色：产品负责人(PO)、Scrum主管(SM)、研发团队(DevTeam)
五个价值观：勇气、专注、承诺、尊重、开放
五个事件：冲刺(Sprint)、冲刺计划(Sprint Planning)、冲刺评审(Sprint Review)、每日站会(Daily Scrum)、冲刺回顾(Sprint Retrospective)
最左边就是一个需求清单，
列出之后，后续的都是开发的过程。
下面我们来看一看Scrum的日常会议，
这都是比较常用的。
第一阶段（团队接收需求的过程）-站在产品经理角度上：经理将需求给到团队，做好迭代计划后，拉出一部分迭代需求清单，将这些需求进行一个详细拆分，将这些需求理得非常明确细致，之后将这些需求做成原型（默认此时是软件开发工作），利用原型为团队过一遍需求：未来我要的是一个什么样的产品？这就包含功能、功能是怎么样交互的……
在这个过程中，开发团队随时都可以打断、提出疑问，然后产品经理解答，所有人达成一致后，产品经理就完全地把需求传递给了开发团队。
第二阶段（需求的反串讲）-由研发的代表来执行此过程：整个研发团队拿到需求后，会进行架构设计，也会进行研发需求的设计，还会排一些开发计划等等。研发团队会出一系列的流程、框架、结构，再把开发安排到每一个人身上，包含时间节点等计划都会列出来。这些内容清单会给到研发的代表，然后研发代表会找到参与这个迭代的项目团队（不一定是整个项目团队，因为每个迭代参与的人和团队可能不同），给出内容清单（即研发产生的结果），和项目团队一起过一遍。这里的过程和第一阶段是一致的，项目团队可以打断、提出疑问，而研发代表和参与设计的团队会给出解答，所有人达成一致后，这个需求评审会就算最终结束了
接着，就进入了研发的阶段：开发人员去开发、测试人员去测试……
在开发阶段，每天都会进行一个会议，这是敏捷中很重要的一环。
固定时间、固定地点、产品参与人员、研发团队必须参加，敏捷教练可以不参与。
不闲谈，非常快速高效地过一遍每个人的任务。
遇到的困难不在会上细说，可以在会后找到具体负责人详谈。
这也是一个比较重要的会议，由敏捷教练（SM）来推进。
主要是回顾上一个迭代，做得好可以沿用到下一个迭代，做不好的需要改进，不断地提供生产力。
一般这个会议根据迭代的周期决定。
这是我比较擅长的部分，所以也是尽量少讲理论，这些都是我在项目实际应用中得到的经验和实践。
1.需求管理流程
2.需求开发流程
3.常用工具
研发协作工具：
阿里云效
微软TFS
阿里Teambition
Atlassian JIRA……
需求设计工具：
Xmind
Axure RP
PS……
研发工具：
PD数据库设计
Visio流程设计
研发相关的开发工具……
灵活运用
紧密协作
持续交付与改进
我的主场听我说第7期
【IT项目Scrum之常用最佳实践】
内容分享就到此为止了哦~
很多同学没有时间参与直播
纷纷想要老师这份珍贵的课程PPT
作为一个为大家规划职业未来
全心全意为大家服务的好Adi
当然会无私分享出来啦！
发送消息【直播】
即可领取独家课程PPT▼
一起规划您的职场之路
从现在开始改变
未来将会永远掌握在自己的手里
（部分图片来源于网络，如有侵权请联系）
身边的许多人对自己的职业生涯漠不关心：
随波逐流，会去向哪里只有听天由命。
兜兜转转几年，回望自己的职业生涯，只有一团乱麻。
职场中，如何构建自己的能力体系？
危机时，如何规划自己的职业生涯？
4月21日20:00，严昫老师帮你解答
#长安十二时辰【第三讲】#
长安十二时辰大型系列直播活动，第三讲火热报名中~
本期分享主题：下属出了岔子领导怎么出面摆平？
4月25日 10:00-12:00
【最高可获得4PDU】
以上是关于干货IT项目Scrum常用最佳实践！轻松入门！实战经验分享！的主要内容，如果未能解决你的问题，请参考以下文章