软件性能工程

<br /><br />在只能用狼籍来形容的sprint1 demo终于落下了帷幕。由于是第一个迭代，第一个sprint，一切都可以原谅，不是吗？<br />sprint1的目标很简单，每个同学只要完成一个功能点就OK。但是demo的时候还是暴露出了很多问题。<br />1.代码未统一管理<br />2.demo没有页面支撑<br />3.缺少沟通<br />由于项目中期才采用scrum模型，现在发现以前很多东西到现在需要修补，比如E-R图。E-R图的不明确，造成各模块之间关联不明确。这个其实在设计阶段就应

<br /><br />review项目的需求文档是枯燥的，如何更好的理解需求文档是个思考的问题。<br />通过画原型图可以很好的理解需求文档，原型图，把需求直接转化为页面，给人以视觉上的感受，更加直接。<br />而且在画原型图，如果对需求不明确，是画不出来的。<br />原型图也可以细分需求文档，补充需求文档。<br />所以在需求PRD文档出来后，再画原型图，比较合适。

<br /><br />周六打了3个小时篮球，打到腿抽筋，周日逛了3个小时西溪湿地。今天上班明显状态不行，典型的周末综合症。<br />整理了项目的文档，也整理了下思绪。敏捷开发模型scrum已经在项目中慢慢的实施，通过对scrum理论的学习，并在项目中实践。<br />sprint1将在本周三结束。<br />离项目发布6月28号还有段时间，我把接下来的时间分为了5个sprint，每个sprint制定了story，周三后将于各模块负责人讨论是否可行。<br />每个sprint的开始，制定详细的目标，并与

<br />经过2个sprint，团队对迭代这种模式已经有了一定的认识，俗话说：计划赶不上变化。sprint3出现了一个很严重的问题，任务完成不了，只完成了既定任务的70%。<br />这或许是每个项目都能遇到的问题，在项目中，完成不了任务，理由总归很简单，没时间啊～时间紧啊～其他事情忙啊～～<br />完成不了任务，应该从两个方面进行考虑：<br />第一：是不是设定的任务太多了？<br />第二：项目组同学是不是很好很自觉的去完成任务？<br />首先，每个迭代的任务是每个同学自己申请的，根据scrum

<br /><br />历时2周的sprint2，结束了。从这次sprint的demo中发现，大家比sprint1明显进步很多。总体来说，sprint2达到了我的期望。<br />大家按照sprint开始既定的任务去完成。<br />不过也暴露出很多问题。<br />走远了，要想想为什么要出发？这句话，让我感触很深。是呀，从kick off到今天已经2个半月了。我们已经走得很远了，我们是不是按照既定的方向在前进，当初的需求是否被我们砍了很多？我们当初为啥要出发？？<br />在项目中不断的review需求和

离项目发布只剩下最后一个迭代了。要做的事还有很多，模块之间的联调，小细节的扫尾，等等。迭代5还算完成得不错。人啊～非到了最后关头才肯发力。迭代5这么多的任务居然绝大部分完成了。最令人高兴的事任务&场景模块在没有的情况下，已经建立起来了，这样PAP所有的模块已经建立起雏形。离胜利越来越近了。这个迭代，最大的收获是发现随着对开发的熟悉，框架的熟悉，大家的开发效率明显高于前面几个迭代。

2011年的上半年，我们伴随着PAP度过。2011的上半年，我们的工作因为PAP而变得丰富多彩。从3月15号立项，到7月19号发布，整整历时4个月。还不包括1月份和2月份的前期准备，技术调研工作。承蒙兄弟们看得起，第一次担任PM角色。从制定项目计划，到寻找资源，每一步迈得都是崭新

今天第一次开了sprint的回顾会议，整理了一个sprint中哪些做的不好？哪些做的好？从会议整体来说，效果还不错，一共整理了5条做的好了，比如：任务比以前更加细化了，会议的效率越来越高了，严格控制了会议时间。也整理了21条我们认为做的不好的地方。通过对21条不好的分析，我们提炼出优先级最高的5条。比如:任务还不够细化，不能很好的估算时间；开发代码质量不高；测试没有保证；相互等待，缺乏

今天结束了sprint 5 的第一周。sprint 5针对sprint 4 的进度滞后，做了一些小改动。估算一个星期的工作量。比如在一个星期内，能完成多少backlog。进行一个星期的测试，这样做的好处是大家能很好的完成backlog，没有出现sprint 4 时那种滞后的情况。暴露的问题是大家都很忙，赶着晚上加班。这不是我们所需要的。所以在第二周，任务的估算，将更加精确。减少团队晚上