标签：
今天先阅读了构建之法的敏捷流程的论述，在敏捷流程中开发人员可以很快交付给用户有价值放软件也可以很快知晓软件的欢迎需求变化，以此来增加竞争优势。在我看来，书上说的 “敏捷”，要团队的每个成员都有进取心，并且相互充分信任，在我们团队的开发过程中，我们每个人相互信任也有进取心，但是我们的水平参差不齐，比如我的水平就比较菜，所以我们的团队项目进度一直达不到理想的状态。
在每日例会上，我们的突破就很少，每天要解决的问题还是那些，久而久之我们的确感到有些厌烦。“只有关注技术和设计，才能越来越敏捷”，作者说的这句话真的是对我的讽刺，比如说我们要用到一个新的开发语句，我们就没有时间去仔细摸透它，这点我还是要反思的，为什么我的时间挤不出来，也许是自己的学习效率过低导致开始学习的时候就没啥信心往下去学习，还有一个原因是我们很难去静下心来看一个我们一无所知的知识，所以这一点也是我要去反思的地方。
怎么说呢，我们的团队虽然没有做到敏捷流程，但是还是按照其方法去努力的，所以说我们最后做完我们的团队任务的时候还是体会到了这样的方法的用处的。我们的团队很弱，强行把敏捷或者其他的高级方法套在上面会适得其反，所以我们在遇到难题的时候不追求敏捷，而是在一些细枝末节的地方追求敏捷，怎么说呢，现在回过头去看自己的开发过程真的收获了很多东西吧。在团队中，大家的明确分工决定了每个人有着每个人的责任和必须做好这件事的义务，一旦有一个人掉链子，整个团队交付的结果可能是非常糟糕的，所以我们会一起解决问题，打破职责界限这样我们的团队才没有明显的拖后腿的情况。
对于冲刺会议，我的确是想说，我们没有真正意义上的冲刺，我们的水平导致了我们心有余而力不足，老师说不要给自己打标签，我还是要说的，但是我认为这样的水平不足不会是长久的问题，我还有时间去不断完善自己。
标签：
原文地址：http://www.cnblogs.com/3066405538a/p/5606012.html
