提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 这个作业属于那个课程 | 班级博客 |
| 这个作业的要求在哪里 | 作业要求 |
| 第一次作业的链接 | 第一次博客作业 |
1. 对以前疑问的解答
问题一
原文出处：2.1.2 好的单元测试标准
这里作者给出了7条非常好的单元测试标准，但是在实际测试中，软件各色各样，难免会有其中两条标准之间无法很好的平衡。例如，一个庞大的软件工程，一方面要追求测试的全面行，一方面又要保障测试的速度，那么两者之间如何权衡。
回答：在实际测试发布的时候，团队会依照功能的轻重缓急做出权衡，优先对重要的功能做出全面的测试。所以很多软件发布时还会有很多残留的bug，要经过一遍遍的更新才能更加完善。
问题二
原文出处：我还建议，把所有开发过程的附加物件，像设计文档，都扔掉······SCRUM依赖于团队人员面对面，高容量的交流和合作；每个人独立的小隔间，没有必要的文档都增加了疏离和误解的可能性。
其中本书作者提到了如果团队成员在不同时区工作，就需要文档等辅助手段来达到敏捷的目的，但是敏捷原则中提到了“每天共同工作”，“保持简明，简化工作量”。我认为为了尽早并且持续的交付软件，文档的存在是会延误工程的推进的，撰写过程和阅读过程都是耗费时间的。这与敏捷原则相悖，所以我还是认为文档是不应当存在于敏捷流程的，而这种无法共同工作的成员也是不应当存在的。否则这种团队与非敏捷流程的区别又在哪里呢？
回答：设计文档可以让团队的开发流程更加清晰，在别人想要了解团队的工作时更加方便。所以说开发文档是必要的工作，不能没有。
问题三
原文出处：16.1.2 迷思之二 大家都喜欢创新
作者给出了与标题相反的观点，在看完之后，我茅塞顿开。回想从古至今，几乎各行各业，从皇帝到百姓，在创新时都会有触及到部分人了利益，想要让自己的创新得以实现，就要付出惨痛的代价。换而言之，大家不是都喜欢创新，而是喜欢能够对自己有利的创新。难道创新真的敌不过在前人基础上的线性扩展吗？
回答：在查找资料后发现，这个时代，想要在某些领域有突破性的进展几乎时不可能的，创新和改良已经逐渐同化，所有的创新几乎都是在巨人的肩膀上迈出的小小一步。
问题四
原文出处：16.1.4 迷思之四 创新者都是一马当先。
作者告诉我们几乎所有的先行者都葬身在了自己所探索的那片大海里，那还会有人愿意去进行创新吗？
回答：虽然创新的代价巨大，但不是说创新者永远都成不了领导者，创新者不但要有创新的勇气，更要有能沉下心好好观察的耐心，成功者不单单是靠着一腔热血，更是靠一直以来的积累。
问题五
原文出处：16.1.7 迷思之七 成功的团队更能创新。
作者告诉我们成功的团队需要满足董事会的需求，要不断的提升自己的业绩，但是身为行业的领导者，他们不会轻易的去冒险创新，将自己置于极大的不确定之中。那么成功的公司四如何在两者之间进行权衡。
回答：成功的大团队在看到机会时不会大脑发热就冲上去，而时在等其他团队厮杀完之后将潜力股收购，这样时风险最小的，也是成功团队在风险和收益中权衡的办法。
2.产生的新问题
1.在团队进行开发之前如何对工作进行合理的预估和分配？
2.建议与意见：开发者和管理者之间如何能很好的交流，交换意见。
3.软件工程中学到的知识
需求
了解用户需求是软件开发前的重中之重。
设计
在设计之前先做好调研工作，对将要使用的工具，开发模式详细了解之后才能更好设计开发。
实现
在开发的过程中要做好交流工作，有了交流开发才能顺利。
测试
测试阶段要全面，就算没能力修正完所有的BUG也要尽力测试出所有的BUG。
发布
推广工作要做好。
维护
收集用户反馈是维护的重要一环，有用户反馈可以更好的贴合用户需求。
4.个人理解与心得
个人项目
个人项目是我之前一直使用的开发模式，一个人从计划到开发再到测试都是一人完成，这样完成的最终项目虽然不会很庞大，但是在开发的过程中可以清楚的掌握开发情况，需要修改的地方也不用与他人讨论，只用自己决定即可。
结对项目
两人结对，分工合作就可以开发较大一点的项目了。但是两人之间要分工清楚，有问题要即使沟通，两个人的力量总比一个人大，主意总比一个人多。在两个人结对编程的过程中我与自己的小伙伴相互学习，相互帮助，有了很多收获。
团队项目
团队开发向我们展示了一个团队项目从选人，到设计，开发，测试，发布以及最后的维护阶段的整个过程，这些都是我之前没有接触过的事情。处于一个规模较大的段对是我之前重来没有过的体验，与他人分工，共同向一个目标奋斗。无论是每晚的例会，还是平时的相互帮助，我都感受到了成员们对与一起开发的热情，在一起开发的过程中相互学习到了很多。总而言之，这段宝贵的经历一定会成为我将来的开发经验。