Poemscape|Beta阶段过后诸葛亮

设想与目标

咱们的软件要解决什么问题？是否认义得很清楚？是否对典型用户和典型场景有清晰的描述？
  在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