过后分析$\alpha$

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

VisualPytorch发布域名+双服务器以下：
http://nag.visualpytorch.top/static/ (对应114.115.148.27)
http://visualpytorch.top/static/ (对应39.97.209.22)

过后分析会图：

1、设想和目标

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

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

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

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

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

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

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

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

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

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

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

   虽然用户量并无达到预想的水平，但就反馈来看，用户对重要功能的接受程度仍是达到了咱们的预期的。所以，能够说咱们确实是离目标更近了。

5. 有什么经验教训? 若是历史重来一遍，咱们会作什么改进?

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

2、计划

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

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

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

   其实总的来讲，对于计划的意见都比较明确，并且因为分工比较早并且重叠的部分很少，即便有改进，也基本上是在本身的分工内进行的改进，意见的冲突并很少。若是遇到这种问题，通常都是在开会时就予以解决，经过讨论来尽可能达成一致，最终的决定权在PM手上。

3. 你原计划的工做是否最后都作完了? 若是有没作完的，为何?

   除了前面提到的内容之外都作完了。没作完的缘由也提到了，主要仍是卡在了前端插件上。

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

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

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

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

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

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

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

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

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

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

9. 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

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

3、资源

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

2. 各项任务所需的时间和其余资源是如何估计的，精度如何?
   估计是按照咱们之前的开发经验。作这样的估计实际上是存在较大误差的，由于具体解决问题的时间包含了学习新知识，一边学习一边开发很难在一开始就明确估计到所须要的时间。

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

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

4、变动管理

不存在人员上的变动，仅有工做内容的变动。

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

2. 咱们采用了什么办法决定“推迟”和“必须实现”的功能?
   在群里讨论技术细节和时间，若是条件容许就作，不容许就不作。好比“支持网络层封装”的功能由于时间不容许就推迟了。

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

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

5. 员工是否可以有效地处理意料以外的工做请求？
   能。规定全部请求都转到PM那里处理，这样减轻了开发人员的压力，让他们能集中精力在本身那一亩三分地上。

5、设计/实现

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. 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?
   应由测试引导项目的开发，而且设计应该更加清晰明确。若是重来一遍，咱们会花更多时间完善设计文档，而且在项目开发时编写更多测试用例。

6、测试/发布

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

2. 是否进行了正式的验收测试？
   没有一个整体的验收测试，主要由各自分别进行。缘由是你们经验不够丰富，须要在下一阶段完善此方面。

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

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

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

发布到同窗群中时，发现红包被抢得差很少了，可是网站的访问量和使用状况增加不大，这仍是对咱们沉重的打击。

6. 咱们学到了什么? 若是重来一遍, 咱们会作什么改进?

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

7、团队的角色，管理，合做

1. 团队的每一个角色是如何肯定的，是否是人尽其才？

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

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

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

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

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

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

8、总结

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. 项目文档的质量如何提升？

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

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

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

8. 对于软件工程的理论，规律有什么心得体会或不一样意见？ （期中做业见我的博客）

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

对比敏捷的原则，你以为大家小组作得最好的是什么？

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

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

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

新增的功能

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

修复的bug

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