个人作业-提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | |
| 这个作业的要求在哪里 | |
| 我在这个课程的目标是 | 增加开发项目具体经验，提高团队协作能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 团队协作回顾，软件工程理论 |
过往问题解答
问题一：是否应该鼓励降低开发用时的标准方差？
• 在软件工程师的成长这一章中，举了AI估计用时7天，实际用时1，9，11天的例子来说明成熟的工程师应该降低标准方差。其以标准方差作为任务交付的稳定度。
• 但若存在如下情况，AI实际用时1，7，8天，其方差依旧较大，但不是因为拖延，而是因为“技艺创新的大爆发”。在这种假设下，AI即使方差较大，其完成任务的能力也明显强于另一个人。我认为不应该一味地追求缩减方差，可以用标准天数和延期天数取而代之作为衡量一个人能力速度的标准。这样的标准会更加有代表性。
关于这个问题我认为评论的人说的比较有道理，这主要是一个稳定性和平均时间的评估效能问题，主要在意的是稳定快速地完成任务。如果真像我说的经常有灵感导致时间缩短，就应该适当性的调整时间使任务量、时间与这个人的能力相匹配。但我依旧认为用方差作为衡量标准不如标准天数和延期天数有代表性。
问题二：结对编程中二人互相适应的问题。
• 提到结对编程需要不时交换领航员和驾驶员，但是不同的人往往会有不同的编程习惯和思路，不仅是缩进等规范，还包括解决同一类问题的不同思路。如果不断交换双方角色，会不会导致代码的风格有差异，影响可读性，同时，一方需要花时间适应另一方的思路。
• 另外，我认为结对编程更有利于能力较差的同学学习，对于代码质量的提升并没有想象中的大。相反，若两方差距过大，容易造成基础差的同学跟不上思路，需要花大量时间学习而拖慢进度的局面。代码的整体布局也会由能力强的人确定，甚至不如单人编程。
在结对编程的过程中，实际上是按照代码块进行任务编程分配的，在实现某一个函数时A当领航员B作为驾驶员，在完成另一个函数时交换双方的角色。这样分配的话，实际上领航员不需要太过关注代码的实际编写，只需要保证理解代码排除可能的逻辑错误即可，并不会对工作时长有太大的影响，，也能适当减轻工作量，代码风格差异的影响不会特别大。相反，与每人仅关注于自身的模块只提供接口的方式相比，更能对整个程序有一个全面的了解。
本次的结对编程任务难度不大，所以并不能直观感受到水平差异对结对编程的影响，但我想结对时应尽量避免双方水平差异过大的情况。
问题三：如何看待用户的潜在需求？
关于用户需求的部分，本书中强调“准确而全面地找到这些需求”，但是有些情况需要“创造需求”。
• 比如《王者荣耀》，原先的电脑游戏侧重于操作体验，一开始想移植入手机的类似游戏把用户定位于原本电脑游戏的玩家，努力还原电脑操作。但是王者荣耀用其简化的操作，开发了原本没想过用手机玩游戏的潜在用户，若仅仅只按照“玩家”的用户需求来定制，则不会取得这么大的成功。
• 一些成功的商品，正是满足了潜在需求的产品，这种需求由于尚未被开发，很难通过调研找到（《王者荣耀》的许多玩家之前并不会觉得自己对这类游戏感兴趣）我们在制作产品的时候，是否该考虑这些潜在需求，又该怎么挖掘到用户的潜在需求呢？
事实上确实有许多用户不会主动想到自己究竟需要怎么样的服务，作为调研人员，我们应该主动去询问他们对于我们设想的潜在需求的看法，来调研这些设想是否真的有必要。比如王者荣耀可以去询问如果有一款比较简单又社交性强的游戏，他们是否愿意尝试。在实际的调查过程中，我们也是在询问用户需求外，特意询问了他们对于我们构想的新功能的看法。
问题四：敏捷开发中是否有必要解决所有bug？
• 在十五章中，提到了ZBB策略，即在这一版本构建把所有已知的bug全部解决，而本书在此之前也提到过“优秀的软件团队会发布有已知缺陷的软件”。
• 实际项目中我们也不能保证消除所有的bug，有些bug消除起来较难，需要改动的代码较多，而bug影响又小，在花费的时间和收获的效果不成正比的情况下，有些公司会对这些bug视若无睹，或者等到版本大更的时候考虑修复。追求修复所有bug反而有可能拖慢项目进度。在bug也不影响新功能的开发的情况下，ZBB可以选择留bug以保证项目进度吗
在我们的实际操作过程中，并没有遇到我所描述的难以消除且影响不大的bug，但是我们确实遇到了需要花很长时间才能解决的问题。在我们的敏捷开发中，由于要保证交付时间，我们选择先避开这个问题，用另一种方法解决问题。而ZBB策略中，我也没有改变自己的想法，虽然ZBB需要清零bug，但是团队在质量外也需要兼顾速度，偶尔遇到几个难以修复又影响不大的bug可以先不修复。
问题五：什么才是真正的“好想法”？
创新一章中有一个迷思即“好的想法会赢”，并举了键盘和国际单位制的例子，实际上这两个想法如出一辙，都是对现阶段使用习惯的改变，我并不认为有让人耳目一新的亮点。实际上我们应该对“好的想法”有个明确的定义，我们是否该将改变大众习惯纳入到减分的因素？如果是想法的优点、益处大于缺点，符合大众需求，符合时代潮流的才可以称得上是好的想法。
我没有改变我的想法，真正的好想法应该是在有足够基金和技术支持的情况下可以广泛被大众接受、喜爱的想法。而像例子中讲述的看似更合理但是由于要强行改变大众习惯，增加了学习成本，大多数人也不需要追求太高的打字速度，故例子中的并不是一个合格的好想法。
知识点
需求
在需求阶段，我们需要使用NABCD分析法对用户需求及行业现状有一个全面的分析。我们不仅需要去关注如何解决用户的需求，也需要关注其他竞争对手的产品情况，找出自己独特的优势点，和后续应该怎样推广才不至于无人问津。
设计
设计阶段我们是用设计文档进行实现的，在文档中插入了一些辅助图形。用文字进行设计太过单薄而且表达能力有限，在这上面用图片讲自己的构思画出来可以更好地讲述软件架构以及功能设计方面的想法。比如我们的event子节点实际是通过树的形式架构的，这种树的架构比较难想，就是需要通过图形讲出来的。
实现
我意识到每日例会进度管理上的重要性。在很多情况下，我们并不能很好地按时报告自己的进度，这导致了我们的积极性不是很高。若是项目进度延后，测试进度也会随之变慢，这时候就应该找出项目卡壳的地方，尽快修正计划，及时协商保证进度。
测试
测试总纲需要明确Why，What，Who，When，在测试代码之余，测试不同的运行环境也是很有必要的，我们有可能在一个手机的屏幕长宽比上使用合适，但是在另一个型号的手机上就会出现各种问题，苹果、安卓的差异会导致更大的问题。另外，对于环境的不同配置，如不同屏幕分辨率，网络速度以及这些的不同组合都需要进行综合考量。我们也使用了测试矩阵对这些信息进行了汇总。
发布
在发布前的最后阶段，我们学到了砍掉功能这一知识点。最后发现alpha阶段我们的软件在ios中运行出现了困难，所以我们不再纠结于在ios发布的相关事项，而是转而去关注其他bug的问题。在这种策略下我们并没有延误发布。
维护阶段
在维护阶段，我们需要对用户的反馈进行及时的反应，这就需要我们对于用户敞开反馈渠道，比如在应用商店中放上团队联系方式，或者在软件中内置反馈渠道等。用户的反馈通道敞开，我们才能更加快速、精准地改进。
心得与体会
这次的课程让我能从设计到发布维护完整的经历了两个开发阶段，我主要是与另外两个同学进行后端的开发，我们从了解技术栈开始，一点一点克服困难，完成程序的开发工作，在这期间我们遇到了数据库安装使用等问题，都一一有了对策。我也体会到了互帮互助，一起想办法解决困难的感觉。只可惜我们与同学的交流更多的是私下交流，组内一起讨论问题的机会十分优先。
