轻松Scrum之旅(上)

  2014年12月27日下午3点,老师听完ITOO的Java和.Net项目的延期原因,总结了以下三点:1.没有全局观,统筹没有做好  2.如果遇到问题,没有去找相应的理论支撑 3.没能很好的使用工具

  我们新生入学,作为ITOO的子项目,开发起来也遇到了重重困难。想起了老师说的第二点,寻找理论支撑,我翻阅了之前推荐给我们的电子书《轻松Scrum之旅》,它给项目的管理起到了很好的指导性作用。通过这本书的引导,我对敏捷开发的常用的知识做了详细的整理。


一、准备Scrum之旅

1.瀑布模型VS敏捷开发

  瀑布模型的开发模型固定,可行性分析——>需求分析——>设计——>编码——>测试——>运维。优点:提供了各个阶级的检查点,一个阶段完成,只需考虑下一个阶段(跟贪心算法是不是很像?)适合于迭代。缺点:文档多、开发末期才能见成果,不适合用户需求的变化。程式化的东西难免让人觉得假大空,死板。

  敏捷开发最大的特殊就是应对客户变更的需求,以人为核心,采取迭代的方式,循序渐进的开发软件。一听到这个名字,感觉开发的过程比较迅速!优点:能很好很快的给用户提供满意的产品。缺点:工作汇报,如果没有完成任务,会害怕暴漏自己能力不足。另外对沟通能力,业务理解能力要求比较高,全能型开发者。总之一句话:门槛高啊!


2.禅道的使用:

  产品负责人:确定产品的功能和时间,优先级。人员一般是市场部或者开发部使用该产品的人员来担任,主要目的是根据需求确定功能。

  Scrum Master:监督整个项目,调整项目计划,促进团队成员的沟通,扫除障碍。掌握产品开发进度,参与每日Scrum会议、Sprint计划会议和Sprint评审会议。

  Scrum Team:5-10个全职工作成员。

       轻松Scrum之旅(上)_第1张图片

       燃尽图:总剩余时间的燃尽图,就是本次迭代中所有拆分任务的剩余时间总和,随日期的变化而逐渐递减的图,它为敏捷开发提供了可视性。

通过它能帮我们发现以下问题:

1.团队计划制定情况如何?

2.在一个Sprint中,团队对计划的的故事执行情况如何?

3.团队是自我管理的吗?作为“团队”来说,工作步调一致吗?

4.团队能进行哪些改进?


 二、激动人心的Scrum之旅——第一站

  每日Scrum会议:

时长:站着,不应该超过15分钟。

内容:昨天我完成什么任务?今天我打算做什么?我遇到了什么障碍?

内涵:大家同步信息的平台,而不是交流问题,讨论问题的渠道。而且制定计划也要按照大家的实际情况来制定,不能项目组长武断做决定。

注意:1.团队成员间的交流,承诺,不是汇报进度。2.不是解决技术问题的会议。

Sprint评审会议:

  Scrum团队在会上用Demo的形式来展示他们在这个Sprint上做的工作,与会人员评价它的新功能。

   用Demo的原因:1.直观,及早发现问题,利益相关者可直接反馈 2.为完成功能,团队会努力并发布这些功能 3.减少99%的也许完成的数量。


Sprint回顾会议:

   Scrum Master首先给大家看Scrum Backlog,总结这个Sprint,大家讨论比较重要的一些事件。认为哪方面做的好,哪方面需要改进,如何改进。讨论成果,如何在下一个Sprint中做的更好。


三、Sprint计划与变化

1.思想

  不应该有理由和借口抛弃团队。

   不应该隐瞒团队的技术实力,否则很难做切合实际的计划和评估。

  善于寻求帮助是个好习惯,不仅仅是针对敏捷开发。

  敏捷思想,团队里面没有绝对的权威,每个人都有可取之处,要避免少数服从多数。

2.工具和机制

  项目文档管理工具Confluence。 

  单元测试是不可避免的一环。

  代码复审+结队编程可以提高效率。


四、总结

  项目开发仍在继续中,总有新的问题出现,老师说的很对,你做过的每件事肯定有其他的人做过,学会站在巨人的肩膀上是一种能力。欲带皇冠,必承其重。开始学习的不适是必然的,但是使用工具带给我们的效益远远超乎我们的想象。


如果您觉得我写的东西有些帮助,敬请期待我的下篇博客轻松Scrum之旅(下)



  

你可能感兴趣的:(敏捷开发,项目管理,Scrum)