事后分析$\beta$

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

VisualPytorch beta发布了！

功能概述：通过可视化拖拽网络层方式搭建模型，可选择不同数据集、损失函数、优化器生成可运行pytorch代码

扩展功能：1. 模型搭建支持模块的嵌套；2. 模型市场中能共享及克隆模型；3. 模型推理助你直观的感受神经网络在语义分割、目标探测上的威力；4.添加图像增强、快速入门、参数弹窗等辅助性功能

修复缺陷：1.大幅改进UI界面，提升用户体验；2.修改注销不跳转、图片丢失等已知缺陷；3.实现双服务器访问，缓解访问压力

访问地址：http://visualpytorch.top/static 或 http://114.115.148.27/static

发布声明详见：https://www.cnblogs.com/NAG2020/p/13030602.html

事后分析会图：

一、设想和目标

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

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

   在\(\beta\)版本，我们新增了模型市场和模型推理两大功能，其目的和\(\alpha\)版本的需求分析也是相符合的。创建模型中将已有模型作为模块插入的功能，也是在\(\alpha\)版本中就做了铺垫，在\(\beta\)版本中去实现的。

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

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

   在\(\beta\)版本中，我们实现了包括上一版本遗留的功能在内的全部主要功能，包括模型市场、模型推理和在模型中插入自定义模型的功能。除此之外，还完成了对帮助文档、导航栏等细节的优化。还有一些没有实现的功能，比如为模型市场的模型增加点赞数、浏览量等功能，因为实现的价值不大，加上临近期末时间上的不足而放弃掉了。

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

   这一次，项目成功达到了预期的用户数量和模型访问量，一定程度上证明了我们所做的需求分析和功能优化在方向上的正确性。

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

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

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

   目前还没有接到用户的反馈，后续我们将会结合助教和互评意见进行分析。不过\(\alpha\)阶段用户反馈的一些问题得到了改进。总体来说，我们离目标肯定是更近了。

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

   假如重来一遍，我们可以考虑任务的布置与进度安排问题，并且尽可能在接近期末的阶段留出更充足的缓冲时间。

二、计划

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

   计划阶段时间比较充足，也开了数次网络会议进行讨论。\(\beta\)阶段的计划时间大概为1周。

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

   和上一阶段基本是一样的模式，在大家都发表对于某一功能的意见后，通过讨论来尽量达成一致，由PM拍板决定。不过总体来说大家的意见冲突并不算多。

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

   基本都做完了，一些没做完的内容主要是因为觉得实现的价值不大，所以经过讨论后中途就放弃了。

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

   现在看起来应该是没有的。

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

   任务的定义都很清楚，在GitHub的issue中 详细描述了每一项任务的要求，以及最终要达到的目标。

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

   项目的开发过程基本都是按照计划进行的，要说勉强称为意外的，也就是一些功能因为存在bug的原因没办法及时完成，但也很快想到了其他的替代办法（利用已有的可用接口）实现了这些功能。由于\(\alpha\)阶段的开发积累了很多经验，在\(\beta\)阶段中并没有遇到什么没有估计到的风险。可以说，一切基本在计划之中。

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

   计划中留下了一些缓冲区，基本上确保了整个软件开发的有序进行，同时也没出现因为一个功能实现不了而导致整个项目进度卡很长时间这样的情况。

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

   将来的计划中，应该考虑调整缓冲区，并且尽量细化项目的验收指标，更精确地描述项目的期望功能，最好做到规格化描述。至于加班的问题，需要确保在遇到问题时，前后端至少各有一人能及时进行反馈。

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

   在计划部分，我们学到了如何将一项大的工程拆分成小的开发项目进行敏捷开发。如果历史重来一遍，我们会考虑提高成员之间的沟通性，增进交流，更快速地解决可能遇到的bug等问题。

三、资源

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

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

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

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

四、变更管理

人员变更上，在\(\alpha\)阶段结束后按照课程规定进行了强制换人；工作内容变更上，通过石墨文档和GitHub的issue对工作内容进行通知。

1. 每个相关的员工都及时知道了变更的消息?
   
   是的，开会比较及时，并且\(\beta\)阶段直接建了一个新的微信群。GitHub中的issue变更时，被assigned的成员会收到相应邮件。

2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
   
   在群里讨论技术细节和时间，如果条件允许就做，不允许就不做。比如“模型市场三个参数”的功能因为时间不允许，加上实现的必要性不大，就放弃了。

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

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

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

五、设计/实现

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

2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
   
   相比\(\alpha\)阶段，这一阶段基本没有出现这种情况。

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

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

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

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

六、测试/发布

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

2. 是否进行了正式的验收测试？
   
   没有一个总体的验收测试，主要由各自分别进行。

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

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

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

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

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

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

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

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

   在\(\beta\)阶段，基于\(\alpha\)阶段的前后端人员划分，首先按照要开发的功能将成员划分为三组，并且每组都有一名前端开发和一名后端开发，使得各自工作可以相对独立地开展，还可以让每组采用结对编程的方法进一步提升效率。

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. 项目管理有哪些具体的提高？
   
   beta阶段会按照issue拆解执行，照比\(\alpha\)阶段，项目管理的效果提升明显，同时也大大降低了git分支管理的难度。

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

6. 项目文档的质量如何提高？
   
   现有的文档已经较为详细，详见项目展示——文档与规范。

7. 对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
   
   作为PM并没有太多的权力，反而有太多需要承担的责任，需要处理各种各样的意外情况，包括：

   • 组员任务未按时完成
   • 组员完成的任务不符合需求
   • 课程组安排的大量作业压力
   • 课业及考试压力
     
     事实上，作为PM也不可能做到面面俱到，做“除了项目开发以外的所有事情”。在目前这种情况下，有了量化的评价指标，已经相当程度上激发了组员的动力。

8. 对于软件工程的理论，规律有什么心得体会或不同意见？ （期中作业见个人博客）
   
   心得体会见项目展示——每人总结

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

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