事后分析$\alpha$

项目	内容
课程：北航-2020-春-软件工程	博客园班级博客
要求	事后分析
我们在这个课程的目标是	提升团队管理及合作能力，开发一项满意的工程项目
这个作业在哪个具体方面帮助我们实现目标	组织组员对\(\alpha\)阶段的任务进行总结，对过去进行反思

VisualPytorch发布域名+双服务器如下：

http://nag.visualpytorch.top/static/ (对应114.115.148.27)

http://visualpytorch.top/static/ (对应39.97.209.22)

事后分析会图：

一、设想和目标

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

   在定义需求时，我们要解决的，是刚入门深度学习的初学者，缺乏一个良好、方便、直观的学习途径的问题。我们的目标，则是通过提供一个图形化的在线平台，用户可以通过拖拽的方法连成网络，或者使用我们提供的经典模型，自动生成程序，并且教初学者本地部署模型，加载数据并进行训练。

   总体而言，我们对典型用户和典型场景的定义描述还是比较清晰的。具体的描述在团队项目选择与功能规格说明书中。

2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

   在扩展模型的功能上，我们成功实现了对网络层的扩展，并且实现了模型保存的与预览的功能，还对界面进行了比较彻底的优化。不过，还是有一些功能上的目标没有完成，比如网络封装成基本模块的功能，由于前端jsplumb版本的限制没有实现，不过后端以及json接口定义都已准备好，计划于\(\beta\)阶段实现此功能。另外，经典模型也已经搭建完成，现保存在超级账号中，计划于\(\beta\)版本中实现对所有账号的开放。

   项目最终成功地按照原计划交付时间进行了交付，这归功于任务划分的科学性与我们组各个成员的个人积极性和良好的团队合作。

   项目最终并没有达到原计划的用户数量100人，仅仅达到了目标的三分之二。一方面，可能由于我们的项目正如一些同学的反馈所言，不是那么吸引人；另一方面，我们的宣传渠道并不广泛，只是在计算机学院的大群“SCSE1706菜市场”和软件工程的课程群进行了宣传。以“事后诸葛亮”的方式思考的话，可能是在我们6系中，对深度学习和pytorch有较深了解的学生，不太会对我们这样主要面向初学者的项目感兴趣；而对深度学习兴趣不大的人，则不太关注我们的项目（当然也有可能只是都不爱看群罢了）。

   总的来看，我们还是基本达成了目标的主要部分，但还有一些原本打算实现的目标被放弃或者没有达到。

3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

   项目目前处于\(\alpha\)阶段，我们也不是很清楚上一届团队工程化方法的执行情况，仅仅是看他们的博客，不好做一个比较。不过，就个人猜测而言，我们的软件工程质量应该还是和上一届有差距的，做这个判断的依据就是今年的新冠疫情。由于疫情原因，在整个开发阶段，团队都只能使用在线会议软件这种比较低效的方式来进行Scrum Meeting，冲刺阶段更是连找张桌子围在一起开发的机会都没有（虽然由于计划比较合理，我们也没太进行赶进度的冲刺），在很大程度上影响了一些工程化方法的实施。这个影响应该说在之前的结对项目中就已经可以感觉出来了。等到了\(\beta\)阶段，我们希望至少能够以自己为参照，在软件工程的质量上得到提高。虽然开会的方面没办法提升了，但可以在其他方面有所提高，例如目标的设置、计划的制订等等。

4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

   虽然用户量并没有达到预想的水平，但就反馈来看，用户对重要功能的接受程度还是达到了我们的预期的。因此，可以说我们确实是离目标更近了。

5. 有什么经验教训? 如果历史重来一遍，我们会做什么改进?

   假如重来一遍，我们可以考虑及时更改前端插件，完成更多的计划功能。另外的话，会考虑加快一下整体进度，同时优化分工，争取完成更多内容。

二、计划

1. 是否有充足的时间来做计划?

   计划阶段时间比较充足，也开了数次网络会议进行讨论。

2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

   其实总的来说，对于计划的意见都比较明确，而且由于分工比较早而且重叠的部分不多，即使有改进，也基本上是在自己的分工内进行的改进，意见的冲突并不多。如果遇到这种问题，一般都是在开会时就予以解决，通过讨论来尽量达成一致，最终的决定权在PM手上。

3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

   除了前面提到的内容以外都做完了。没做完的原因也提到了，主要还是卡在了前端插件上。

4. 有没有发现你做了一些事后看来没必要或没多大价值的事?

   暂时没有。就目前来看，即使在现在的版本中没有利用上的代码和接口定义，也是为\(\beta\)版本的开发做准备的。至于这些代码以后会发挥多大的作用，要在下一个版本中进行验证。

5. 是否每一项任务都有清楚定义和衡量的交付件?

   除了一些学习性质的任务外，都有比较清楚的定义和衡量的交付件，一般都是实现网页的某项改进/某个功能，前端和后端都是如此。

6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

   项目的整个过程基本是按照计划进行的，但也出现了一些意外，比如前后端之间可能因为沟通不够，已经对git运用不熟练导致代码版本控制不当，出现接口对接不上的问题，使得某些功能无法正常工作，例如加载已保存模型。不过这种开发人员内部问题带来的风险并不算大，因为很快可以通过及时沟通和debug来解决。从去年学长的对Visual Pytorch的开发经历来看，开发中有可能遭遇到更严重的问题，包括但不限于服务器被黑掉。这样的风险在接下来的开发中务必要重视，并采取备份等方法予以防范。

7. 在计划中有没有留下缓冲区，缓冲区有作用么?

   在计划中基本没留下缓冲区，不过计划整体而言时间划分还是比较充裕和宽松的，不太存在计划在规定时间内无法完成的情况。

8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

   将来的计划中，可能会涉及到更为复杂的开发内容，从这个角度考虑，应该设置一定的缓冲区，并且尽量细化项目的时间指标，比如设置期望完成时间和最晚完成时间。至于加班的问题，就需要确保在遇到问题时，前后端至少各有一人能及时进行反馈。

9. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

   在计划部分，我们学到了如何将一项大的工程拆分成小的开发项目进行敏捷开发。如果历史重来一遍，我们会让每个开发项目的要求变得更为细致，尽可能每天都能完成至少一个小项目。

三、资源

1. 我们有足够的资源来完成各项任务么?
   
   已有资源：静态资源与服务器我们都已经拿到；有两个星期的开发时间。
   
   不足资源：时间不太够用，使得完成的功能不能达到预期的需求；1核1G服务器的配置不太够用，许多期待完成的功能（如在线运行代码）不能完成；同时中途两位同学参与度不高也成为了我们缺乏人手的窘况。

2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
   
   估计是按照我们以前的开发经验。做这样的估计其实是存在较大偏差的，因为具体解决问题的时间包含了学习新知识，一边学习一边开发很难在一开始就明确估计到所需要的时间。

3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
   
   资源是足够的。我们本身就非常重视美工与设计，知道这是很重要很费时的一部分，所以不存在低估。

4. 你有没有感到你做的事情可以让别人来做（更有效率）?有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
   
   我们做事情都是分工来做的，在具体操作过程中，分工的问题就存在比较模糊的界限。我们最终商议还是会根据对所做模块的专业性来进行分工。我们前段时间遇到了一个具体的问题：前端的表单需要校验，但是我们不知道需要向后端传送怎样的数据。校验问题本来是前端来做，但是我们要求后端提供具体的正则表达式来帮助前端进行校验，这就是一个专业的人做专业的事较好的例子。

四、变更管理

不存在人员上的变更，仅有工作内容的变更。

1. 每个相关的员工都及时知道了变更的消息?
   
   暂无变更。由于大家基本上每两天就又一次会议，小道消息传播得比较快。

2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
   
   在群里讨论技术细节和时间，如果条件允许就做，不允许就不做。比如“支持网络层封装”的功能因为时间不允许就推迟了。

3. 项目的出口条件（Exit Criteria）是否得到清晰的定义?
   
   功能都完成了就算出口了。但是说实在的，在这个项目里面我们没有用到太多。

4. 对于可能的变更是否能制定应急计划?
   
   基本没有，大多时候由PM单独找人或自己完成应急工作。

5. 员工是否能够有效地处理意料之外的工作请求？
   
   能。规定所有请求都转到PM那里处理，这样减轻了开发人员的压力，让他们能集中精力在自己那一亩三分地上。

五、设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
   
   总体设计工作是由PM在第一次scrum meeting前完成。PM监督整个设计阶段并最了解需求，所以是合适的时间和合适的人。

2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
   
   遇到过，例如前后端对于接口文档的认识分歧导致写法不统一，解决方法是在对接时相互协商解决。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
   
   在设计阶段我们画了网站的视觉图来帮助前端设计，后端部分在编写代码生成函数时运用了单元测试验证代码的有效性，并使用了python的coverage库进行代码覆盖率检查，其他使用的工具包括github等，这些工具有效的加快了团队开发的速度。

4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
   
   前端画布部分存在较多BUG。原因是前端参数和网络层模块非常多，并且对大小写和内容格式有严格要求，在阅读设计文档时容易看错并产生编写错误。同时在图像展示方面与文字有时难以兼容，出现了较多显示BUG。

5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
   
   代码复审主要由每个模块负责的同学自己进行，总体而言不太严格，需要在下一阶段增加相应制度保证工程质量。

6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
   
   应由测试引导项目的开发，并且设计应该更加清晰明确。如果重来一遍，我们会花更多时间完善设计文档，并且在项目开发时编写更多测试用例。

六、测试/发布

1. 团队是否有一个测试计划？为什么没有？
   
   有，每个团队成员对自己负责的代码进行单元测试，并模仿真实用户使用网站功能进行测试。

2. 是否进行了正式的验收测试？
   
   没有一个总体的验收测试，主要由各自分别进行。原因是大家经验不够丰富，需要在下一阶段完善此方面。

3. 团队是否有测试工具来帮助测试？
   
   使用了coverage、unittest和pycharm、spyder自带的测试工具帮助测试。

4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
   
   每个开发人员通过使用网站对最终成品进行黑盒测试，测试结果直接反映了实际运行结果，同时前后端分别进行单元测试和代码覆盖率检查。这些测试工作有效消除了工程中的大量BUG。可以通过增加单元测试案例以及前后端交互测试等内容进一步丰富测试过程。

5. 在发布的过程中发现了哪些意外问题？
   
   服务器部署过程还是挺费事的，与本地运行不同，在服务器上部署需要比较熟悉linux，并且学习nginx、uwsgi的交互方式。两位组员在去年以外学长的帮助下花了2天完成了部署工作。部署过程中还发现了意想不到的bug，如页面跳转出错。

发布到同学群中时，发现红包被抢得差不多了，但是网站的访问量和使用情况增长不大，这还是对我们沉重的打击。

1. 我们学到了什么? 如果重来一遍, 我们会做什么改进?

学习到了各类测试工具的使用方法以及测试案例的编写。如果重来一遍，我们会把测试做得更充分，并制定一个更加完善的测试计划。

七、团队的角色，管理，合作

1. 团队的每个角色是如何确定的，是不是人尽其才？

   首先将队员按意愿分为前端和后端两类，对于界面、javascript比较熟悉的去了前端，对于python或者pytorch比较熟悉的人去了后端。

   在前端和后端都发布了任务的拆解，基本上是按意愿去认领对应的工作的，认领和分配的工作都是各自擅长的一块。因此很大程度上都能发挥各自的特长，可以说做到了人尽其才。

2. 团队成员之间有互相帮助么？

   有。因为有些工作一个人做起来比较耗时耗力，并且两个人一起做时会考虑得更加全面。因此在许多任务上，尤其和集成、部署相关的任务，均为多人协作完成，在任务过程中类似于结队项目一样紧密交流。

3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？

   出现项目及合作的矛盾和冲突时，交由PM对问题进行协调。在会议上组织讨论相关问题的解决方法，并安排具体到人去解决相关问题。

八、总结

1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

   处于可重复级。建立了基本的管理制度和规程，管理工作有章可循。 初步实现标准化，开发工作比较好地按标准实施。变更依法进行，做到基线化，稳定可跟踪，新项目的计划和管理基于过去的实践经验，具有重复以前成功项目的环境和条件。

2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

   处于磨合与规范之间，小组通过alpha阶段的磨合正逐步朝规范化前进。

3. 你觉得团队在这个里程碑相比前一个里程碑有什么改进?

   在规范化管理代码与分工上有着不错的提升。

4. 你觉得目前最需要改进的一个方面是什么?

   对于Github与Git的一些功能使用还有不足之处，代码签入流程也有值得改进的地方，尤其是测试部分。

5. 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

   • 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

   • 团队每天都会有新的代码签入，在学习阶段结束后，保持了快速稳定的开发速度。

   • 团队定时总结如何提高效率, 并付诸行动。

   • 每周三周五周日均有团队会议，对开发进行总结与展望。

下一阶段应该如何提高软件工程的质量

1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
   
   代码管理将延续现有体系，但在审核上需要更为严格。
   
   alpha阶段有多次因对git操作不熟悉而导致冲突的情况。在撰写了相应文档的前提下，这种错误的出现是不应当的。
   
   由于开发人数相对其他组较少，且不能面对面工作，因此复审只能靠个人进行。代码规范方面，则继续遵循相应文档即可。

2. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
   
   通过重构的方法来提高工程质量，是一种不得已而为之的方式，耗时耗力，还会大幅度地延缓项目进度。局部的重构是可以接受的，但项目整体的框架，是一开始就设计好的。

3. 其它软件工具的应用，应该如何提高？
   
   目前使用pycharm/sublime/postman/spyder/coverage/unittest等工具，足以支持开发。beta阶段的开发任务应该也能被这些工具cover。

4. 项目管理有哪些具体的提高？
   
   此前issue并没有实际投入使用，beta阶段会严格安装issue拆解执行。

5. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
   
   通过专门的前端页面读取后端数据信息。暂时没有需要提高的地方。

6. 项目文档的质量如何提高？

现有的文档已经较为详细，详见项目展示——文档与规范。下一阶段可能会根据迭代的功能进一步细化文档。

1. 对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
   
   事实上作为PM并没有太多的权力，反而有太多需要承担的责任，使得任务量太重：

• 本组7人中有一名同学4月下旬才拿到电脑参与实际开发，另一名同学则从第一次会议后渺无声息
• 使得人手不足很多任务不能按照预期要求开发。许多任务都交由PM手上
• 为了与那两位同学交流，PM也花费了较大的时间成本去与两位同学交流
• 要说这是PM的过错也不太合理，更多的是两位同学个人的原因

1. 对于软件工程的理论，规律有什么心得体会或不同意见？ （期中作业见个人博客）

心得体会见项目展示——每人总结

对比敏捷的原则，你觉得你们小组做得最好的是什么？

• 尽早并持续地交付有价值的软件以满足客户的要求
  
  项目早期交付的版本只实现了主体的功能和一些简单的辅助版本，保证项目尽早、如期的上线。我们提供了客户评论和反馈区，可以实时有效地收到用户的意见，然后根据原定计划结合客户的意见修改项目，持续地交付有价值的软件。
• 敏感流程欢迎需求的变化，并利用这种变化来提高客户的竞争优势
  
  结合收到的用户的反馈来修改项目，可以更好地掌握客户当前的需求是什么，根据用户的需求来改进项目，当需求发生变化时，也可以项目及时改进来跟上用户需求的改变
• 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短
  
  项目在发布之后，会定期根据客户的反馈增加相应辅助功能以及修复客户使用时出现的一些bug，保证定期不间断更新，保证用户的体验。
• 可用的软件是衡量项目进展的主要指标
  
  我们组首先实现项目的主体功能，在内部自测通过之后保证主体功能没有bug之后，立即发布上线，在后续，按照原先的计划结合客户的反馈不断更新，保证了项目进展如期有条不紊地推进。
• 无论团队内外，面对面的交流始终是最有效的沟通方式
  
  由于处于疫情期间，面对面交流很困难。我们的团队每周定期三次在腾讯会议上开线上会议，这样的形式可能效果不如面对面交流，但我们认为这是疫情期间最好的会议交流形式。
• 以有进取心的人为项目核心，充分支持信任他们
  
  不多说了，pm牛逼，前端牛逼，后端牛逼。
• 只有能自我管理的团队才能创造优秀的架构、需求和设计
  
  我们组内采用明确的评分机制，每人每天都要填写当天的工作进度，根据每个人的工作量以及工作的完成质量，用预先组内共同商定的计算算法计算每人的得分，保证了组员有劳有得，只有公平的分数分配才能激励成员更好的完成工作

什么是在下个阶段要改进的地方？越具体越好。

要改进的地方详见项目展示——Beta阶段大体计划。具体内容见：功能设计

新增的功能

• 邮箱验证
• 帮助文档导航栏
• 问题反馈支持图片
• 静态资源的整合
• 模型市场
• 经典模型
• 模型共享
• 模型推理
• 模型参数分析与可视化

修复的bug

• 前端可视化优化
• 界面切换时存在的跳转错误问题