[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]
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]