第六次团队作业——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	王婷婷，胡心颖，许玲玲，陈燊	７	女生的审美会比男生好一点，ＰＭ负责审核
界面原型Ｂ	陈燊，许玲玲	７	许玲玲在软工课之前做过网页的原型，对工具的使用更加熟悉，可以快速的完成。
体系结构设计	王婷婷，胡心颖	７	她们两个人对体系结构设计比较了解，能够更容易的完成任务
编码规范	黄伟炜，陈齐民	７	他们两个都有做过这一方面的任务，而且两个人的分工比较明确，一个负责前端，一个负责ＰＨＰ
数据库设计	陈齐民	７	陈齐民是学习ＰＨＰ方向的，还有过项目经验
需求分析说明书	郑扬涛	７	郑扬涛文档写的好，而且需求分析之前是由他进行总结的

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

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

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版本的冲刺阶段，我们小组会让一个成员去全权负责美工的工作，以求项目的用户界面更为友好，更为符合互联网+时代的审美潮流。