[团队项目]SCRUM项目6.0 7.0 （新）

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

sprint演示

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

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

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

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

 

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

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

4.Sprint演示日期：2015.5.24（一个特殊的日子）

   下周二课堂上，第个组用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章，发布读书博客。

 

 

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

Sprint回顾

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

 

1.回顾组织

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

　　时间：时间一个钟

　　参与者：重案组成员

　　场所：B5001工作室

　　秘书：黄冠锋

 

2.回顾流程

• sprint总结：Scrum master向大家展示sprint backlog，在团队的帮助下，对sprint做总结，包括重要事件和决策等。我们团队在一次次项目研讨中能够逐渐提高个人的能力，使团队合作性更强，工作效率也越来越高了，看燃尽图实际值和理想值也越来越接近了。
• 轮流发言：122许恒蓝 团队项目使我的写代码能力逐步提高

　　　　　　　　129赖新耀 团队分工很明确，能够互相帮助解决问题

　　　　　　　　130卢利钦 整个项目开发过程考验的就是人与人之间的默契，相信下一次Sprint会做得更好

　　　　　　　　134黄冠锋 在这次团队项目开发中，我们真的学到好多东西，尽管能力水平不平衡但我们能够优势互补，在团队中发挥个人的特长，这样对我们的团队有更好的发展。

• 生产率分析：项目生产率跟我们预期的大致一致
• 改进之处：工作分配不够详尽，项目划分还不够明确

 

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

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

　　　　　　经常讨论，发现问题，及时解决

　　Could better：需要改变的做法。

　　　　　　工作分配要更明确

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

 　　　　　 有了学问，好比站在山上，可以看到很远很多东西；没有学问，如在暗沟里走路，摸索不着，那会苦煞人。

4.回顾结论

　　不断改进不断优化项目的页面，逐步逐步符合大众的口味

 

 

 

 

附上项目截图：

最后附上网页网址：www.dfish.ml    欢迎大家指导指导  不喜勿喷 

我们每天通过CNZZ数据专家及时统计网站流量和用户喜好

 

重案组成员及本次的个人贡献分

姓名	学号	博客链接	Github链接	个人贡献分（20*N*比例）80
黄冠锋	201406114134	http://www.cnblogs.com/hgf520/	https://github.com/crown999	23
卢利钦	201406114130	http://www.cnblogs.com/luliqin/	https://github.com/luliqin	22
赖新耀	201406114129	http://www.cnblogs.com/lieson/	https://github.com/Laixinyao	20
许恒蓝	201406114122	http://www.cnblogs.com/xhlbk/	https://github.com/xuhenglan	15

转载于:https://www.cnblogs.com/hgf520/p/5511267.html