Scrum敏捷开发 实际执行遇到的问题和方案(研二)

Scrum执行规则

1. 每个小组3-6人，尽量做到高低年级，男女搭配，让大家可以接触到不同类型的合作伙伴。

2. 每个sprint周期开始之前，一定要保证即将开始的sprint周期有足够多的已经准备好的任务（足够多：1-1.5个周期的任务量；已准备好（满足如下任意条件）：a）已形成测试用例、确定好优先级和story points数目并通过老师的审批；b）修复bug类的任务要描述bug的现象，对应的svn的版本号；c）集成类任务要描述集成的预期结果）。

3. 在讨论任务的story points时候，务必做到以事实为依据，不能因为这个任务可能要交给某个基础比较差的同学做，就人为抬高该任务的story points数目。

4. 任务的提出和解决方案的形成，最好能在全组讨论中通过，保证全组人都知道该任务的存在，以及解决方案被全组人充分讨论过。避免任务的重复执行，或者设计出不好的解决方案。

5. 对于全组讨论不出解决方案的任务，可以指定专人花额外更多的时间去研究制定解决方案（制定解决方案可以作为一个单独任务），然后全组讨论通过或否决该解决方案；不能直接把讨论不出结果的任务直接交由某人全权负责设计和实现。

6. 在确定了任务的解决方案后，才由全组确定storypoints的数目。

7. 对于非修复bug类和集成类的任务，坚持测试用例/解决方案的提出者和任务的实现者分开的原则，保证一个任务至少有两个人可以知道实现细节，且在实现过程中，至少有人可以讨论实现细节问题。

8. 在经过全组确定了技术解决方案和story points数目之后，才决定任务的具体执行人，避免在任务的讨论和设计阶段就私自定下执行人，导致其他组员在任务的相关讨论中事不关己高高挂起。

9. 任务执行者的确定，建议采取如下两种方式之一：a）在进行story points表决时，若给出最低story points的组员坚持自己的意见，该组员可直接成为该任务的执行者；b）按照story points的数目，将任务分成难度高、中、低三档，由组员自行决定希望做哪个档次的任务，在该档次中，通过随机选取的方式，来确定任务执行者。

10.     建立任务退出机制，即在分配任务时，由任务执行者结合任务的story points（由全组讨论得到，参见第3点）和自己的能力，在全组同意的情况下，给出任务完成的deadline（精确到小时，例如明天中午12点）。在任务deadline到期仍然未完成任务的情况下，其他任何组员在任何时候有权利接管该任务，成为新的任务执行者。在任务完成后，任务的story points数归新的任务执行者所有。

11.     加强组内沟通，尽量检查每日例会和多进行全组讨论；

 

Scrum Monitor任务列表

1. 每个sprint周期由一人出任Scrum Monitor，用以保证scrum能够顺利执行；

2. Scrum Monitor完成如下任务来监控scrum的执行：

a)  监测钉钉星任务中已准备好但尚未开始执行的任务的总story points数目，当该数目低于一个sprint周期的任务量时，发起全组会议讨论并增加新的任务；

b)  每日负责把钉钉上的星任务的执行情况更新到excel表中，在每天早上9点之前把excel表发给导师的钉钉上；

c)  当星任务逾期后，负责每天在钉钉群中提醒任务责任人，直至该任务完成或者责任人发生变更；

d)  当sprint周期完成2/3的时间后，评估当前sprint周期是否能完成预期任务。若评估结果为不能完成，在钉钉上对导师预警；

e)  对于没有完成预期任务的sprint周期，负责在sprint周期结束2天内组织全组进行反思，并提交1000字以上的整改报告给导师；

f)  在钉钉上记录每个sprint周期内全组会议的情况；

g)  在sprint周期会议上，负责向导师汇报上一个周期的执行情况，具体包括每个成员的总工作时间，花在执行任务的工作时间，花在讨论上的时间，完成的story points数目；

h)  在sprint周期会议上，向导师汇报马上要执行周期的任务的解决方案；

i)  在sprint周期会议上，准备好组内所有成员的工作日志备查。

 

Scrum开发成员责任

1. 负责一起讨论sprint周期内的任务，制定执行方案，确定任务的story points；

2. 每天将自己工作的情况反馈给ScrumMonitor;

3. 当遇到无法解决的问题时，尽量发起全组进行讨论；

4. 星任务结束时，建立二级审批，首先交由测试用例的建立者进行审批，对于修复bug和重构类任务，交由组内其他一名成员进行审批，完成组内审批后再交由导师进行审批；

5. 任务完成的标准是通过导师的审批。