第六次团队作业——Alpha冲刺之事后诸葛亮

我说的都队

031402304 陈燊 031402342 许玲玲 031402337 胡心颖 031402203 陈齐民 031402209 黄伟炜 031402233 郑扬涛 031402341 王婷婷


一、设想与目标

1.我们的软件要解决什么问题?

  • 解决导师和学生毕业设计互选的问题,拥有四个用户:1.系负责人:设定流程时间,调整最终结果;2.院负责人:查看和微调最终结果;3.导师:填报研究方向,选择自己想要的学生;4.学生:填写个人简历,填报志愿。除此之外还要和上一届学长做的课题填报系统整合。

2.是否定义得很清楚?

  • 是,在做这个选题之前软工已经有类似的作业要求做需求分析,并且在正式的需求分析阶段和老师做了多次讨论。

3.是否对典型用户和典型场景有清晰的描述?

  • 是,我们小组的成员都有过此经历,加上老师作为客户给的需求比较专业,对典型用户和典型场景的描述较为清晰。

4.是否有充足的时间来做计划?

  • 是,由于校运会、老师出差等等原因,时间比较充裕。

5.团队在计划阶段是如何解决同事们对于计划的不同意见的?

  • 如果成员们有意见,大家会先彼此讨论,互相了解对方的想法,给予合理的反驳或者吸取对方的意见,由于团队中有过项目经验的人不少,所以都能进行合理的探讨,没有类似经验的会听从有类似经验的,如果有不可调和的地方,最终一般是由组长来决定。

二、计划

1.你原计划的工作是否最后都做完了? 如果有没做完的,为什么?

作为Alpha版本,我们团队在开发前进行了讨论,认为Alpha版本应该着重实现核心功能,而一些非核心功能放在后期的Beta版本进行实现。所以,根据github上的issues整理,在冲刺阶段我们总共建立了49个issues,并且在截止时间前全部顺利完成,根据issues的标签分类,我们将工作计划划分为以下加粗的六类,并对每一类进行划分和详细说明,其中第六类的工作计划为下阶段,即Beta版本的工作计划
预期计划现实进展
登录界面以及对应的跳转100% :因为需要和上一届学长开发的报课系统进行功能整合,所以教师系负责人院负责人三个用户组的登陆功能不做修改,采用学长的登陆功能,而学生的登陆功能全新实现,并且四个用户组都能够顺利验证用户信息进行登陆,并跳转至不同的界面。
四个用户个人信息界面100% :学生在登陆智能导师分配系统后,显示个人信息界面,该功能完成。但是,修改个人信息的功能尚未完成,因为在Alpha版本,该功能并不是核心功能,所以暂时未考虑优先实现。
系负责人:时间设置界面95% :能运用部件进行时间的设置,并对错误的时间设置(比如开始时间比结束时间晚、时间早于现实时间等)进行提示,但是提示的界面显示还不够人性化,需要再完善,未实现完成原因是时间不够,美工稀缺!
系负责人:匹配设置界面85% :若采用师生互选的方式,可以对未分配到导师的学生进行人工分配;智能分配算法的输出可以在界面上显示,该功能已实现。但是,分配结果的界面暂时还未加入分页功能,以及对分配结果进行微调操作,这些功能未完成的原因是时间不够,且分也存在一定难度。
学生:专业导师界面100% :点击专业导师,可查看该学生对应系别的导师,可正常显示导师列表,并且分页功能也已经实现,每页显示7名导师,该功能实现。
学生:志愿填报界面95% :学生通过下拉列表的方式进行志愿的填报,可正常显示所有导师,该功能实现。但是,在导师人数较多的情况下,浏览可能不大方便,在Beta版本考虑加入搜索以及模糊匹配的功能,该功能未实现是因为时间不够,并且该功能不是核心功能。
学生:志愿结果界面100% :在时间期限截止之后,学生可以查看到所有的分配结果,包括导师信息以及相同导师的学生联系方式。
导师:可选学生界面100% :导师可以查看可选学生的绩点以及志愿信息,并选择或则拒绝自己想要的学生,接受之后分配结果会更新到志愿结果
导师:课题提交界面95% :在课题提交的时间段里,导师可以进行进行学生数和课题的设置,该功能已经实现。但是,过了规定期限而未提交信息的导师的学生数和课题设置信息,系统将自动设置为默认值的功能,未实现的原因是技术上存在问题,不知道该如何处理,并且时间也不够。
导师:志愿结果界面100% :在截止期限之后,导师可以查看分配结果信息以及学生的联系方式
院负责人:导师分配情况界面100% :院负责人可以查看到以导师为导向的分配结果,并可分页浏览
院负责人:学生分配情况界面100% :院负责人可以通过下拉条的方式查看某个系的分配情况,并可分页浏览
院负责人:学生分配情况修改界面100% :院负责人可以对分配结果进行微调操作,通过下拉条的方式进行导师的选择
院负责人:导师分配情况修改界面100% : 院负责人可以对分配结果进行微调操作,例如为某个导师新增尚未分配到导师的学生,或则移除某个导师的学生
导师分配智能算法100% :ACM大神敲出来的算法,会有问题???完美符合需求!利用随机数据生成的数据进行测试,分配结果符合预期
后台调用CPP格式的算法,进行数据输入输出100% :算法采用文件输入输出的格式,php从数据库中获取 未分配到导师的学生信息,转换为txt文件,采用php shell调用cpp文件,然后通过算法得到的结果输出为txt文件,php调用txt文件,再转换后显示到view里
项目测试工作80% :因为项目工程较为庞大,而且之前对测试工作接触不多,测试计划的展开屡屡受阻,不过通过资料查阅以及请教学长学姐,目前也较好得完成了测试工作的进行

Beta版本的计划

尚未开发的功能模块

  • 四个用户组的个人信息修改界面

  • 学生、导师信息支持Excel的导入功能

  • 学生——专业导师:搜索功能

  • 系负责人:学生管理、导师管理、结果导出

  • 院负责人:管理系负责人

  • 院负责人——导师分配情况:支持Excel的导出功能

  • 院负责人——学生分配情况:支持Excel的导出功能

需完善的细节

  • UI布局及美化

  • 网站的Logo设计

  • 头像的上传、修改以及对应的界面显示

  • 界面的自适应,浏览器缩放时的界面显示问题

  • 志愿填报的导师搜索功能

  • 智能分配时,系负责人可对结果进行微调

  • 界面切换时的闪现问题

  • 导师列表和学生列表点击头像或姓名后跳转到详细信息界面

  • 在进行重要操作时的提示更为人性化

  • 确认、提交提示框

  • 时间设置根据不同错误进行错误提示

  • 在不同时间段,文字提示和界面显示更为人性化

2.有没有发现你做了一些事后看来没必要或没多大价值的事?

  • 王婷婷:有啊,写着写着就发现之前写的提示信息应该写在模型中,这样就只需要写一次写,控制器来调用即可。其他的话好像就没有了吧!!!

  • 胡心颖:有!有!有!就给按导师查询的页面赋值,做了半天,前端大大把他的页面给我,发现他把按导师查询页面和按导师修改页面合并在了一起,然后要直接用合并完的页面,之前那个单独查询的页面的赋值就白做了。好气啊。

  • 许玲玲:原本刚开始是全都自己编码的,后来发现只要用框架,就可以快速的完成。

  • 郑扬涛:绝对有!本来我负责导师分配情况界面和学生分配情况界面的前端设计,写了一部分但是由于比赛原因,没能很好的完成,于是另一位小伙伴帮忙我写完了,那我自己写的部份就没有用了,相当于白写了。

  • 陈燊:我觉得没有,我的任务主要是项目管理和所有博客的撰写,因为每次实施计划前都考虑得很清楚,所以感觉并没有做了什么没有价值的事情。整个项目的推进和进展节奏都很好。因此Alpha版本的发布也相对比较顺利。

  • 陈齐民:有,在设计数据库时,在和安卓组讨论时,感觉考虑得过多了,设计了多余的数据表和字段,在写前端的时候,有时候纠结于一个js的实现,比如界面跳转的好看与否,但是这个js其实在Alpha版本对系统的影响作用不大。在后台分页功能的实现上,我延用了TP3.2的写法,但是发现这样写是多余的,TP5.0提供了更加方便的实现。

  • 黄伟炜:在刚开始进行界面编码的时候,所有的 css 样式都是由自己纯手敲的。这样的工作量很大。后面继续学习使用 Bootstrap,发现界面的样式只要引用 Bootstrap 的 css 类就可以有很美观的效果。 虽然,前期纯手敲 css 费时费力,但是能够对 css、js、html 之间的配合有更好的理解。知道了原理,后期也就能够更快速地使用框架,来高效产生更美观的界面。

3.是否每一项任务都有清楚定义和衡量的交付件?

  • 有,因为毕设导师智能分配系统的功能比较庞大而且复杂,所以我们花了非常多的时间在需求确定上,对于每个用户组的每个功能模块,甚至是每个界面的每个按钮点击之后是什么效果,页面如何跳转,我们都进行了详细的说明,所有的需求说明都在之前发布需求说明书里有详细的说明,我们在冲刺阶段的Alpha版本开发也是严格按照需求说明书上,所以对于任务有很清楚的定义和衡量。

4.是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?

  • 我们有强大的PM,PM在每次实施计划前都考虑得很清楚,并且对每个人单独进行了issues的分配,规定了issues提交的时间,因此能够对整个项目的推进和进展把握很好的节奏,我们组相比于其他组来说较少熬夜,只是在Alpha版本发布前的一个晚上熬夜测试。项目开发较为顺利,并没有出现什么意外和风险。

  • 唯一的意外是Alpha版本演示之前,团队里的一名成员想要修改提示的功能,但是不小心导致学生填报志愿功能的崩溃,把整个团队都吓坏了,还好之前有备份好几个版本,回退到早上六点多的版本后才安然无恙。

5.在计划中有没有留下缓冲区,缓冲区有作用么?

我们有强大的PM,当然有留下缓冲区啦
  • 每个人的每个issue都有规定的时间,并且PM在仔细了解功能的复杂程度后,同一个人的不同issues的完成时间也不同,并且要求及时更新。//PM的内心真是细腻

  • 我们的开发时间提前于发布时间两天,剩下的两天时间我们一起解决了各个功能模块的一些BUG,因为PM对于项目进度的熟练掌握,我们较少熬夜,也有较充足的缓冲区来给各个成员进行交流和完善功能。

6.将来的计划会做什么修改?

  • 根据栋哥可能随时发生的需求变更来做相应的计划修改 //最有可能需要修改的!!!

三、资源

1.我们有足够的资源来完成各项任务么?

  • 相对于其他组,我们组的人力资源可以算是相对丰富的,两名经验相对丰富的PHP开发人员,一名经验丰富的前端设计、开发人员,一名ACM大神,一名学习能力超强人员,一名超级处女座、挑剔鬼但是很负责人的组长;
  • 时间资源也算是丰富,并且全体队员时间管理上也都较为合理,大家都能充分利用了校运会及其他课余时间来及时完成自己的任务,这也是我们只熬了一次夜的原因;
  • 学习资源还算充裕,刚开始组长也都有给组员们较多时间来学习,过程中会的组员带一带不会的组员;
  • 服务器资源方面,我们组已有两台服务器,且有两名服务器大神,所以服务器算是用得一方风顺;
  • 丰富的精神资源,熬夜写代码时的奶茶、甜点、烤鸭脖便是我们坚持写代码的精神食粮。

2.各项任务所需的时间和其他资源是如何估计的,精度如何?

  • 任务所需的时间估计方面,主要是组长很早就将每个人的任务布置在issues上,并规定每个issues的提交时间,issues任务精度级算是精确到每天。任务精度级算是精确到每天。至于其他资源的估计,貌似好像不怎么估计。                                           

3.测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度? 

  • 各模块的测试时间相对充足,组员每完成一个模块,PM便会及时验收,验收不合格也会及时通知相关人员进行更改。相比于各模块的测试时间来说,项目总测试(各模块合并后的整体测试)是在alpha版本发布的前一晚的凌晨2点(之前需要部署服务器啊,增加数据等等)才开始的,当时大家精神都比较萎靡不振,所以效率还比较低下。
  • 人力资源和软/硬件资源十分充足,本组共有7名组员,人数充足,且每个人都十分有上进心、责任心(都是人才啊)、服务器也都有2台呢。
  • 美工设计的难度确实是低估了,设计出来的页面不够美观、人性化;
  • 没有低估文案的难度,组长可谓是将所有精力都放在了这上面(包括博客撰写、任务分配、任务细化等),除此以外组长也会将部分文案(比如:组员各自的感想总结等)交给组员来写,全体组员都能尽心尽力地完成!

3.你有没有感到你做的事情可以让别人来做(更有效率)?

  • 陈燊(PM):作为PM,我所负责的工作便是项目管理、任务的细化量化以及实时把控项目的进度等,而且组员自身的任务都已分配到位,因此这些项目任务让组员去负责肯定不大合适。当然此外我有负责10篇冲刺博客的撰写,这些博客的撰写原则上是可以分配下去的,但是我觉得作为一个PM,通过每日的冲刺博客撰写,能对项目进度进行一个完整彻底的小结与思考,以便布置下一阶段的任务,因此我觉得这些任务分配给别人也不合适。

  • 陈齐民(PHP):有,我觉得我在前端上花费了太多的时间,而对于一个缺乏审美的程序猿来说,前端设计简直是太痛苦啦!如果我把前端完全交给另一位小伙伴,会更加有效率,我也可以全心全意的投入到后台地开发,总体效率也会更高。
  • 郑扬涛(前端+算法):对于我负责的两个前端界面,因为我中途出去比赛,导致前端学习进度比较慢,所以前端界面我觉得可能让别人来做可能更有效率。对于其它部分感觉PM分配的还是比较合理的,都有考虑每个人所擅长的方面。
  • 黄伟炜(前端):在刚开始进行界面编码的时候,所有的 css 样式都是由自己纯手敲的。这样的工作量很大。后面继续学习使用 Bootstrap,发现界面的样式只要引用 Bootstrap 的 css 类就可以有很美观的效果。  虽然,前期纯手敲 css 费时费力,但是能够对css、js、html 之间的配合有更好的理解。知道了原理,后期也就能够更快速地使用框架,来高效产生更美观的界面
  • 胡心颖(PHP):因为我们小组一共三个人写PHP,只有我没有没有基础,所以让别人做我的工作肯定比我有效率,因为对语法和方法的使用不熟悉,一个查询能反复折腾三天。让其他人来写效率肯定比我的高。而且中途还过了一次双十一,前几次开会的时候别人都是汇报自己的进度,而我一直都是:“还在学习”,github上我的issue也是最后close的。Beta版本的时候不用从零开始学习,在Alpha版本也累计了一些经验,应该效率会高一些。
  • 王婷婷(PHP):这次项目所使用框架的是ThinkPHP框架,之前的话我是没有接触过ThinkPHP的,所以刚开始写,特别特别是刚开始写的那一两个界面真的是效率很低啊,如果换做齐名效率应该会更高点。
  • 许玲玲(前端):原型界面设计,感觉自己不够细心,没有发现一些细节方面的统一性,觉得这个如果由有强迫症的PM来做,会更有效率,不会一遍一遍的被打回来重做。

四、变更管理

1.每个相关成员都及时知道了变更的消息?

  • 每个成员都知道项目进行中的变更信息。我们小组的工作内容都发布在github 的 Issues 上。小组成员都每天定时查看 Issues 信息。每当有发布 Issues ,被 assigned 的小组成员都会收到邮件通知。为了保证,信息通知的灵活性,我们小组还有一个讨论组。每个人都可以及时通知和获得紧急信息。

2.我们采用了什么办法决定 “推迟” 和 “必须实现” 的功能?

  • 首先,在接手项目的时候,我们小组就开过会讨论,并确定了项目的核心功能。而在开始十天冲刺编码之前,再次通过小组开会讨论,确定了本次冲刺要完成的部分核心功能。“推迟”和“必须实现”是这样界定的:1、核心功能中容易实现的必须在 alpha 版本实现;2、核心功能中有技术难点的推迟到 beta 版本实现。

3.项目的出口条件有清晰的定义么?

  • 小组对项目出口条件的定义是:项目能够满足《毕设导师智能分配系统》的需求。经过用户的试用,用户的反馈是满意,能够完成导师学生的双向选择。

4.对于可能的变更是否能制定应急计划?

​ 栋哥改需求,一跃解千愁!!! 这个重大的变更,我们没有应对划

  • 但是,我们有应对数据库变更的计划。我们对数据库进行了备份,能够在需要的时候使用恢复备份以及扩展数据库。
  • 在代码变更方面,使用 git 进行版本控制。当多人提交遇到问题时,能够查看每个成员的更改,并有针对性地进行版本回退。以保证被部署的代码的稳定。

5.成员是否能够有效地处理意料之外的任务请求?

  • 能够。在我们 alpha 发布前夜,听闻栋哥要改变需求。在即将完成 alpha 版本的时刻,得知这个意料之外的任务请求的我们,内心是崩溃的!但是,经过小组讨论,我们欣然地接受了这个挑战。我们将 beta 版本完成大改!

五、设计与实现

1.设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?

设计工作都是在正式编码之前完成,设计的内容有以下几个方面。

设计工作人员时间/天理由
界面原型A王婷婷,胡心颖,许玲玲,陈燊女生的审美会比男生好一点,PM负责审核
界面原型B陈燊,许玲玲许玲玲在软工课之前做过网页的原型,对工具的使用更加熟悉,可以快速的完成。
体系结构设计王婷婷,胡心颖她们两个人对体系结构设计比较了解,能够更容易的完成任务
编码规范黄伟炜,陈齐民他们两个都有做过这一方面的任务,而且两个人的分工比较明确,一个负责前端,一个负责PHP
数据库设计陈齐民陈齐民是学习PHP方向的,还有过项目经验
需求分析说明书郑扬涛郑扬涛文档写的好,而且需求分析之前是由他进行总结的

2.设计工作有没有碰到模棱两可的情况,团队是如何解决的?

  • 原型设计的时候,每个人对于某一内容的实现方式有不同的想法,界面的风格,颜色的搭配,等有了很大的分歧,最终是通过投票进行选择的。
  • 每个设计工作都遇到的PM的精益求精,根据PM的要求以及自己的想法进行整合,最终确定工作。

3.团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?

原型工具: AXURE RP

有效性: 好评4星,功能强大,但是交互性差,采用的是绝对定位,没有办法适应浏览器大小。

数据库设计工具:Power Designer

有效性: 好评5星,powerDesigner在进行可视化设计之后,可直接导成.sql文件,并且可导入mysql中直接生成数据库,不需要一个一个字段的输入,或者写sql语句生成。

测试工具: QUnit、ThinkPHP Debug模式。

有效性: 好评5星,单元测试可以增强我们对自己开发的软件的信心,以及能够使我们尽早的发现程序的 bug 和不足。

类图: Visio

有效性: 好评4星,非常好用的一款对系统和流程进行可视化处理、分析和交流的软件。

4.什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

BUG-1

标题:分页功能

步骤:学生/教师登陆

      专业导师/学生列表

      查看不同页数的导师/学生

原因:分页要传参数,容易传错,导致一直在修改这个功能的代码。

BUG-2

标题:修改功能

步骤:院负责人登陆

      选择系别

      修改最终结果

原因:数据库的主键和学生信息学号相同,导致是用主键和学号混在一起,实际上是有bug的但是并没有发现。

发布之后发现的BUG

   标题:提示功能

   步骤:学生和导师用户登陆

         每个页面提示功能

   原因:提示内容原本是前端写定,后台还没根据数据库的数据进行赋值。

5.为什么我们在设计/开发的时候没有想到这些情况?

  • 因为考虑的不够周到,觉得自己可以写,就开始写了。

6.代码复审(Code Review)是如何进行的,是否严格执行了代码规范?

  • 每个人完成一个功能,git commit 到github上面都会先审核一下自己的代码,是否有错。

  • 然后PM进行代码的审核,审核通过之后才push到github上面。

  • 每测试一遍就进行代码的审核,查错。

六、测试与发布

1.团队是否有一个测试计划?为什么没有?

  • 有比较详细的测试计划,每个模块开发人员负责相应的测试工作。具体可以参考之前的博文:【Alpha版本】项目测试

2.是否进行了正式的验收测试?

  • PM有对整个alpha版本各个模块进行验收测试(可能没有像软件需求规格说明书里面提到的那么正式和详细)。如果某个模块不符合预期,PM会立即通知相应的模块开发人员进行修改。

3.团队是否有测试工具来帮助测试?

  • 有使用测试工具来帮助自动化测试。比如前端JavaScript代码是用QUnit框架进行单元测试,而后台则是使用ThinkPHP5框架开启debug模式进行测试。然后一些UI界面、逻辑跳转等是人工进行测试。

4.团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?

  • 每次代码提交合并完后,都会默认开启TP5框架的DEBUG模式来跟踪软件的效能,查看各个功能模块的运行效率以及数据库的响应时间、文件加载情况、页面的吞吐率以及内存消耗等等;
  • 从软件实际运行的结果来看,这些测试工作还是挺有用的,比如可以测试出一段JavaScript代码或PHP代码对于边界数据的处理是否合乎期望,测试能否成功连接数据库以及相应的SQL语句的是否正常执行等等。
  • 谈到改进的话,我认为在以后的编码过程中,应该多加一些单元测试,以及测试用例应该尽可能的覆盖所有的情况。

5.在发布的过程中发现了哪些意外问题?

  • 本来已经对软件的各个流程都测试好,准备发布了。但是在临近发布的前一个小时,一个组员为了修复某个不太重要的BUG,结果导致整个软件无法正常工作。后来是通过其它组员帮助debug以及通过git进行版本回退操作,才使得发布如期进行。
  • 发布过程中用的是火狐浏览器,而之前在本机上都是用Chrome来测试,导致一些控件出现了兼容性问题,不过对于整个发布过程影响不大。

七、总结

1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

  • CMMI二级:管理级
  • 通过Alpha版本冲刺阶段的合作交流,团队目前有着一个较为系统的管理组织方式,对于老师发布的作业任务,从开会到讨论到分工再到实施,都有着一个既定的流程。而在整个流程过程中,团队组长会对项目进度实时的把控,将任务进行细化量化,并让团队大牛去带领经验尚缺的组员进行学习。所以团队目前的状态,足以应对所发布的任务需求。

2.你觉得团队目前处于[萌芽/磨合/规范/创造]阶段的哪一个阶段?

  • 规范阶段
  • 在每日的站立式会议中,通过PM的主持引导,组员把自己每天的进展情况反馈了出来,这样每个人项目的工作流程都有着一个清晰的了解。然后结合PM的任务分配,适当提出意见,以求整个任务分配更为合理。
  • 团队组员彼此之间都非常熟悉,团队一共七个人,其中有三个人和四个人分别来自相同的两个班级,之前彼此间也经常有过,所以团队之间基本不需要怎么磨合,默契度都很高。
  • 在Alpha版本冲刺阶段,组员之间因为功能的实现效果等问题,偶尔会出现冲突。但是我们小组出现冲突时,会把意见的冲突转换为前进的动力。结合每个人的想法,讨论出一个解决问题最合理的方案,然后加以实行。这样,通过 冲突—讨论—解决 反复的循环,任务的进展速度不停加快,组员间也有了更好的默契度。
  • 团队里有着有过丰富项目经历的大牛,也有对前端或则PHP一窍不通的小白,但是我们通过组员之间的互带、互相学习,小白们在短短的半个多月时间里,都迅速掌握了对应的编程语言并加以运用,开发出了较为完善的Alpha版本。
  • 我说的都队,从团队组建的第一天开始,我们的目标便是前往福州最好的自助餐厅去大吃一顿!我们有能力,有信心,有准备!我们做得很好,但要做得更好!

3.你觉得团队在这个里程碑相比前一个里程碑有什么改进? 

  • 在前一个里程碑里,我们完成了《需求规格说明书》的撰写以及界面设计和体系结构的设计,为项目的编程工作做好了充分的前期准备。
  • 在Alpha版本里程碑里面,我们在前端编程中,发现之前的原型设计部分排版和显示有点不大美观,综合组员们的审美意见等对此进行了不断的修正。
  • 通过每日的站立式会议,对项目进度以及组员进展有了一个更为清晰的了解,有利于PM进行后序任务的布置。尝到了站立式会议的甜果,在后序的团队运行中会多多采用这种会议方式。

4.你觉得目前最需要改进的一个方面是什么?

  • 在Alpha版本的冲刺阶段,由于PM的任务合理安排,以及组员之间互学互助,整体项目的进度进展得很顺利,团队暴露的问题并不多。最需要改进的方面可能便是项目的界面设计上面还不大美观,排版较为粗糙简陋,主要还是因为团队里缺乏一个美工大师。在Beta版本的冲刺阶段,我们小组会让一个成员去全权负责美工的工作,以求项目的用户界面更为友好,更为符合互联网+时代的审美潮流。

转载于:https://www.cnblogs.com/CSLaker/p/6099218.html

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

表情包
插入表情
评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符
©️2021 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值