软工网络15个人作业4——alpha阶段个人总结

一、个人总结

在alpha 结束之后， 每位同学写一篇个人博客， 总结自己的alpha 过程；

请用自我评价表：http://www.cnblogs.com/xinz/p/3852177.html 有比较才会有进步。

类别	具体技能和面试问题	现在的回答(大三下)
语言	最拿手的计算机语言之一,代码量多少? (偏web前端，PC/Mobile App)	html，代码量为3000
语言	最拿手的计算机语言之二，代码量多少? (偏后端，数据处理，网站后台，机器学习	C，代码量为4000
软件实现	(阅读代码的能力，实现，单元测试) 1、你有没有在别人代码的基础上改进，你是怎么读懂别人的代码的？ 2、你采取了什么办法来保证你的新功能不会影响原来的功能? 3、你在开发中碰到最复杂的bug是什么，你是如何解决的? 4、这个bug出现的原因是什么，你在将来应该怎么去避免bug再出现?	1、印象中没有，因为很不喜欢看别人的代码，有的是会片段的学习 2、逐字逐句的推敲研究 3、代码上要注意分块隔开，变量上的名称有意义不覆盖，在增加了一个新功能的同时要去检查一下原来的功能受到影响，避免后面堆杂 4、从后端传入的js语言的数据要进行提取并放到框架中，还要保证相同日期的日期显示只显示一条，通过慢慢调试，网上找类似的案例分析解决 5、出现的原因是对js语言的不了解，对列表数据填充的知识了解不够深入，将来需要多接触这些语言并结合使用，熟能生巧
软件测试	(测试方法、测试工具、测试实践、代码覆盖率) 1、你如何测试你自己写的代码? 2、你如何测试别人的代码? 3、你掌握了多少种测试工具和方法? 4、你写过测试工具么? 5、你如何对一个网站进行压力测试和效能测试? 6、你如何测试一个软件的人机界面(UX/UI)？	1、编写测试代码进行测试 2、直接运行进行大数据测试 3、微信小程序平台的测试工具，测试方法只会测试代码测试 4、没有啊 5、多人同时访问进行压力测试，效能测试主要看运行的速度和服务器的响应速度 6、主要是通过一个美观和使用操作的情况进行测试的
效能分析	效能分析，效能改进 1、你写过的最复杂的代码是什么? 2、你是如何测量和改进它的效能的，用了什么工具，如何分析的?	1、算法课的结课代码，是一个寻找凸包的程序 2、大数据冲击，当时才不懂什么测试工具呢
需求分析	(需求分析，典型用户，场景，创新) 1、你做过多少个有实际用户的项目,用户最多有多少? 2、你的项目有什么创新的地方?	（哭泣）没有做过实际的项目
行业洞察	1、你最感兴趣的领域是什么? 2、这个领域过去10年经历了哪些创新? 3、你分析过这个领域前10名产品么?请分析一下他们的优劣 4、你要进入这个领域，应该如何创新?	1、最感兴趣的是AR 2、这个领域算是比较新的行业，产品从早教到导航都有涉及 3、没有分析过，但是AR产品在导航方面做的比较一般，比较多的是红包和早教产品 4、创新的话可以考虑在什么方面很好的利用AR这个技术并且投入使用的可能性最大
项目管理	1、你参与过项目管理么?请描述一下两个当下流行的开发方法在你的项目中的具体应用情况 2、请问你如何决定项目中各种任务的优先次序，有什么理论来支持你的做法 3、如果你突然发现项目不能按时完成，你作为项目领导，有什么办法?	没有参加过项目管理
软件设计	1、你做过架构设计，模块化设计,接口设计么? 2、请说明一下你为何是这样设计 3、你比较过什么不同的设计方式，你的设计取得了什么结果?	1、模块化设计 2、模块化设计不仅是方便自己对代码的审核和查阅，并且对于纠错也比较容易 3、如果不使用模块化设计，你的代码看起来将会毫无逻辑性可言，杂乱无章，自己都看不下去
质量意识	(代码复审/代码规范/代码质量) 1、你是怎么做代码复审的 2、你加入我们团队后，能帮我们提高代码质量么，请具体说怎么提高?	1、主要是通过自己复审和同伴复审 2、可以，通过审核代码的规范性和可行性来提高代码的质量
工具/社区	Software Tools (performance tool, verslon control, work item, TFS) 1、你在各种开发平台(web, linux, PC, mobile, machine learning) 都使用过什么样的工具 2、自己写过什么工具来改进工作效率? 3、给社区贡献过什么工具和代码? 4、 Github有分享代码么? 5、你写的技术博客坚持了多久，读者最多的是哪一篇?	1、不晓得编译环境算不算得上呀 2、没有自己写过工具 3、没有给社区贡献过什么工具和代码 4、没有使用github 5、学习java时写过一学期，再次接触就是这次的软工了，读者最多的一篇不是因为质量好，而是因为提交的早
团队协作	Work with others (协同工作，提供反馈， 说服别人) 1、请描述你在项目中如何说服同伴采用你提出的更好的解决方案，或者你如何听取，了别人的意见，改进了自己的方案? 2、你如何说服懒惰的同伴加紧工作，实现团队的目标?	1、有想法的时候就会提出来，如果大家都觉得好就会认同这个idea，不认同的话我会听别人的意见，确定自己的想法确实存在不够好的地方 2、在团队中我们是约定好时间一起办事的，实在没办法一起参与的就会自行安排时间，并且在这个团队中我发现我的同伴都是比我要勤快的
理论素养	你上过什么数学，计算机或其他理论课，请举出具体的例子，说明你学到的理论知识如何帮助你解决实际问题。	数学这门课好像没发现在实际中有什么用处，计算机的课程主要是教你一种编程的思想，这种思想在实际中是可以通用的，很培养人的耐心啊
自我管理	1、全年级你专业排名多少? 2、你从刚入学(大学年级)到现在的排名有变化么? 3、如何解释你的排名的变化?	1、2030左右吧 2、没什么变化啊，都差不多

二、回答问题

我们在课程开始之初，曾经要求大家针对软件工程提出问题：个人阅读作业2，那么在经过alpha阶段，大家是否对软件工程有了一定的

了解？请结合自己提出的问题进行回答

Q1：

单元测试必须由最熟悉代码的人（程序的作者）来写。
测试的运行、通过、失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性。
--引用自《构建之法-第二版》

• 看到第二章个人技术和流程这一块时，里面讲到单元测试对于一个程序能够有完美的开端是必不可少的，特别是阅读到上面所写的这边时，我就产生了疑惑，在我的切身经验中，我一开始写代码的时候，并未能对自己的代码构思产生质疑，而作者提到最好能在设计的时候就写好单元测试，是指说当我完成一部分功能时就应该进行单元测试吗？比如说我之前java的课设就是写的四则运算，就事先考虑了我这个程序要有的功能有什么然后进行编写，到最后才进行测试，那我只能在代码都完成的时候进行调试了。然后我觉得单元测试是应该由程序的作者来写，但是测试的时候可以由他人进行，因为我在自己写的时候会陷入自己的固有思维而有很多误区都没有考虑到。然后是我觉得单元测试是不是可以在开发的过程中适当的随情来减少，如果是一些特别笃定不会有问题产生的地方可不可以省去这个步骤，而不会在这个过程带来繁琐的负担。

答：在alpha阶段的开发中，其实我们并没有精力去进行什么单元的测试，我们直接在微信开发平台里面编写直接调试，并且没有进行什么代码的构思，当然这也是因为在这次的开发中没有用到而已，在之后的项目中我觉得代码测试还是特别有必要的，并且是在你完成一部分功能就进行测试为好，因为那样子才不会对你之后的进程有牵绊。整体的代码需要在一开始就有一个大概的构思，然后进行模块的划分，不要边写边研究，会很乱

Q2：

主治医师模式：首席程序员负责处理主要模块的设计和编码，其他成员从各个角度支持他的工作（后备程序员、系统管理员、工具开发、编程语言专家、业务专家）。
业余剧团模式：团队在每一个项目中，不同的人会挑选不同的角色，在下一个剧目中，这些人也许会换一个完全不同的角色类型，个人在团队中听从一个中央指挥的指导和安排。
交响乐队模式：家伙多，门类齐全，演奏都靠谱，同时看指挥。
--引用自《构建之法-软件团队的模式》

• 上面讲到了很多种软件团队的合作模式，我从中总结了一个团队合作中特别必要的人员就是总指挥，不管是在主治医师模式还是交响乐队模式，甚至是在官僚模式中都是需要这么一个大佬来掌握全军的进程并随时监督和检查。虽然选择什么样的团队模式都是因人而异还要考虑项目的各个需求，但是我想的是如果能结合上面几种模式，未免不是一种适应性较高的团队模式，这种模式需要一个全能的并且有指导性的大佬，由他来进行团队成员的能力分析和为整个项目做一个整体的规划，然后由其他成员进行配合工作来完成。就比如我们的结对编程也是可以的，总是开始于一个比较有想法的大佬提出，当然在这个过程中成员对此有任何意见都是可以协商的，最后由大家各司其职来完成这个项目。

答：其实每个团队都有他们独特的团队模式，所有几乎没有哪一种特别固定的什么主治医师模式还是交响乐队模式可以一以概括的，并且这个和团队成员之间的协作力、调度力、执行力都有很大的关系

Q3:

敏捷开发的原则：
1、尽早并持续的交付有价值的软件以满足顾客需求；
...
5、以有进取心的人为项目核心，充分支持信任他们；
...
12、时时总结如何提高团队效率，并付诸行动。
--引用自《构建之法-敏捷流程》

• 敏捷流程是一系列价值观和方法论的集合，从理论上来看，这个方法论是完美的，但是我比较疑惑的是上面的几点。原则上敏捷的开发说是以有进取心的人为核心，并且要充分的信任他们。有进取心是必然的，若核心都没办法严格苛求那整个团队必然会受其拖怠影响，但是充分的信任他们我不是很赞同，就算是大佬也会有错判之时。还有一点是，原则上提到要时时总结如何提高团队的效率，提出这个的目的是为了跟进团队的质量，在总结以往的正确或是错误经验来进行调整，但是我觉得如何在段时间内最有效的总结出经验才是最可观的，每日的例会总结可能会带来负面的影响，有人因为交差而不符合客观事实的提出问题，不仅浪费时间还有可能使总路线方针偏离。

答：我们团队在敏捷开发的原则上可以说是完美的诠释了“以有进取心的人为核心，并且充分的信任他们”这一原则，因为在一个团队中你会发现PM的带动作用是特别强大的，充分的信任是必须做到的，并且不是说一昧的苟同观点，而是对一系列任务的安排都必须严格的按她说的进行，如果有什么问题上需要商量的可以提出来大家一起解决

Q4:

功能的定位和优先级
杀手功能：OCR文字识别技术，可以在屏幕上取词解释，拥有独家权威词典；
外围功能：良好的界面设计，在各个平台上都能运行；
必要需求：单词的短语释义的准确性；
辅助需求：可以做各种皮肤；
功能分析的四个象限可以让我们决定怎么处理不同类型的功能，重要的是，倾斜到可以产生差异化和独特用户价值的地方。
--引用自《构建之法-需求分析》

• 这里说到对用户的需求分析后重点将软件服务倾斜到可以产生差异化和独特用户价值的地方，这里的差异化是具有别具一格的功能特色和用户体验，这里就是所谓的杀手功能，可是在这之前我认为应该还需要考虑的是需求人群，是学生还是大龄人还是适用于面向全体人群的软件应用。假若这项服务是为了满足用户额外的娱乐，那么应该将重点同时放置于这里所说的辅助需求和杀手功能，就比如绝地求生和荒野行动这两款手游，不一样的用户体验（画质感）和占用的空间大小或者流畅度都会直接影响了市场。

答：考虑杀手功能的前提之上本身就是建立在你确定了用户人群了，确定一个项目的同时就已经很自然的确定了这个项目所面向的人群。

Q5:

分而治之
一个团队项目要在一段时间内完成诸多任务，满足用户的需求，实现团队的目标，同时还希望项目能维持良好的技术架构，从哪里入手?
--引用自《构建之法-WBS》

• 在构建WBS树时，选择从结果出发构建WBS树，而不是从团队的活动出发是什么用意？WBS树的构建是为了将项目分解成小型块以方便开发团队进行分工还是主要是给产品的接收方或利益相关者看的？我在360百科中查询到说工作包(work package)是WBS的最底层元素，一般的工作包是最小的"可交付成果"，因此一个用于项目管理的WBS必须被分解到工作包层次才能够使其成为一个有效的管理工具，这也就是叶子节点了，但是如果叶子节点特别小只需要短时间就可以完成，那可以将上一层结点作为叶子节点吗？

答：用意是为了不让我们团队在项目开发的过程中偏离轨道，从结果出发去构建WBS树能更好的建立一个好的出发点。工作包的最小的叶子节点，即使是再细小的任务也应当做为叶子节点。

三、再提问题

同时，大家一定会在实践过程中产生更多问题， 结合你的读书（教材，博客，参考书）， 实践， 再提出关于软件工程的 5 个问题。

Q1：

敏捷流程第三步：冲刺
--引用自《构建之法P107》

• 在alpha阶段进行七天冲刺时，我们在开始的第一天将第七天的任务都安排好了，但是我们发现很多任务的量实现安排过多，导致我们没有办法对看板进行一个很合理的安排，到后面的燃尽图也是奇奇怪怪的，甚至有的任务因为时间紧迫被删除，想问当遇到这种情况怎么办，如何在一开始就对我们整个大的流程有一个比较细致合理的安排

Q2：

两人合作：
两个工程师在一起，做的最多的事情就是“看代码”
--引用自《构建之法P59》

• 我觉得两个人之间的合作更多的时间是花在了如何安排任务，我想问的是如何安排任务才能尽善尽美，又能考虑各自的擅长之处又不会有任务量的差别

Q3：

-在实际的开发过程中，我发现课本上很多知识理论和团队理念似乎都没有用到我们实际的开发中去，博客是一直进行，也一直在教我们运用书本，可是好像变成了一种交付式的任务，想问一下这个是不是我们的课题选的不够很好的将实践与理论相结合？还是说是我们的时间不够充足去体会这个过程

Q4：

软件测试：
-引用自《构建之法P270》

• 测试需要从用户角度出发，那可以不用写规格说明书和测试文档了吗

Q5：

MSF
保持敏捷，预期和适应变化

• 在alpha阶段中我们就出现了当质量和功能相互冲突的时候，想把质量完善了，但是局限于这个问题整个团队的进度就会被拉开，这时候可以放弃一些质量来进行功能的继续吗