设想与目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
在Poemscape|Beta总体规划中定义得很清楚。
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
原计划的目标中，
- 性能：很好的达成目标，项目从Alpha阶段的需要一分多钟才能跑完一首诗，到现在几十秒就能同步出诗和对联；
- 功能：实现基础目标：能够分别为人像和风景进行针对性的创作；
- 美化：稍显不足，但也较第一版有所进步；
和大成组进行了对比，我们在目标重视和人员配置上有一定的问题，①我们以模型速度和质量为重点，在对用户体验方面本来就比较忽视，然后在界面的设计上，又采取了减少用户点击次数，让用户能够更快的得到结果为目标；②表面上我们前端组有两个人，但实际能够编码的人员只有一卓一人（对比大成组Alpha阶段就有3-4人负责/参加前端）。这三个思考方式出发点都没有错，但拼起来就导致我们的用户体验不佳，这也提醒我们以后要全局考虑。
计划
是否有充足的时间来做计划?
Beta初期，由于大家都是green hand，对任务实际的困难度估算不准确（“PM”还是一个技术盲==），所以当时我们认为，相较于先调研直接定出精准的规划却未符合事实，不如根据项目分为三个阶段（试做➕调研阶段、完成目标阶段、补漏调整阶段），同时按照成员兴趣进行大致分组管理效率更高。到了中后期后再进行确定的规划。前期我们完成的非常好，燃尽图一直都有超前完成，但是中后期即使不清楚情况也应该明确DDL和任务安排，却没有实现，这是PM的失职。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
PM收集整理了所有组员最初的想法都在最初提出，由PM进行整理，最后汇整起来，由于我们人数够多，所以决定将所有任务都列出。并且确定了任务的基础性，重要级排序。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
我们实现了我们认为最重要的工作。当然还有开放的、未完成得到工作，这部分工作原计划中就处于bonus状态，并未计划是都完成的。
有没有发现你做了一些事后看来没必要或没多大价值的事?
从软件发布的角度来看，组内安排了大量人手去解决性能方面的问题，其实剩余的人力资源是不足以在考试/结课月的10天内辅助将人脸识别这个功能很好的Train并投入实际的运行，而这项工作，不仅花费组内一位同学整个Beta阶段的大部分精力，前端组也付出了很多的努力。从项目的角度出发，Beta阶段重点应放在发布出去的产品的整体质量上，而不是一味的在功能上提高，当然这是我们未来成为成熟的工程师后能够也应该判断并规避的。
从PM个人角度出发，作为非技术口的同学，每天和大家一起开远程语音会议的必要性没有这么大（所以后期不完全参加），也花费了不少的时间和精力去消化，反而应该每天通过其他方式（如私戳大家询问状态和进度等等）去和大家交流，以实现对话。
是否每一项任务都有清楚定义和衡量的交付件?
我们的架构师对任务有很明确的规划，并进行了测试，在这点上组内有充分的自信。但是在前端上我们其实可以看到效果图和实际实现的状态有一定的出入，这点上是美工早早的不熟练，询问了做网页设计的前辈，最好的情况是设计和编码Html+CSS+JavaScript的是同一个人（至少设计师能做出html+CSS），而负责编码前端的工程师负责的是前后端的接口等功能的部分。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
整体而言，项目按照计划，每天完成和完善前面的issues，并提出新的issues以推动实现项目。但项目还是有意外——没考虑到的风险是子项目间的拼接问题花费的时间和精力，导致我们在拼接功能上花了好几天时间；原因是经验不够丰富。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
齐炜祯 ：beta阶段，从PM转变为Developer的角色，主要跟随子博学到了现代软件的结构，学习了成熟的架构对于整个项目的意义，整个从alpha到beta的过度过程，体会到一个各个功能都有但是走一步掉一个螺丝的机器人和一个功能构建完整功能定位明确，拓展方便的体系之间的区别。如果能重来我们有什么改进：在每个人都有太多自己的事情之外做软件项目做成现在的程度我已经很满足了。在《人件》中有讲到，同时做的事情越多，耗费的无用精力更多；在不同的团队里，认真负责是互斥的。所以大家在完成好科研工作之外能把项目完成到现在的程度我觉得很好了。如果能重来，我希望可以所有的developer都是全职员工。
姚青松 ：肯定有银弹，良好的工具使用，每日例会，合理的分工，正确的冲刺方式，和谐的团队氛围一定会让软件工程变得容易高效，反过来说如果不懂如何合作开发，很小的问题就会卡死整个项目，和每个人的实力和问题复杂度无关。如果重来会更加重视分工交流验收，即使每天做很小的工作也要确保完成。
王子博 ：我觉得最大的经验是，要制定明确、可度量的里程碑，并且将责任分配到人，切实实现之。我在编码工作基本结束时就宣布实现了第一个目标，开始计划额外功能了，这主要是因为更早时我给大家说的估计是四五天能完成第一个目标，到了第四天、第五天时心里有压力，急于开始安排下一阶段的任务。其实这个估计本身没有什么问题，正确估计了编码的时间，但我没有重视 bug fix 的过程，以为在前进过程中上一阶段的 bug 可以零散地被解决。实际上，必须专门为此分配时间，不然的话人总是更愿意编码新功能，不愿意枯燥地解决 bug 的。我们迟迟没有清理干净 bug，也就导致迟迟拿不出一个完全能用的构建。自动构建和部署的系统虽然做了，却因此没发挥出足够的作用，没有体验在其上不断优化、实时观察进展的过程。
赵瑞静 ：总的来说学到了软件开发的流程和合作沟通的重要性，细节的来说学到了一些浅显的服务器架构有关知识。 如果历史再来一遍，相比于添加更多的功能，可能会更加重视优化已有功能的体验。
刘泽 ：软件工程的时间安排，统筹规划的重要性。一个好的架构的重要性，怎么才能提高代码质量，同时提高自己的工程能力。学习到了一些新的网站搭建知识。重来一遍会做什么改进：针对功能拼接要花费更多的精力在上面，否则经常出现不如人意的bug.
张一卓 ：软件工程的基本开发流程，积累了网页前端的一点经验。重来一遍的改进：预先规划多花一点时间，在开发流程中要能够先完成里程碑，再向前推进。
###资源 **我们有足够的资源来完成各项任务么?** 虽然我们抱怨过的问题，但我们有够用而不充足（adequate but not sufficient）的服务器完成我们的任务。
各项任务所需的时间和其他资源是如何估计的，精度如何?
进行了任务的困难度排序之后，最重要的问题是一定要解决的，所以直接解决，精度分配到个人。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间有些吃力，服务器资源够用而不充足，不需要编程的部分，美工难度还好，文案比较匮乏。
变更管理
每个相关的员工都及时知道了变更的消息?
和Alpha阶段不同，这次我们的daily scrum有在run，确保了消息的及时性。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
架构师进行了很清晰的定义。
对于可能的变更是否能制定应急计划?
我们相信我们可以。
设计/实现
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
齐炜祯：只要有拼接就会有bug。互相交接的工作，责任不明确，会互相推卸责任。
姚青松：凡是遇到连个功能模块相接的部分产生的bug最多，engine/api，前端api，因为出现bug没有落实到人或者两个人，大家就会一起互相等，导致bug一拖再拖。发布之后一台服务器承受不住三个engine，其次没有考虑到用户上传超级大图片的情况。开发设计时候低估了用户量，和用户上传内容的不确定性。
王子博 ：bug 最多的部分是前端，这也是没什么办法的事情，我们的前端开发能力确实不太充足，只靠一卓一个人在努力。总体上这是在预料之中的，也没有对项目进展产生明显影响。在发布之后出现过两次较长 downtime，都是由于向生产服务器上做了有问题的更新，既没有事先在开发环境测试，也没有在生产环境发现后及时回滚以减小损失。我觉得这是因为我们没有专门安排生产服务器的维护者，发布以后大家向服务器推送更新比较随意，没有制订严格的服务器操作规范。如果改正的话，规范应该至少包含这样的要求：生产分支必须通过 pull request 提交，pull request 必须除发起者外得到一人审查认可，在生产服务器操作时必须事先想好操作内容、操作后的测试方式、测试出问题时的回滚方式。
赵瑞静 ：我觉得bug最多出现在两个功能进行拼接的时候，发布之后发现没有不满意多做几首的功能。在最初时间规划不是很好，最后做的不是很完善。
刘泽 ：功能的拼接，稳定版本的确定，版本的迭代等。是有想到这些情况的，只是执行起来比想象中问题大，可能前期不够重视导致的。
张一卓 ：所有模块拼在一起时会出现之前没有发现的bug，没有想到的原因：我们的项目测试工作做得不够完善，开发时不能预先测试。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
王子博 ：我们采纳的规范是，每个仓库设 dev 和 master 分支，前者用于每日提交，在达到里程碑后向后者发送 pull request，经过至少另一人评审后签入并部署。在每日提交后，子博会审核代码风格是否符合 PEP8，代码逻辑是否符合 spec，并以 GitHub comment 的形式给出反馈，大家第二天就能及时修正问题，避免开发过程偏离 spec。在实践中，由于我们用了太久才到达第一个里程碑，部署了无 bug 的网站，达到了签入 master 分支的标准，所以 master 分支迟迟未被使用，基本上始终在 dev 分支上工作，以至于居然做出了持续集成 dev 分支这种不合理的事情来（笑），导致不少有 bug 的代码被持续集成自动部署了。到了后期，项目发布以后，由于大家增加功能心切，为了尽快部署新功能，出现了跨组工作和未经测试和评审就部署代码的现象，代码质量便失去了严格控制，虽然敏捷，但对服务稳定性造成了一定影响。
###团队的角色，管理，合作
团队的每个角色是如何确定的，是不是人尽其才？
整体根据大家的兴趣和精力进行了任务分配。
团队成员之间有互相帮助么？
有的！
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
每天开会沟通+部分情况微信群实时沟通
总结
代码管理的质量具体应该如何提高？代码复审和代码规范的质量应该如何提高？
对于人的领导和管理，有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节，或者《人件》等参考书
首先，PM的人选有一定的问题，作为非技术+非本地+还有自己的工作的PM，能力和精力上有些吃力，所以实际上我们实施的是：通过每日会议大家的互相交流这个基本的"外驱力"进行监督，和大家的自觉作为“内驱力”进行激励实现的双向约束，其本质是全体民主管理，项目计划的每天调整也是完全民主的。从项目结果出发的情况来看，由于我们的组员的自我管理约束能力较高，项目产出是不错的，但从管理模式来看，它的本质是不稳定的，如果这个项目时间更长，还是容易出现其他情况的。
改进方面，若笔者仍担PM一职，必定会寻找一个明确的PM助理进行沟通管理，为更好的分配资源，对每天调整计划的管理还是应该有一定的集中度，同时对目标的管理进行严格的量化。
贡献的权重
| 组别 | 成员 | 贡献权重 |
|---|---|---|
| 引擎 | 姚青松 | 21 |
| 引擎 | 齐炜祯 | 23 |
| 架构 | 王子博 | 22 |
| API服务器 | 赵瑞静 | 20 |
| API服务器 | 刘泽 | 19 |
| 前端 | 张一卓 | 18 |