你的位置:首页 > ASP.net教程

[ASP.net教程]敏捷开发心得4


1.Sprint 评审会议:不是让开发团队做成功“演讲”---会议上不一定要有PowerPoints 图片和文件,通常会议不会需要超过30分钟的准备时间,只是简单的展示工作结果,所有与会人员可以提出问题和建议。

2.在Sprint评审会议之后,开发团队会进行Sprint回顾会议。有些开发团队会跳过此过程,这是不适合的,因为它是使Scrum成功的重要方法之一。这是提供给开发团队的非常好的机会,来讨论什么方法能够起作用而什么不起作用,并一致通过改进的方法。Scrum开发团队,Product Owner和Scrum Master豆浆参加会议,会议由外部中立者主持;一个很好的方法是由Scrum master 互相主持对方的回顾会议,可以起到各团队间信息传播的作用。

3.敏捷回顾不是一场没有主题的讨论会,大家坐下来,七嘴八舌漫无目的一阵“乱弹”,这样的形式对于项目进展没有任何帮助。

4.Scrum回顾会议的过程:

1》在白板上写上主要主导原则;

2》在白板上画上一个至少三页纸连在一起长的时间轴。

3》在白板上写上我们的成功经验是什么。

4》在白板上写上“有什么能够改进”。

5》在白板上写上谁负责,然后分成两个区域---团队和公司。

5.Scrum回顾会议的最高指导原则。即“无论我们返现了什么,考虑到当时的已知情况,个人的技术水平和能力,可用的资源,以及手上的情况,我们理解并坚信:每个人对自己的工作都是全力以赴的”。

6.在项目过程中,处理问题越早,那么付出的代价与成本就越小。问题是,当我们在紧张的开发任务中,有时候很难发现这些错误,更加意识不到这些错误会带来的严重影响。通过回顾会议,利用团队成员互相善意的敲击对方,或者反复“锻炼”开发过程与方法,就能够让每一位成员都练就“火眼金睛”。

7.进行Scrum回顾时,发现问题仅仅是第一步,我们还要在回顾会议中合理分析这些问题出现的原因,所属分类,并因此划定问题的责任。我们要明确这些问题是团队内部的,还是由于外在因素导致的,指定处理人和处理时间。

8.在每个Sprint开始的时候,我们都必须要明确这个Sprint结束的时候需要演示的是哪些东西。很多时候,如果一个Scrum展开的不是很顺利,在Sprint演示的时候我们常常会听到这样的理由,“因为某些原因,这个功能我没有办法展示给你,但是这个功能是有了的,我只需要改动小小一点东西就可以了”。如果这样的话,这些理由到后期会泛滥成灾。我们所能做的,除了拒绝通过这些相关的 User Story 之外,在每个Sprint开始的时候还应该帮助团队了解到我们需要在Sprint演示会议上看到什么东西。强调我们重视的是可交付的版本,而不是一个口头上的更能增加。