标签：结束 解决 软件 老师 比较 sprint 学习 能力 哈哈
1. P144页，章节7.2.8 提到学习所有的经验 提到总结经验和经验分享是在每次里程碑结束时进行，我很疑惑，每天进行站立会议时，是不是也可以进行经验总结和分享？
2. P137页，章节7.2.3提到成员授权和信任问题。我的问题是在实际开发中，当项目开始前所信任的有能力干活的人中途离开了或者在开发过程中这个人遇到技术难题，长时间未解决，其他成员对这个人产生能力质疑时，如何解决这个问题？由谁来主导这个问题的解决？项目负责人?
3. P121页，章节6.2提到了长期任务，这种任务比较艰难且对项目又很重要，完成的时间超过Sprint的计划时间，邹老师对此只提到往往开发人员对此并不重视，并没提到如何较好的解决这类问题。我恩师常告诉我最难的那部分应该尽早去做，是不是对这“长期任务”也应该今早安排人来承担这部分责任？
4. P116页，章节6.1提到了在冲刺阶段只能由Scrum大师来与团队成员进行交流。我读到这部分时还在想Scrum Master?这是什么？然后在P122页找到了章节6.4第一段找到了解释。Scrum大师就是团队的PM。然而又能描述好需求，又能了解技术的这种PM太难找了。于是乎，就有了PM与程序猿的“斗争”。哈哈~
5. P128页，表6-3提到的敏捷的适用范围以及章节6.5敏捷的问答，我还是很难理解敏捷是什么？总是说敏捷流程，是不是做项目时，及早响应需求，尽快发布可用的软件，这就是敏捷的体验？
最后吐个槽，本想把第三版完整看一遍，结果实在没时间挤出来了。还好我提前勾画了问题，哈哈哈。第二次上软工，还有邹老师的构建之法越看越有味道。本科时的确没看明白。
标签：结束 解决 软件 老师 比较 sprint 学习 能力 哈哈
原文地址：http://www.cnblogs.com/ranh941/p/7507965.html
