这个作业属于哪个课程	软件工程
这个作业要求在哪里	团队作业6——复审与事后分析
这个作业的目标	项目的事后总结与分析

会议照片

设想和目标

我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
软件要解决的问题：为普通用户提供一站式简单图片处理的平台。
定义是否清晰：定义较为清楚，我们只针对大多数互联网用户做简单的即用即走的图片处理。
对典型用户和典型场景有清晰的描述，在需求规格说明书中有提出。
我们达到目标了么?（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么?)
我们按照原计划时间交付了所有的主要功能，次要功能中只有复杂的涂鸦尚未完成。
由于我们对服务器部署网页的知识欠缺，导致我们的网页没有按时上线，只能通过本地与局域网运行，因此用户数量较少。
用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户功能基本完成，跟我们预期想法基本一致。我们离目标更近了。
有什么经验教训? 如果历史重来一遍,我们会做什么改进?
教训：问题定义不够明确，提问本身就是一种能力。
改进：在提问及设定目标前，充分的调研是必要的。

计划

是否有充足的时间来做计划?
有。我们在计划阶段安排了足够的时间，并且经常开会进行讨论交流。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们会对不同意见进行分析并权衡其中的利弊，最终达成统一。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划第一阶段的工作都已完成。
第二阶段(进阶)中涂鸦功能未完成。因为项目计划设计阶段错误估计其难度，预设时间过少。
有没有发现你做了一些事后看来没必要或没多大价值的事?
暂时没有。
是否每一项任务都有清楚定义和衡量的交付件?
是的。我们使用 Leangoo 专门管理每一项任务。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
基本是的，但同时也存在意外——服务器部署较为复杂，备案时间长。
服务器部署风险没有估计到，因为先前并未从事过相关工作。
在计划中有没有留下缓冲区，缓冲区有作用么?
有。在 Alpha 的计划中设置了三天的缓冲区，主要是用于计划之外的任务安排，例如项目功能没有出现预期的效果，我们需要进一步的协商改进。
有什么经验教训? 如果历史重来一遍,我们会做什么改进?
教训：团队交流不够积极，导致对接时消耗较多时间；功能开发前未做到统一规划，导致代码冗余；队员未能定期交付任务，导致进度延后。
改进：积极交流任务进度，及时解决问题；功能在开发前应做好统一规划与限制，并在开发时得严格遵守约定的约束；当队员接任务后未能定期交付时应及时调整并重新规划该任务。

资源

我们有足够的资源来完成各项任务么?
没有，缺乏前端和服务器部署方面的经验，以及服务器资源。
各项任务所需的时间和其他资源是如何估计的，精度如何?
任务所需时间主要是根据任务量和任务截止时间估计的，精确到天数。但同时，我们也会根据实际情况在召开会议的时候进行适当的调整。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间，人力和软硬件资源足够。
是的，我们低估了它们的难度。对于项目目前的美工设计，较为欠缺。对于文案的编写，我们预估错了其所耗费的时间精力。
你有没有感到你做的事情可以让别人来做（更有效率）?
没有。对于目前我的工作，我认为我更适合做。
有什么经验教训? 如果历史重来一遍,我们会做什么改进?
留有充分的缓冲区。
多促进成员交流，各取所长。
做好项目方面的实时监督与加强项目资源的管理与部署。

变更管理

每个相关的员工都及时知道了变更的消息?
是的，有变更信息我会第一时间通知相关成员。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们主要通过功能分析四象限法并结合具体的任务量及时间安排。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有清晰的定义。我们认为主要功能实现后经过全面的测试即可发布。
对于可能的变更是否能制定应急计划?
可以。我们通过群聊进行充分的沟通与计划变更。
员工是否能够有效地处理意料之外的工作请求？
基本可以。我们会进行探讨，规划。

设计/实现

设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在项目初期完成，由队长与队友充分讨论完成，时间和人选均合适。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，在立项初期，我们对项目具体内容难以确立，后来我参考了类似网站。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
是的，我们采用了单元测试。我认为这是有效的，它可以在 debug 阶段进行便捷的测试。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
整体框架的实现，各功能间的搭配 bug 较多。因为这些操作较为复杂，涉及方方面面。
发布后没有发现重大的 bug。
因为我们经验的欠缺，导致我们在设计/开发的时候没有想到这些问题。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
在功能开发者提交代码后安排复审人进行代码复审，我们会严格执行代码规范。
如果历史重来一遍,我们会做什么改进?
加强功能开发者自我的代码复审力度，减少代码冗余量，以减少 debug工作量。

测试/发布

团队是否有一个测试计划？为什么没有？
我们有安排测试计划。
是否进行了正式的验收测试？
是的。
团队是否有测试工具来帮助测试？
有，我们团队采用 IDEA、Vscode 以及项目管理工具等来帮助测试。
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
根据测试工具获得的响应时间与项目运转情况来测量并跟踪软件效能(包括压力测试)。
从结果来看，这些测试有助于我们完善我们的项目。
改进：我们应上线发布来更客观地测试项目性能。
在发布的过程中发现了哪些意外问题？
服务器部署上线耗时过长，使得我们的项目暂时只能通过本地及局域网访问。

团队的角色，管理，合作

团队的每个角色是如何确定的，是不是人尽其才？
每个角色都是队员主动选择的。
我们充分了解了各个成员的能力，并进行了适当的调整。
团队成员之间有互相帮助么？
有，成员遇到困难时，会通过相互沟通交流一起协助解决困难。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
相互沟通解决。

总结

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
CMMI中的三级，定义级别。
你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段?
规范阶段。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
代码更加的规范统一，技术运用更加熟练，开发效率有所提升。
你觉得目前最需要改进的一个方面是什么?
成员交流积极性欠缺。
代码管理的质量具体应该如何提高？代码复审和代码规范的质量应该如何提高？
项目初期制定代码规范，并且要求开发人员必须严格遵守。
复审人员严格执行代码规范。
整个程序的架构如何具体提高？如何通过重构等方法提高质量，如何衡量质量的提高？
架构制定者要完善自己的整体架构体系的理论。
对代码的各个方面进行分析、复审、重构。
功能的处理速度，整体bug量，代码可读性。
其它软件工具的应用，应该如何提高？
多使用，多学习。
项目管理有哪些具体的提高？
熟悉了整体项目的管理流程。
熟练使用各种项目管理工具。
项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
通过日志系统来跟踪用户数据方面的信息。
项目文档的质量如何提高？
使用文档审查工具。
对于软件工程的理论，规律有什么心得体会或不同意见？
理论需要同实践相结合。

Alpha 阶段的角色和具体贡献

成员	角色	团队贡献分	可验证的贡献
戴子豪	PM	40	所有团队博客的编写、整个项目统筹安排与推进、所有成员的组织协调
朱俊荣	Dev	50	整个项目前端的实现、多种图片风格化的实现、文字识别的实现、整个图片处理过程交互的实现、图像增强的实现、证件照换底色的实现
李铭伟	Dev	13	图片格式转换、图片压缩的实现
陈倚星	Dev	12
卫宇琪	Dev	4
张震	Test	18	项目总体测试工作、测试文档的编写
甫尔达吾斯	Dev	3