初识scrum总结

[color=olive] Scrum管理软件开发是一个重要的尝试，也是具有意义的进步。以往我们是在混乱中度过的，直接拿到需求，读的一知半解便开始着手代码，自己写代码自己负责。等到测试人员测试的时候bug很多，修改bug占用了很多时间。有时开发速度很快，但真正完成任务的周期需要相当的时间。以往的交流也是非正式的，还要看开发人员是否喜欢和其他人员交流，有时甚至会造成程序员发挥自己想像“补充”需求的局面，造成了开发上的重大失误。
Scrum很好地消除了上面提到的问题。Scrum小组的sprint计划会议、冲刺目标、每日例会、评审、不受干扰的开发、结对编程、回顾会，这些使得开发工作井然有序，提高了开发效率和产品质量。团队成员每天都能明确自己的任务，能够高效率的工作。
Scrum是一个框架，其本身就是一种团队的管理。它提供了一套实践方法，提出了把任务分成story、backlog、sprint backlog等概念，每日跟踪完成进度，回顾与明确今日的任务，使一个团队高效率的运作。一支出色团队靠的不是技术，不是流程，而是有良好素质的团队成员。良好素质包括进取心、责任心、良好的习惯、热情……在Scrum团队中，我们可以培养这种良好的习惯，良好素质的团队成员。
今天看了《硝烟中的Scrum和XP》，更进一步地了解了Scrum。结合敏捷开发，Scrum为我们提供了量身订做的开发管理，我们可以根据自己的需要灵活地把Scrum运用到项目中。文章中考虑到了很多问题，几乎全面地回答了我们的疑惑，对于Scrum团队的形成，到有效地开展工作，影响Scrum团队的因素，Scrum的各个环节，测试等都做了详细的说明，有的以例子的方式辅助解答，有的注以说明其灵活运用。当然，Scrum是一个框架，完成开发任务还是要靠我们小组成员，而我们初识Scrum是在探索中，《硝烟中的Scrum和XP》给了我们重要的参考与扩展，是经验的学习和Scrum运用的深入。
公司引入Scrum管理的第一个尝试放在了产品组的开发项目上，利润敏感性分析的开发。Scrum小组的形成和前期会议中，叶新华和王慧娟两位经理都参加进来，我想这里的角色划分应当是：王慧娟代表了产品负责人，叶新华代表了项目经理，这正符合Scrum会议的要求。会议中讨论了story，产品的backlog，sprint backlog，sprint冲刺目标，每个sprint backlog完成需要的人日等，确定Scrum master为方磊，成员为于飞、朱浩、孙元元和我本人。会议之后大家的任务目标都很明确，任务量和完成的人日安排是大家一起制定的，所以没有异议。这种每个人都参与估算的方式调动了成员的热情，也增加了估算的可靠度。开发过程中每日的例会都会按时举行，成员都能明确自己下一步要做什么，燃尽图的走势和小纸片的移动也告诉我们工作的进展情况。
我认为我在这个小组中还是存在不少问题的，甚至完成速度和我有很大关系。我在小组中分派的任务不多，前期任务中有一部分是我的，我完成的也很快，通过评审和修改后接下来的工作偏向于计划外的事情。看了《硝烟中的Scrum和XP》后觉得这是件糟糕的事情，我的计划外任务太多，甚至脱离了小组工作。这与我对Scrum的理解不够有很大的关系，通过回顾会上叶新华的解答我恍然理解了Scrum的真谛：齐心协力的团队。假如我在完成前期的工作后，不去做那些计划外的工作，专心于冲刺目标，和成员一起做没有完成的工作，参与到结对编程中，相信完成任务的时间会提前。这里是我应当深刻反思的地方。
关于Scrum中的其他一些不足，我认为sprint backlog划分上基本没什么问题，个别的还需要拆分；在sprint会议上大家对任务的难点估算不够，对需求的理解不够；开发的效率不高（原因很多，比如第一次Scrum，开发人员第一次用Flex开发等等）；成员之间的沟通还需要进一步加强，成员的工作热情还需要进一步提升，要充分调动成员的积极性。
当然这次Scrum的尝试是成功的，它的优点我们只是有限的发挥了一些，潜力很大。我们的开发小组不在是混乱的，我们的目标也很明确，我们每天要做什么也很明确，我们遇到问题可以很好的交流，Scrum master会帮助我们解决一切影响我们工作的问题，我们是积极地参与者，目标只有一个：努力完成冲刺目标。总结经验才能做得更好，吸取经验后积极改进才能进步。相信我梦想的Scrum，相信我们的进步，让白板、任务条和燃尽图充满我们的工作，点燃工作的热情。
[/color]