Scrum 项目1.0 2.0 3.0 4.0 5.0 6.0 7.0

1.确定选题。

应用NABCD模型，分析你们初步选定的项目，充分说明你们选题的理由。

录制为演说视频，上传到视频网站，并把链接发到团队博客上。

截止日期：2016.5.6日晚10点

阅读教材第8章，8.1~8.3节 P157~168，了解获取用户需求的办法，每个组可以选择一二加以应用。

8.4节P168-171 查阅NABCDA模型的具体说明。

2.0---------------------------------------------------------------

2.SCRUM 流程的步骤 1

完成产品Backlog的编制，在spint计划会议之前，确保product backlog井然有序。

阅读教材第8章，8.5节 P171~173，帮助我们确定列表的优先级。

8.5节 P174~186，帮助我们估算工作量。

小组展示

下周二（2016.5.10）课堂上，第个组用6分钟时间尽情展示一下小组风采与选题。

形式可以但不限于由一人主讲其他成员配合，内容可以但不限于以下内容：

团队名称的由来、团队口号的含义，选题的理由、预期达到的目标，产品Backlog展示。

希望各个队伍认真策划并加以演练，以达到较好的展示效果。

评分：

本次作业由同学们和老师共同评分，每个组对其他组的展示内容与效果进行打分。

3.0-----------------------------------------------------

SCRUM 流程的步骤2: Spring 计划

1. 确保product backlog井然有序。（参考示例图1）

2. Sprint周期，一个冲刺周期，长度定为两周，本学期还有三个冲刺周期。

3. 确定Sprint目标。

　　3.1 产品负责人概括产品backlog,对sprint目标进行总体介绍，讲清他认为最重要的故事。

　　3.2 团队从最重要的故事开始逐一讨论每个故事，估算时间，理清每个条目的含义，在必要的情况下拆分backlog条目。所有重要性高的backlog条目都要填写“如何演示”。

　　3.3 团队根据生产率，选择要放入sprint中的故事。

 

4. 把故事进一步拆分成任务。（参考示例图2）

 

5. 形成Sprint backlog。 Scrum master隆重登场，组织大家按照SCRUM流程，步步为营顺利开展工作。（参考示例图3图4）

 

要求：将1，3，4，5项工作成果组织成一篇博客，发布在团队博客上。

截止日期：2016.5.12晚10点。

 

 

4.0-----------------------------------------------

1.准备看板。

• 形式参考图4。

2.任务认领，并把认领人标注在看板上的任务标签上。

• 先由个人主动领任务，PM根据具体情况进行任务的平衡。

• 然后每个人都着手实现自己的任务。

3.为了团队合作愉快进展顺利，请坚持每日立会。

• 定下每日例会的时间地点。
• 例会情景请拍照留影（至少一次，发布到博客上）。
• 会上大家依次报告:我昨天做了啥，我今天要做啥，我碰到了哪些问题。
• 每日立会时更新看板。
• 每天例会后的看板拍照显示进度。（拍照可以固定在一个位置拍，以后还可以把每天拍的图做成动画。参考图5）

4.博客发布要求：

　　看板设计。

　　任务认领情况。

　　下每日例会的时间地点，及一张包括全部团队成员的例会照片。

　　每日例会的看板进展。

　　每个同学记录自己的任务实现情况，可同时发布在自己的博客上。

　　此次博客截止日期：2016.5.17晚7点。

 

 

5.0---------------------------------------------------

1.团队成员完成自己认领的任务。

2.燃尽图：理解、设计并画出本次Sprint的燃尽图的理想线。参考图6.

3.每日立会更新任务板上任务完成情况、燃尽图的实际线，分析项目进度是否在正轨。

   每天的例会结束后的都为任务板拍照并发布到博客上

4.每天看到进展，待续到sprint演示。

 

5.博客发布要求:

完整的任务板（有燃尽图），5.18号晚10点之前发布到博客上，5.19号的例会就用上。

然后每天例会追加的任务板更新后照片或截图，直到本次sprint结束。

 

6.0-----------------------------------------------------

sprint演示

1.坚持所有的sprint都结束于演示。

• 团队的成果得到认可，会感觉很好。
• 其他人可以了解你的团队在做些什么，并得到重要反馈。
• 演示是一种社会活动，不同的团队可以在这里相互交流，讨论各自的工作。这很有意义。
• 做演示会迫使团队真正完成一些工作，进行发布。如果没有演示，我们就会总得到些99%完成的工作。有了演示以后，也许我们完成的事情会变少，但它们是真正完成的。

2. 可能会费点时间，实际没有完成多少工作的状况下演示就会变得令人尴尬。团队在做演示的时候会结结巴巴，之后的掌声也显得勉勉强强。有人会为团队感到有点儿难过。有人感到很不爽，宝贵时间被浪费在了一场很烂的演示上。

但它是苦口良药，等到下一个sprint，这个团队就会真得试着做完一些事情！

 

3.Sprint演示提示--检查列表

• 我们软件工程课的目的是理解开发过程、开展项目管理。所以第一要点是用你们的工作成果展示你们理解了一个sprint流程。
• 清晰阐述sprint目标，免得有些人对产品一无所知。
• 让演示关注于业务层次，不要管技术细节。即注意力放在“我们做了什么”，而不是“我们怎么做的”。
• 暂不需要花里胡哨的演讲，集中精力演示可以实际工作的代码。
• 节奏要快，不要演示细碎的bug修复和微不足道的特性。
• 可能的话，让观众自己试一下产品。
• 展示Sprint回顾的过程及成果。

4.Sprint演示日期：2015.5.27

   下周二课堂上，第个组用6~8分钟时间进行第一个Sprint的演示。

 

 

7.0------------------------------------------------

Sprint回顾

让我们一次比一次做得更好。

 

1.回顾组织

　　主题：“我们怎样才能在下个sprint中做的更好？”

　　时间：设定为1至2个小时。

　　参与者：整个团队。

　　场所：能够在不受干扰的情况下讨论。

　　秘书：指定某人当秘书，筹备、记录、整理。 

 

2.回顾流程

• sprint总结：Scrum master向大家展示sprint backlog，在团队的帮助下，对sprint做总结，包括重要事件和决策等。
• 轮流发言：每个人都有机会在不被人打断的情况下讲出自己的想法：他认为什么是好的，哪些可以做的更好，哪些需要在下个sprint中改变。
• 生产率分析：对预估算的生产率和实际的生产率进行比较，如果差异比较大的话，分析原因。
• 改进之处：快结束的时候，Scrum master对具体建议进行总结，得出下个sprint需要改进的地方。

 

3.回顾辅助（参考图7）

　　Good：可以继续保持的做法。

　　Could better：需要改变的做法。

　　Improvements：有关如何改进的具体想法。

 

4.回顾结论

　　即时贴上。

　　圆点投票来决定下一个sprint会着重进行哪些改进。

　　每个sprint只关注几个改进就够了。

 

5.回顾截止日期：2015.5.25晚10点

 

6.读书

　　阅读《构建之法》第8、9、10章，发布读书博客。

 

将些次Sprint演示与总结情况发布到团队博客上。

每个人也对此次Sprint进行总结，连同读书笔记与提问，发布在自己的博客上。

截止日期:2016.5.27晚10点。

然后好好休息，下周开始新的Sprint周期。

 

 

参考图7

 

 

 

参考图6

 

参考图4

 

参考图5

 

参考图1

参考图2

参考图3

参考图4