提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 本次作业所属课程 | 北航软件工程2019 |
| 本次作业要求 | 要求详情 |
| 我在本课程的目标 | 回顾在软件工程课程中学到的东西 |
| 本次作业的帮助 | 回顾课程，总结经验 |
1、链接博客
2、对自己曾经提出的问题的解答
2.1 迷思之二：创新颠覆行业？
在创新这个点上我仍然坚持我提出这个疑问时候的观点：创新是为了我们的社会和时代向着未知的远方迈进，是给我们每个人带来越来越方便高质量生活的一条必经之路。尚且不说每个人都有如此高尚的道德品质与以人 类发展为目标的信仰，即使是为了利益，我认为当一个发明电报的人看到新发明电话的时候想的并不是恨。我相信每一个聪明人更多想到的应该是吸收与发展，因为他已经看清楚这个创新会颠覆目前的一切，所以会去支持并投入到这种创新之中。
2.2 迷思之七：成功的团队与SWOT分析框架的矛盾
我之前认为成功的团队中的专家是应该可以预测到一些颠覆性的技术或者创新的，但其实在一段时间的实践与了解之后我认为我们所谓专家的预测以及SWOT分析框架中的创新的招数都是针对一些比较常规的，按大众正常思维发展而来的“创新”，而那些具有划时代意义，颠覆性的技术创新的出现都是需要天时地利人和，很多方面的因素碰巧凑到一点的时候才会发生，所以两者也就不存在矛盾一说了。
2.3 划分产品与投入的四个象限
学长助教的评论使我明白了我在思考这个问题时候的局限性。10X原则的杀手功能与我自己想象的“普遍2X原则”问题上常会陷入“幸存者偏差”，即看到的“有很多好的软件在全方位的功能与体验上比竞争对手都要好出一个档次”是第二象限产品中一个很小的比例？而“只关注杀手功能”的软件的成功率（虽然由于其本身技术壁垒高因此数量可能较少）反而会更高。确实很多异军突起的产品更多被关注的是他们的闪光点，也就是“杀手功能”，显然那些进行产品开发的前辈们长期的实践经验得出的结论要比我的空谈空想可靠得多。
2.4 “萝卜快了不洗泥”or“慢工出细活”
这个问题其实在一开始我也是有自己的答案的，两种employee的区分是不同的人存在不同的性格以及不同的学习与成长环境造成的，两者都有各自的优缺点。在实际的软件工程工作中我们常常会遇到不同的开发需求情况，也会遇到各种各样不同的顾客，所以其实没必要去纠结这两种工作方式或者人才孰好孰坏。在不同的情况下他们都会发挥各自的作用，他们会被不同的顾客或者上级青睐，只要有能力保证最后产品的质量，两种过程只是个人喜好的不同罢了。
2.5 关于敏捷工程原则
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
3、学习过程中的“知识点”
需求
积极收集用户反馈，对需求功能划分优先级并实际一点
设计
一定要一个组的成员坐在一起头脑风暴，交换意见，才能决策出更好的计划与分工
实现
要留有一定的缓冲区，不要赶ddl实现
测试
开发者是最好的测试者，只有了解熟悉代码的人才能做好测试
发布
发布要尽早，而且表面功夫要做足
维护
产品维护很重要，而且在实践过程中甚至比实现还要费劲，但却是软件工程中跨度最长且最重要的一环
4、理解与心得
其实在这门课选择老师的时候以及了解到软件工程的构建式是三种软件工程中最硬核的，但由于其他两个形式都是今天新增加的，所以认为当前的模式还是比较成熟，故选择了构建式的软件工程。其实要说在程序方面比其他两类软件工程任务重也没有太多，只是多出了结对编程这一项。我认为这个环节既是我们的一个热身，又是一种新的编程形式的学习与熟悉。而之后的团队项目在内容上其实与其他的也差不了多少。我们这门课的特色就是“博客”，超大的博客量对于团队来说是一项不小的任务，在alpha阶段我担任的是队伍的前端人员，了解熟悉了安卓开发中前端的一些内容吧，但也只是针对于一个简单编辑器的修修改改，并没有过多承担开发的任务。在beta和gamma阶段我转换角色为团队的PM，新的角色意味着新的任务与挑战，在这个阶段从管理项目到产品发布，也是体会到了软件工程中不一样的一面。无论是担任什么角色，都让我学到了软件工程实战中的一些知识与经验，希望可以在我今后的学习与工作中回想起软件工程中学到的东西。
