项目网址:https://poempicture.azurewebsites.net/index
demo录屏:录屏网址
成员得分:
html
解决的问题和定义请查看本网址当时对于典型场景、用户定位和需求都有比较清晰的认识,所制定的基础功能和杀手功能到如今来看都是比较准确的。前端
alpha阶段的话还算是基本完成目标了。本来制定的功能完成了对联和古诗创做两个核心功能,对人脸做诗也基本走完了流程,可是服务器上只整合了对联和古诗的功能,并且根据负责server的同窗报告,由于azure的限制和比较差的硬件,咱们一次只能开一个模型,对联或者古诗。按照原计划时间交付了。如今除了咱们组和另外一个对联组同窗的使用,尚未其余使用用户。android
这是第一个版本。略过git
就如今的运行速度来讲,没人可以接受。离目标最少还差一个架构师。其次还差能大改模型的人。github
单就此部分,设想和目标来讲的话,仍是比较成功的,基础功能和以后的杀手功能或者拓展辅助功能的设定仍是比较有指导意义的,用户定位如今看起来也还算合理。教训也有一个致命的,就是功能太多,就咱们能租的起的服务器来讲,根本不可能完成彻底,就算能跑在服务器上,也彻底不可能支持大规模访问,不过做为设想,是指导咱们的,真正完成哪些功能,是根据实际状况来完成设想的指导的;所以设想目标还算成功。web
有不少时间能够用来作计划,可是因为咱们都没有太小组的项目经历,所以实际上作起来以前,很难说在项目开始以前就准确地知道具体的任务该作什么和任务量。因此咱们把alpha又分为了前半阶段和后半阶段。前半阶段仍是摸石头过河,所以是两人一个小组,每一个小组一个任务主题,边探索边肯定任务量,在初期就有一个用于参考的ddl,可是很灵活,根据每小组真实的进度来更改。请参考alpha第一阶段计划。而到了真正作起来,小组步入正轨以后,PM对于项目的理解、进度的把控到了一个熟悉的阶段以后,则能够制定到每一个人天天该作什么的详细计划,而不是粗糙的参考ddl。请参考alpha后五天计划编程
第一阶段摸石头过河,PM根据每一个人的兴趣肯定的小组和小组任务,并分配了小组参考ddl阶段的任务目标,每一个小组的目标、任务量都是由小组进行起来以后自行确认而且和PM沟通的;即PM定大方向,小组组员确认详细计划。第二阶段则是由PM制定到每一个人,并在任务开始前询问组员对于计划的意见进行修改,而且在进行起来以后确认了组员的真实进度后进行调整。小程序
基本作完。基本作完和彻底作完之间的gap:好比人脸做诗,服务器上已经不容许咱们跑更多的模型了;生成诗和对联的质量都不理想;tag到词典的处理不理想;server的代码质量和处理方法不理想等等。直接缘由在于PM不敢占用你们太多时间,做太push的要求;PM管理经验不足,没有能够合理管理进度(确保组员接受到任务、确保组员完成任务)的方法;须要有一个备忘录好比GitHub issue,每人天天都查看;根本缘由在于,一,你们太忙了,抽不出足够的时间在这个工做上,所以好比模型太差(包含生成效果差和模型太大跑得慢),不会有从新推翻找新的模型的动力;二,咱们组组员的coding能力都比较差,项目经验几乎没有,因此分工了以后每一个模块的解决手段比较简单粗暴,代码水平也比较低,不过这一点在PM看来不是什么大问题,原本也是来学习软件工程的,有什么水平写什么代码,彻底能够接受。api
没有服务器
如今看起来这是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判断。由于你们都很忙,员工提出任务遇到困难且沟通后肯定不会严重影响项目的就能推迟则推迟,很是影响产品品质的则必须实现。
第一阶段(前五天)没有,完成框架功能就算作好了,第二阶段(后五天)开始逐渐有清晰定义,好比“交接给server端,运行成功才算结束”,可是员工仍然有可能写了代码丢一边就无论了,PM当天询问进度时候才发现没有拼接,只好在进度博客中谎报该员工完成了任务,可是三四天后他才拼接并且发生严重问题致使功能只能被丢弃的问题发生。
能够。加班。
有的能够,好比宇飞,基本上有额外的意外PM都会去拉着宇飞一块儿解决,所以宇飞是整个项目里贡献最大的人。好比在图片字行数不正确等问题,以及从项目开始初期就反复确认了不少遍的给tag2couplet的接口所须要的形式以后,pre的前一天晚上员工忽然告诉PM那边的模型须要中文逗号隔开的输入才能正确识别,PM又拉着宇飞改代码改到了十一点多
如实汇报进度
进度设计上面已经提过了,咱们把alpha又分为了前半阶段和后半阶段。前半阶段仍是摸石头过河,所以是两人一个小组,每一个小组一个任务主题,边探索边肯定任务量,在初期就有一个用于参考的ddl,可是很灵活,根据每小组真实的进度来更改。请参考alpha第一阶段计划。而到了真正作起来,小组步入正轨以后,PM对于项目的理解、进度的把控到了一个熟悉的阶段以后,则能够制定到每一个人天天该作什么的详细计划,而不是粗糙的参考ddl。请参考alpha后五天计划
。UI设计是在alpha的第一阶段和第二阶段中间由擅长美工的早早完成的,是合适的时间合适的人完成的。
我以为上面这一问已经把如今这一问回答清楚了。
没有作。时间太紧张,核心功能尚未作完。
古诗模型的全部操做基本都bug重重。由于组员对代码理解的很不到位,就开始工做,工做后缺乏必要的检查就交付,致使后期修改的任务量比较重。
没有进行很好的代码复审也是项目出现问题和紧急状况的缘由。
没有。都是跑起来看结果有没有问题。由于核心功能还没开发完,甚至还在砍。只能说解决明显的bug
无
无
无
生成图片的诗显示不全,检查代码找不到问题,本地测试也没有发现问题,最后发现由于前端使用的时候每行诗之间为了显示美观多输出了一个空行,而本地文件中的处理是split计算行数留出空白的。
临pre前一天晚上组员发现出了bug,致使临时加班
我感谢 _______徐宇飞____对个人帮助, 由于某个具体的事情: __屡次一块儿改bug解决紧急状况___。
勉强能够到第二级,管理级。能够分工到权责到人,再有一样的项目任务,大几率能够完成。
规范阶段。
这是第一个里程碑
PM对于合理布置准确量化的任务和验收的能力;组员对于“思考一个问题”的流程的能力。
尽早并持续地交付有价值的软件。冲刺前就找好了代码库和api接口。
业务人员和开发人员应当天天共同工做。后期作到了
严格遵照进度检查和天天的博客书写,要求每一个组员必须本身去管理github上的issue,确保天天PM验收代码经过后才算完成任务
代码的管理须要从新更改,能够参考最后一天报告中子博的建议。代码复查和代码质量为了控制工做量仍然是自审,可是应该列在任务里量化掉,才会有人去作。
很差意思我不知道
工具已经足够用了,须要提升的点在于督促组员去使用,主动地报告问题和进度。
任务量化,细化,具体到能够马上实现;须要有验收和整合的步骤。
没有除测试同窗外的使用用户。
文档的目的是辅助项目的发展,有效的记录、指导、督促才是重要的。
首先是整个事情的大背景和条件,存在有老师的指望和同窗的指望之间的矛盾。老师很是认真负责,对于项目的要求比较高;同窗们大四对于成绩的要求很是低,组里的科研任务很是重,并且你们的coding水平良莠不齐,你们对于项目的指望水平也不一样。并且和真正的项目相比,并不存在真正的管理被管理之间的约束,分数对于你们的影响也很是小,所以致使了每一个人干活 意愿相差不少的状况。为了很好的管理团队,须要有必定的制约力。我认为,由于是临时凑成的小组,能力不一样,作出来的成果水平不一样是不要紧的,可是若是有能力却不工做,并且态度不好的话,是我不能接受的。在”开除组员“前,组里有两个同窗几乎历来不回复消息,由于知道他们忙,因此任务量布置得很是少,可是把关照会当成直接忽视,开会等等很难联系到,可是“开除组员”后,你们明显回复消息积极了不少,项目的推展也顺利了不少。其次是像老师中途评论到的,必定要把各个任务能够量化到,你们才能很好的完成,这点在真实工做中,真的是必须的。