scrum敏捷项目管理方法（Scrum开发管理的实施方法与工作过程）
scrum敏捷项目管理方法（Scrum开发管理的实施方法与工作过程）在说明任务管理方法前，还是要提一下Scrum理念所强调的仪式感。Scrum方法认为一个团队中的所有成员最好是将自己的电脑从格子间的工位搬出来，有条件的话大家在一个单独的房间里共同办公。例如找一间空闲的会议室，大家把电脑都放在会议桌上，彼此围成一圈。然后拿出可粘贴式便签纸，准备下一步工作。可是问题就在于软件开发活动就是个意外频出的过程，一张绘制完美的图表到后期总是被各种变更扭曲、打乱，结果变得丑陋不堪。在Scrum的实施过程中，采用的是事项清单来管理任务。经过数轮的冲刺实现产品的迭代，这必然是趋近于客户的目标的。这远比团队关起门来开发几个月，拿出来的产品跟客户的预期差距甚大要好得多。同时，固定时间的冲刺活动也有利于团队成员保持工作节奏，能够合理地安排自己的任务。要点：Scrum团队的任务管理是有别于传统的软件开发管理的。在传统管理方式中，是由项目经理与架构师或者资深程序员讨论出一个任务列表。
本文将说明Scrum方法中的冲刺、事项清单、用户故事以及立会，其实施过程与注意事项等。全文3100字，阅读时长6.2分钟。
一个遵循Scrum理念的团队建立起来之后，就要进入工作状态中了。但这不是一上来先打了鸡血一样，过一阵子又疲软无力。要想保持高效的产出，节奏很重要。在scrum中，一个冲刺的过程一般来说不超过一周时间。持续四到五个周期的冲刺之后，就可以得到基本可用的产品了，这也是流传甚广的30天开发可用软件说法的由来。
对于冲刺的目标来说，并不是说在每个周期完成一个功能模块，所有模块开发完后组装在一起完事。每一次冲刺的目标都应该是交付一个可用的软件产品。当然，最初的产品仅是一个粗糙的原型，但也足够给客户提供直观的体验。在此时客户发现问题并提出新的需求，在下一个冲刺中就可以全力解决问题并开发客户所需的功能了。
在冲刺开始之前，要举行一场计划会议。这个会议的议题是讨论要进行的工作，并将讨论内容归纳成用户故事。需要注意的是计划会议只讨论当前一个冲刺之内能完成的任务，目标过于宏大没有意义。作为一种敏捷方法论，Scrum强调的是快速接近用户真实意图，打造符合预期的可用软件。
当一个冲刺结束之后，则要召开一场总结会。这个会议则是讨论当前已经完成的工作，同时要回顾出现了哪些问题以及解决的办法。这是为了避免在后面的工作中再犯相同的错误，这往往是提高效率的关键。最后则是向所有成员展示已经取得的成果，鼓舞团队士气，为下一个冲刺做好准备。
经过数轮的冲刺实现产品的迭代，这必然是趋近于客户的目标的。这远比团队关起门来开发几个月，拿出来的产品跟客户的预期差距甚大要好得多。同时，固定时间的冲刺活动也有利于团队成员保持工作节奏，能够合理地安排自己的任务。
要点：
- 举行冲刺计划会议；
- 全力以赴投入工作；
- 召开冲刺总结会；
- 多轮迭代。
Scrum团队的任务管理是有别于传统的软件开发管理的。在传统管理方式中，是由项目经理与架构师或者资深程序员讨论出一个任务列表。然后项目经理在甘特图中标明各个任务的起止时间，再把开发人员填充进去，万事大吉。这种图表是完美的，如果不出意外，结果也应该是完美的。
可是问题就在于软件开发活动就是个意外频出的过程，一张绘制完美的图表到后期总是被各种变更扭曲、打乱，结果变得丑陋不堪。在Scrum的实施过程中，采用的是事项清单来管理任务。
在说明任务管理方法前，还是要提一下Scrum理念所强调的仪式感。Scrum方法认为一个团队中的所有成员最好是将自己的电脑从格子间的工位搬出来，有条件的话大家在一个单独的房间里共同办公。例如找一间空闲的会议室，大家把电脑都放在会议桌上，彼此围成一圈。然后拿出可粘贴式便签纸，准备下一步工作。
管理员这时会站起来，在会议室的白板上用碳素笔画出三个分隔的区域，并且从左至右在各自区域写上：待办事项、在办事项、完成事项。接下来讨论第一个冲刺要完成哪些任务，在Scrum中，这被称之为用户故事（下节详细讨论用户故事）。大家达到一致之后，管理员把用户故事分别写在便签条上并贴在“待办事项”区。再接着就是进行任务分配了。
重点之处在于，任务并不是由管理员自上而下地分配给某人，而是由团队成员自告奋勇领取任务。领取者会庄严地将便签条从“待办事项”区移至“在办事项”区。这样团队所有成员也就明确承诺了自己的任务，并且在一个冲刺周期完成之后，再由领取任务者将自己的便签条从“在办事项”区移至“完成事项”区。相信当众主动承诺所带来的驱动力是远胜于被人在后面给推着走的了。
当然，如果一个团队在组建伊始，可能会出现对工作承诺过于悲观或过于乐观的问题。但经过一到两个冲刺之后，团队成员彼此熟悉并且配合默契了，就会更加合理地领取任务并完成好。当冲刺的次数越多，团队的效率就会越高，这是Scrum方法所带来的一个巨大的益处。
事项清单也有助于团队成员对项目整体进展的把握，因为只要有一个任务还留在“在办事项”区内，那么这一次冲刺也是失败的。势必大家都会为了共同的目标而群策群力，而不是说别人的任务跟我没关系，等他自己解决就行了。
要点：
- 在封闭空间内集体办公；
- 准备好写有待办、在办、完成事项的白板和便签纸；
- 将用户故事写在便签纸上，并张贴出来；
- 团队成员主动领取任务；
- 移动便签纸，直到任务全部完成。
在Scrum中，软件功能的需求被称之为用户故事。之所以要用这样的名称，是为了借助于“故事”一词所传达出的隐喻。我们知道一个故事的基本要素里包括人物、情节发展与结局。对应于软件需求来说，一个需求应该从用户角度出发，然后他会如何操作以达成目标，以及这个需求是否可测试。
在讨论用户故事的时候应该要和最终使用者进行充分地沟通，因为只有使用者才明白他们想要的是什么。但遗憾的是使用者本人在没有直观的感受前，他只能以模糊的话语来描述他想象中的事物。
所以在确定一个用户故事时，它的规模不能太大，最好是一个可在短期内实现的功能。一般在Scrum实践中，一个用户故事的开发周期就是在一个冲刺之内。
同时，一个用户故事必须是独立可测试的，不能说对它进行测试还要依赖于另外一个用户故事。强调它的独立性一是为了减少系统功能的耦合，二则是可以根据用户对功能的要求紧急程度进行组合。
在初期讨论用户故事时，可能会罗列出很多事项来，但不可能都同时进行。因此要按照功能的重要程度给其标记上权重值，这样就可以将最核心的功能挑选出来优先开发。在一个冲刺完成后，用户立即就能对已经完成的功能有直观体验，进一步明确下一步的工作。
除了功能重要程度，每个用户故事还应该标记实现复杂度。这个数值是为了估算团队的完成能力，有了这个数值就可以合理分配一个冲刺之内的工作量。不至于说上周任务难度低，工作特别轻松，这周任务都很复杂，结果搞得大家都压力重重。
要点：
- 一个用户故事必须是独立可测试的；
- 一个用户故事最好在一个冲刺内完成；
- 标记重要程度值；
- 标记复杂度值。
立会的意思就和字面上一样，站着开会。这也是一个Scrum所要求的仪式，站着开会显然会促使人长话短说，同时还有益健康。当然，Scrum理念的发起者是希望这样一个形式能让人时刻记住立会的目标：快速总结工作成果，并提出问题。
在一个冲刺周期内，立会是要求每天都要召开的，通常由管理员发起。开会时间也最好是一天中的固定时刻，例如早晨十点，不用特别通知，每个人到了点就自动聚在一起开会。
管理员会提出三个拷问灵魂的问题：
“昨天完成了什么工作？”
“今天要做什么工作？”
“遇到了什么问题？”
每个人都要回答，而且每个问题的回答时间不能超过30秒，意味着两三分钟内就要把三个问题全部答完。这不是在搞某种行为艺术，而是效率的需要。 如果在短时间内不能说清这些事项，那就意味着任务的分解是不合理的，有隐含的复杂情况没有被发现，而这对项目来说就是风险。
一个需要注意的情况，就是立会不要开成工作汇报会，大家只是例行公事般说完自己的事就各自安好了。立会的主要功能有两点：一是让大家的信息保持对等；二是尽早解决问题。
有研究发现，一个团队的默契合作程度和一个叫做信息饱和度的指标相关。这个指标的含义就是团队成员之间分享信息的比例，信息饱和度越高则团队的产出效率越高。而每日立会则是一个极好的大家共同交换信息的机会，通过这种方式将信息饱和度保持在一个高水准。
我们翻开任何一本讲述软件工程的书籍，都会告诉我们一个软件bug如果在前期被忽略，到后期来修复时会产生更加巨大的代价。立会上的第三个提问就解决了延迟解决问题所带来的损失。
当然，在立会上仅需要提出问题就好，散会后再召集相关人员详细讨论解决办法。切忌在立会上就热烈讨论半天，而耽误了整个项目的进展。这时管理员就要保持清醒的头脑，控制会议的进程。
要点：
- 三个问题；
- 三分钟之内说完；
- 聚焦于出现的问题。
