对联组项目管理 - 过后诸葛亮会议

项目网址：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水平良莠不齐，你们对于项目的指望水平也不一样。并且和真正的项目相比，并不存在真正的管理被管理之间的约束，分数对于你们的影响也很是小，所以致使了每一个人干活 意愿相差不少的状况。为了很好的管理团队，须要有必定的制约力。我认为，由于是临时凑成的小组，能力不一样，作出来的成果水平不一样是不要紧的，可是若是有能力却不工做，并且态度不好的话，是我不能接受的。在”开除组员“前，组里有两个同窗几乎历来不回复消息，由于知道他们忙，因此任务量布置得很是少，可是把关照会当成直接忽视，开会等等很难联系到，可是“开除组员”后，你们明显回复消息积极了不少，项目的推展也顺利了不少。其次是像老师中途评论到的，必定要把各个任务能够量化到，你们才能很好的完成，这点在真实工做中，真的是必须的。

对于软件工程的理论，规律有什么心得体会或不一样意见？ 请看阅读做业。 (这个做业的期中阅读)