对联组项目管理 - 事后诸葛亮会议
项目网址：https://poempicture.azurewebsites.net/index
demo录屏：录屏网址
成员得分：
设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
解决的问题和定义请查看本网址当时对于典型场景、用户定位和需求都有比较清晰的认识，所制定的基础功能和杀手功能到现在来看都是比较准确的。
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
alpha阶段的话还算是基本完成目标了。原本制定的功能完成了对联和古诗创作两个核心功能，对人脸作诗也基本走完了流程，但是服务器上只整合了对联和古诗的功能，而且根据负责server的同学报告，因为azure的限制和比较差的硬件，我们一次只能开一个模型，对联或者古诗。按照原计划时间交付了。现在除了我们组和另一个对联组同学的使用，还没有其他使用用户。
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
这是第一个版本。略过
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
就现在的运行速度来说，没人能够接受。离目标最少还差一个架构师。其次还差能大改模型的人。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
单就此部分，设想和目标来说的话，还是比较成功的，基础功能和之后的杀手功能或者拓展辅助功能的设定还是比较有指导意义的，用户定位现在看起来也还算合理。教训也有一个致命的，就是功能太多，就我们能租的起的服务器来说，根本不可能完成完全，就算能跑在服务器上，也完全不可能支持大规模访问，不过作为设想，是指导我们的，真正完成哪些功能，是根据实际情况来完成设想的指导的；因此设想目标还算成功。
计划
是否有充足的时间来做计划?
有很多时间可以用来做计划，但是由于我们都没有过小组的项目经历，因此实际上做起来之前，很难说在项目开始之前就准确地知道具体的任务该做什么和任务量。所以我们把alpha又分为了前半阶段和后半阶段。前半阶段还是摸石头过河，因此是两人一个小组，每个小组一个任务主题，边探索边确定任务量，在初期就有一个用于参考的ddl，但是很灵活，根据每小组真实的进度来更改。请参考alpha第一阶段计划。而到了真正做起来，小组步入正轨之后，PM对于项目的理解、进度的把控到了一个熟悉的阶段之后，则可以制定到每个人每天该做什么的详细计划，而不是粗糙的参考ddl。请参考alpha后五天计划
团队在计划阶段是如何解决同事们对于计划的不同意见的？
第一阶段摸石头过河，PM根据每个人的兴趣确定的小组和小组任务，并分配了小组参考ddl阶段的任务目标，每个小组的目标、任务量都是由小组进行起来之后自行确认并且和PM沟通的；即PM定大方向，小组组员确认详细计划。第二阶段则是由PM制定到每个人，并在任务开始前询问组员对于计划的意见进行修改，并且在进行起来之后确认了组员的真实进度后进行调整。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
基本做完。基本做完和完全做完之间的gap：比如人脸作诗，服务器上已经不允许我们跑更多的模型了；生成诗和对联的质量都不理想；tag到词典的处理不理想；server的代码质量和处理方法不理想等等。直接原因在于PM不敢占用大家太多时间，作太push的要求；PM管理经验不足，没有可以合理管理进度（确保组员接受到任务、确保组员完成任务）的方法；需要有一个备忘录比如GitHub issue，每人每天都查看；根本原因在于，一，大家太忙了，抽不出足够的时间在这个工作上，因此比如模型太差（包含生成效果差和模型太大跑得慢），不会有重新推翻找新的模型的动力；二，我们组组员的coding能力都比较差，项目经验几乎没有，所以分工了之后每个模块的解决手段比较简单粗暴，代码水平也比较低，不过这一点在PM看来不是什么大问题，本来也是来学习软件工程的，有什么水平写什么代码，完全可以接受。
有没有发现你做了一些事后看来没必要或没多大价值的事?
没有
是否每一项任务都有清楚定义和衡量的交付件?
现在看起来这是PM做的比较差但是很开就意识到开始解决的一个问题。在摸石头过河阶段，无法定义清楚非常清楚的定义和衡量的交付件是可以理解的。在alpha第二阶段，已经安排到个人任务和具体的工作任务，但是由于没有“清楚的定义”和“衡量的交付件”，PM遇到了很多问题。比如需求是训练一个模型，可能真的会训完就任务结束了，dev不会自觉地 去尝试跑一下各个输入有没有合适的输出，等PM意识到需要额外指派任务才会有人做这个事的时候，发现了问题需要解决就已经严重拖累进度了。所以第二阶段第三天起就开始把任务定义成“做完并交接给xxx并且跑通才算完成”、“训练完使用一下观察tag生成文本的结果没有严重问题才算完成”等等
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
有不少意外。意外大大小小的都有。小意外比如，需要某同学完成某功能，并与下一个同学交接，该同学则完成了该代码就丢在一遍或者push到repo上就不管了，而PM询问工作进度时该同学会汇报已做完。但是PM让负责server整合的同学作demo的时候却发现整合同学根本没有接到过这份代码，导致拖累项目进度的意外。这个情况不止出现过在一个人身上，也不止一次。因此从该阶段第两三天开始，PM开始陪着每个同学写代码并且督促交接，从此开始任务才得以解决。再比如，有的同学没有该任务的经验，完成不了任务却不告诉PM，有的同学任务没有完成或者还存在问题就告诉PM已经完成了当天进度，出现了大问题却瞒着不告诉PM，等到PM发现某进度严重出现问题时才开始解决，最终拖累了项目进度。不过好的是晚些大家仍然是比较坦诚的，突然发现了error可能会迟一些，但是一定会汇报error，然后一起解决。大的意外比如上周出现的开除组员情况，因为上周上课已经详细讨论过了，略过不提。
在计划中有没有留下缓冲区，缓冲区有作用么?
有留缓冲区。缓冲区非常重要。可以保证进度的连续性，不会因为很多风险的产生就最终使项目失败
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
详细到定义好每个人的每天的Input，output，做到哪一步，能跑成什么样算完成。缓冲期设计到20%。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
千万不能设计定性的任务和模糊的任务，要精确到每一个可执行的步骤。结束后一定要查验到可以跑通的代码才算结束，而不是问了得到肯定的答复就算结束。
资源
我们有足够的资源来完成各项任务么?
没有。
各项任务所需的时间和其他资源是如何估计的，精度如何?
对于资源的估计比较失败，跑神经网络别说gpu了……连好点的cpu都没有。所以一开始设计的功能也设计多了，所以后续beta的重点在于优化模型、优化界面、优化体验、加速、设计小程序和人性化的分享功能，而不是添加功能了。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
感觉美工太重要了。一万个感谢早早设计的效果图。
你有没有感到你做的事情可以让别人来做（更有效率）?
除了写各个文档的本职工作外，PM确实做了很多其他不该自己做的任务。比如因为有组员不工作，PM要去写网页。交接任务，都不会主动去交接，需要PM去跟着把两边人喊在一起陪同交接。组员可以完成“训练模型”一类的任务，而无法完成“观察xxx，找到最好的xxx，并解决xxx到xxx的gap”一类定性无法定量的任务 。需要把任务精确到“PM整理好交给你的这份数据训练多少轮，换成哪些数据，然后……，跑完输入tag观察一下结果没有致命的问题才算完成”等等才可以进行，感觉虽然明确的可以立刻上手做的任务安排是PM需要做的，但是太细的任务描述让自己感到吃力，甚至有时候心情不好的时候想让组员不要做了自己做还能快一点。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
对于dev来说，每个人的能力不止在于coding的能力，也在于对于任务是什么，该怎么做，什么样算做完，怎么样算做好的辨别能力，以及分析问题的能力。比如我以为大家都知道我们的cpu能力有限，有启动时长限制，加载一个模型的启动时间已经很吃力了的情况下布置的新任务，解决“现代词汇tag到词表词汇”的问题，肯定是找一个api或者轻量的运算方法，而不是load一个巨大的模型进来导致更加跑不动需要版本阉割掉功能等等。组员作为focus在自己项目上的开发者，对问题的思考和对全局的观念可能和PM不一样，很可能会忽略一些问题，涉及到全局的任务，应该是PM定义清楚的。其次是组员对于自己focus上的项目，也可能会因为分析问题不完全导致很多问题，比如任务是”修改古诗模型，训练上对联的数据并且观察结果可以有正常的创作结果“，组员可能会忽略掉现在语料的对联数据集，就不需要过一遍诗学含英古词汇词典的filter了，否则训练结果会一团糟。应该让每个人做自己擅长的工作。不过好在组员都非常坦诚，最后发现了问题也不会瞒着不报，所以问题最终还是可以通过临时加班解决的。
变更管理
每个相关的员工都及时知道了变更的消息?
这点PM做的缺陷比较大。PM以为在微信群通知一遍、在博客园写一遍、在github上提一遍issue员工就知道了。实际上员工可能会忙忘掉。所以PM后期会再通知一遍得到个人的回复。但是因为大家都很忙貌似根本没时间看issue，所以最后issue也都是由PM关掉的（宇飞除外），所以确认工作进度的效率低下，需要PM再次确认进度没有翻车。beta阶段需要确保这些工具能够真的使用起来。这个问题还体现在，有的时候某个组员给某个组员提了需求，只是去他工位上告诉他或者微信群里说，导致忙着忙着就忘了；在beta阶段需要养成每个组员开issue关issue，把issue当成备忘录的习惯。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
由PM判断。因为大家都很忙，员工提出任务遇到困难且沟通后确定不会严重影响项目的就能推迟则推迟，非常影响产品品质的则必须实现。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
第一阶段（前五天）没有，完成框架功能就算做好了，第二阶段（后五天）开始逐渐有清晰定义，比如“交接给server端，运行成功才算结束”，但是员工仍然有可能写了代码丢一边就不管了，PM当天询问进度时候才发现没有拼接，只好在进度博客中谎报该员工完成了任务，但是三四天后他才拼接而且发生严重问题导致功能只能被丢弃的问题发生。
对于可能的变更是否能制定应急计划?
可以。加班。
员工是否能够有效地处理意料之外的工作请求？
有的可以，比如宇飞，基本上有额外的意外PM都会去拉着宇飞一起解决，因此宇飞是整个项目里贡献最大的人。比如在图片字行数不正确等问题，以及从项目开始初期就反复确认了很多遍的给tag2couplet的接口所需要的形式之后，pre的前一天晚上员工突然告诉PM那边的模型需要中文逗号隔开的输入才能正确识别，PM又拉着宇飞改代码改到了十一点多
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
如实汇报进度
设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
进度设计上面已经提过了，我们把alpha又分为了前半阶段和后半阶段。前半阶段还是摸石头过河，因此是两人一个小组，每个小组一个任务主题，边探索边确定任务量，在初期就有一个用于参考的ddl，但是很灵活，根据每小组真实的进度来更改。请参考alpha第一阶段计划。而到了真正做起来，小组步入正轨之后，PM对于项目的理解、进度的把控到了一个熟悉的阶段之后，则可以制定到每个人每天该做什么的详细计划，而不是粗糙的参考ddl。请参考alpha后五天计划
。UI设计是在alpha的第一阶段和第二阶段中间由擅长美工的早早完成的，是合适的时间合适的人完成的。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
我觉得上面这一问已经把现在这一问回答清楚了。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
没有做。时间太紧张，核心功能还没有做完。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
古诗模型的所有操作基本都bug重重。因为组员对代码理解的很不到位，就开始工作，工作后缺少必要的检查就交付，导致后期修改的任务量比较重。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
没有进行很好的代码复审也是项目出现问题和紧急情况的原因。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
测试/发布
团队是否有一个测试计划？为什么没有？
没有。都是跑起来看结果有没有问题。因为核心功能还没开发完，甚至还在砍。只能说解决明显的bug
是否进行了正式的验收测试？
无
团队是否有测试工具来帮助测试？
无
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
无
在发布的过程中发现了哪些意外问题？
生成图片的诗显示不全，检查代码找不到问题，本地测试也没有发现问题，最后发现因为前端使用的时候每行诗之间为了显示美观多输出了一个空行，而本地文件中的处理是split计算行数留出空白的。
临pre前一天晚上组员发现出了bug，导致临时加班
我们学到了什么? 如果重来一遍, 我们会做什么改进?
团队的角色，管理，合作
每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
我感谢 _______徐宇飞____对我的帮助， 因为某个具体的事情: __多次一起改bug解决紧急情况___。
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
勉强可以到第二级，管理级。可以分工到权责到人，再有同样的项目任务，大概率可以完成。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范阶段。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
这是第一个里程碑
你觉得目前最需要改进的一个方面是什么?
PM对于合理布置准确量化的任务和验收的能力；组员对于“思考一个问题”的流程的能力。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
尽早并持续地交付有价值的软件。冲刺前就找好了代码库和api接口。
业务人员和开发人员应当每天共同工作。后期做到了
正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
严格遵守进度检查和每天的博客书写，要求每个组员必须自己去管理github上的issue，确保每天PM验收代码通过后才算完成任务
代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
代码的管理需要重新更改，可以参考最后一天报告中子博的建议。代码复查和代码质量为了控制工作量仍然是自审，但是应该列在任务里量化掉，才会有人去做。
整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
不好意思我不知道
其它软件工具的应用，应该如何提高？
工具已经足够用了，需要提高的点在于督促组员去使用，主动地报告问题和进度。
项目管理有哪些具体的提高？
任务量化，细化，具体到可以立刻实现；需要有验收和整合的步骤。
项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
没有除测试同学外的使用用户。
项目文档的质量如何提高？
文档的目的是辅助项目的发展，有效的记录、指导、督促才是重要的。
对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
首先是整个事情的大背景和条件，存在有老师的期望和同学的期望之间的矛盾。老师非常认真负责，对于项目的要求比较高；同学们大四对于成绩的要求非常低，组里的科研任务非常重，而且大家的coding水平参差不齐，大家对于项目的期望水平也不同。而且和真正的项目相比，并不存在真正的管理被管理之间的约束，分数对于大家的影响也非常小，因此导致了每个人干活 意愿相差很多的情况。为了很好的管理团队，需要有一定的制约力。我认为，因为是临时凑成的小组，能力不同，做出来的成果水平不同是没关系的，但是如果有能力却不工作，而且态度很差的话，是我不能接受的。在”开除组员“前，组里有两个同学几乎从来不回复消息，因为知道他们忙，所以任务量布置得非常少，但是把关照会当成直接忽视，开会等等很难联系到，但是“开除组员”后，大家明显回复消息积极了很多，项目的推展也顺利了很多。其次是像老师中途评论到的，一定要把各个任务可以量化到，大家才能很好的完成，这点在真实工作中，真的是必须的。
