【Beta阶段】展示博客

Beta阶段展示博客

 

blog software buaa

 

 

1、团队成员简介

 

 

 

 

	Email：qianlxc@126.com Free time：8:00 7:00 a.m ~ 11:00 12:00p.m Introduction： 我是一个热情的人。开朗的人。活泼的人。(小编觉得用逗号分开比较好 我喜欢交际，喜欢沟通。 我不是码农，我是工程师。 Role：写代码，整体框架与结构的设计，负担沟通接洽各个成员的责任。 Duty： Project Mannager(项目经理) Personal Homepage：http://www.cnblogs.com/SivilTaram/
Email：309143859@hotamil.com Free time：不上机的晚上 Introduction： 我觉得自己的专业能力在这个团队当中是最差的，但是我会努力学的……其实觉得目前市场上的软件功能已经逐渐覆盖包围，对于我们这样一个小团队来说要开发新的功能确实不太容易，所以我个人的想法是着眼于身边，在北航甚至是计算机学院的背景下做一些东西。 Role：任何职务（主要我觉得自己都不太会）组织要我干什么我就干什么 Duty： Reporter(文档撰写人员) Personal Homepage：http://www.cnblogs.com/lydiavitani/
	Email：1143974257@qq.com Free time：晚8点-晚12点 Introduction： c，java，安卓开发。这次团队项目我更倾向于做安卓应用或开发安卓游戏，主要是使用的是我们更加熟悉的java语言。同时java也非常适合协作开发。 Role：运动教练，写代码，协调工作=。=（你还卖萌 Duty：Programmer(代码开发人员) Personal Homepage：http://www.cnblogs.com/mnb10109/
Email：634208109@qq.com   Free time：早上4八点半到晚上八点半，并不是空闲时间，12小时工作时间。 Introduction： web后端，渗透测试。 对团队看法：我们差个牛逼的前端画网页。。目测全系也没有。。。。。。 软件工程看法：软工主要是学管人的，团队合作，这俩我都不擅长，我只提些架构上的建议，一切听领导安排。（确实差个好前端，快来个人跳槽呀！ Role：后端开发 Duty：Back-end(实力后端) Personal Homepage：http://www.cnblogs.com/hoerwing/
	Email：504037668@qq.com Free time：周一下午及晚上，周五下午，周末至少一天 Introduction： 突然发现我可以不把个人介绍搬上来呀哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈! Role：前端设计 吹比担当 Duty：UI Designer(UI设计师) Personal Homepage：http://www.cnblogs.com/kibbon/
Email：songxh_scse@126.com Free time：8:00~11:30am（周四）   7:00~11:00pm（周一、三） 以及一些零散时间 Introduction：个人编程能力不强，目前仍然在学习之中，但是我愿意学习，希望在以后的学习工作中与大家一起进步。 Role：可写代码，也可以测试，还可以提供一些想法 Duty：Programmer(代码开发人员) Personal Homepage：http://www.cnblogs.com/songxh-scse/

  

 

2、目标与实际数据

用户数据永远是我们的项目最关心的，首先来说说相比于α阶段，β阶段的我们有了哪些用户量上的增加或改变。在β阶段，我们的目标有效注册用户是1000人，目标网站流量是25000次。

   

2.1 用户注册数

α阶段团队展示时，物理实验网站的实际注册用户数是刚到300。截止至2016/1/9日12：00，物理实验网站的有效注册人数是800余人左右，达到了期望的80%。

   

2.2 域名的启用

在α阶段展示时，我们的域名备案还没有审批通过，从11.23日备案通过后，域名的作用逐渐发挥，现在受访域名buaaphylab.com已经占据受访流量的1/4。

   

2.3 访问流量数

α阶段展示时，物理实验网站的总浏览次数才刚刚过3000。如今一月半过去了，我们的网站也蓬勃发展了一个半月，虽然因为实验在校历第16周周二就已经停止了选课，从而导致整体流量的增加量在趋势上呈降低态，但是流量总数是非常可观的。从cnzz的数据统计得到，截止至2016/1/9日12：00，我们的网站流量总数已经超过了25000，达到了一个较为可观的数字。以下为cnzz的数据统计结果：

   

2.4 活跃用户数

在α阶段展示时，我们的物理实验网站交流群里的人数刚达到160人次，在β阶段结束后，已经达到了272人次。以下为群介绍与成员情况

   

3、典型用户与场景描述

   

3.1 典型用户

名字	小红
性别	女
职业	某校一般学院大三学生
物理知识层次与能力	一般般
动机	不同的物理实验老师在数据处理上可能会有不同的要求，在处理特定的物理实验数据时，和自动生成报告的数据组数不一致。
目的	希望能够有个小工具帮自己处理数据，并有一定的参考与指导意义。
困难	由于数据组数不确定，希望可以动态增加数据或者减少数据组数。
用户比例	约占同届学生20%
典型场景	小红在做1011，这个实验是需要使用逐差法做的。但是今天这个给小红讲课的实验老师好像有点不一样…哎？老师，为什么其他同学之前做这个实验的时候只需要10组数据，而我们这次就需要15组数据进行逐差处理啊？老师："我带这个实验带5年了，上我的实验就必须按我要求的方法来处理"。小红心里一阵苦涩，任性的老师真多，如果有一个能够动态计算多组数据的逐差结果，而不是只能通过固定组的数据生成报告就好了。想着想着，小红进入了物理实验网站，找到了小工具，逐差法计算器，输入数据，按照需求还动态增加了需要的组数。小红心想："这么灵活的小工具，真是造福大众啊"。

 

名字		小黑
性别		男
职业		某校学院大三学生
物理知识层次与能力	一般般，其实主要是电脑差，跟物理没关系
动机		预约实验放出的机会比较少，很难抢到。
目的		希望能有人抢到物理预约实验后跟自己一起去做。
困难		僧多粥少
用户比例		约占同届学生90%
典型场景		"你昨天抢到预约实验了吗？""别提了，提起这事我就伤心，我那破电脑，抢个预约实验简直就是做梦啊。""那你没试过在buaaphylab.com的论坛里发帖请求别人带你去一起做预约实验吗？预约实验还可以一起做，多好""你说的是真的吗？那我现在就去发帖求人带预约实验了，这论坛真是好东西！"

 

名字	小明
性别	男
职业	某校学院大三学生
物理知识层次与能力	如果够高，能不用考试吗？
动机	烤漆到了，物理实验的复习要捡起来了
目的	希望能够发帖询问自己关于物理实验考试题目的疑问并共同解决
困难	物理老师的答疑时间又太短，人太多，并且物理老师回答的总是那么几个问题，重复率太高。
用户比例	约占同届学生70%
典型场景	烤漆到了，物理实验的考试马上就要来了，"啊，我物理实验什么都不会，考试该怎么办呢？这道题我没看懂唉，可是物理老师的答疑时间又太短，态度不好不说，还给不出一个有理有据的答案。"小明心想：要是有个论坛能够用来交流提问各种基础物理实验有关的问题该多好啊，那样大家回答过的问题也能保留下来，下一届的同学还能看到，真不错。说着，小明点击进入了链接，点击社区进入了讨论版，发出了第一个帖子：论物理实验的复习。

   

3.2 场景描述

以上就是我们β阶段推出的功能所面对的三类特定用户，可以看出三类用户都是学生。

α阶段后，我们反思了关于项目初始的定位，最终在反复思量后取消了针对老师的服务，做成了专门针对学生的物理实验网站服务平台。做出这个决定的原因是多方面的：一方面是因为在α阶段后，我曾和物理实验组的负责老师的接洽，老师表示不太愿意接受这样的平台，实验组的组长是一位年纪较大的老师，她负责出物理期末考试题，因为年纪原因更加倾向于传统意义上的答疑方式，不希望通过网上论坛的方式。另一方面原因是，如果要把物理老师接纳进论坛的话要对物理老师进行实名制的认证，这将耗费比较大的精力，团队在商量后决定所有feature的开发全部基于学生用户。

在确立基本可能的需求后，我们对用户来了一次问卷调查，问卷调查的结果显示：

• 关于是否需要论坛功能，有84.62%的人觉得需要，说明论坛功能有压倒性需求。
• 有69.23%的人认为有必要认证邮箱，30.77%的人认为不需要。关于这一点，说明认为需要认证的人还是大多数，但是也有不少的人认为并不需要认证这样的功能。
• 对于自己预约了实验是否愿意在论坛上发帖求组队这一点，92.31%的人愿意跟不认识的人一起做预约实验，这是我们团队开始没有想到的。
• 而论坛中是否需要考题讨论区，绝大多数的人（92.31%）自然都认为是需要的。
• 对于是否接受论坛需要通过赚取少量积分才能下载实验报告，69.23%的人是不愿意接受的，但是这也在我们的意料之中，毕竟以前是不需要积分的。这样的机制是考虑到网站的长久发展而设想的功能。
• 积分制对论坛是否有促进作用，数据上并没有特别明确的结果，23.08%的人会更愿意水帖，30.77%的人觉得不愿意，46.15%的人觉得不知道。

调研的结果表明积分制可能会导致流失用户，所以β阶段将积分制的功能暂时搁置。而论坛的功能和小工具的feature符合我们β阶段的基本功能，说明β阶段的计划是可行的。

 

4、团队管理与协作

4.1 分工协作

单核心

　　α阶段中团队管理中主要存在的问题是，作为项目经理的我在整个流程中发挥的作用太大。一旦失去我这个中心，整个项目的各个部分都将处于一种停滞状态。每个队员的直接交互人是我，直接交流的人也是我，不和其他队员产生信息交互与分享。又由于第一阶段要通过一些例子和参考来让其他队员进行模仿学习，所以我的压力和负担很大。这种依赖关系如下所示

　　一旦失去我这个单核心，各个结点之间并不能产生关联，没有办法形成小闭环进行正常的开发：适应与沟通都需要时间和人力成本。

   

多核心的试探

在β阶段，为了改变α阶段出现的"没有项目经理等于没有一切"的情况，将每个人对整个团队影响降到最低，在商讨后，我们对整个团队的结构做出了调整，调整后的分工协作图分两条线并行

• 邢浩、鲁聃是一条线，进行论坛的搭建与前端修改
• 佘彦廷、黄雨萌、何小松与刘乾是一条线，主要负责剩下的实验数据处理、测试与实验的上线

实验处理部分的依赖关系如下图，鱼尾代表一个实验的开头，鱼头代表实验上线，1~9代表对一个实验的处理步骤。

　　而对每个人来说，比如何小松，他的每日迭代开发应当是这样度过的：

　　而对于一个整体来说，则是一个四级流水的结构，就像下面所展示的

　　同时项目经理作为每日的监督控制人员，对每个人只起督促作用，但不再作为主程序员控制最关键的一环。代码开发的工作量减少，主要是负责协调进度与前后耦合沟通的部分。这样即使我因某些因素请假没有工作，只是会有一部分的工作停滞，不会产生大面积停滞的情况。

　　而另一支线则是我部分参与沟通的，主要由后端工程师邢浩与前端工程师鲁聃直接交流与沟通的环状结构。

   

　　两路并发给我们带来各个部分比较高的自由度。第二阶段在为前端工程师定任务时我与以往也不同，遵从了自由制定，部分跟进的制度。前端能否做好有些时候靠设计和灵感。所以我为前端工程师预留了足够多的空间与自由安排的时间，所以可能你看到的Scrum meeting是这样的：

　　受限于前端工程师本身的时间、精力与行业特殊性，所以我冒险让其采用了上述自由安排进度的策略。最终中间过程不够理想，但是结果也算是没有辜负我的期望。

4.2 质量控制与评价

• 测试：　　　　    ★★★★☆
• 代码规范：　       ★★★★☆
• 文档：                 ★★★★☆
• 需求分析与反馈：★★★☆☆

 

由于α阶段测试不足，在β阶段我们恶补单元测试，严格要求测试与开发并行。本轮迭代涉及到了如下几种测试： 

• 单元测试 
• 黑盒测试 
• 回归测试 
• 压力测试

 

单元测试与自动构建是通过drone.io来完成的。它一样可以和Github紧密结合，每次push都能自动运行单元测试。但是与Travis-CI相比最大的优势在于登陆速度很快...Travis-CI的自动构建虽好，但是在国内比较难用。

本次黑盒测试共测试出了 10条bug，有1条尚未修复

编辑栏状态不稳定，图标无法完整显示。Issue链接：https://github.com/buaase/Phylab-Web/issues/194

其余9条已经全部修复完成，以下为bug清单：

• 只有主页的导航栏里有小工具的跳转链接，其他部分的导航栏里没有。
  • 　　Issue链接：https://github.com/buaase/Phylab-Web/issues/192
• 在论坛的编辑框内无法上传附件，最后发现是因为编码问题。
  • 　　Issue链接：https://github.com/buaase/Phylab-Web/issues/189
• 个人资料页里在保存了网站和QQ后失效，无法成功保存。
  • 　　Issue链接：https://github.com/buaase/Phylab-Web/issues/188
• 编辑栏的bug，在编辑东西时无法完整显示出编辑栏的各个状态。
  • 　　Issue链接：https://github.com/buaase/Phylab-Web/issues/187
• 点击社区不能跳到社区主页，跳到个人资料页，点击phylab按钮不能回到网站主页。
  • 　　Issue链接：https://github.com/buaase/Phylab-Web/issues/184
• 图片超过一定大小无法上传作为头像。
  • 　　Issue链接：https://github.com/buaase/Phylab-Web/issues/185
• 在资料保存成功后，提示的图片的那个带感叹号的三角形很奇怪。
  • 　　Issue链接：https://github.com/buaase/Phylab-Web/issues/186
• 只有主页的导航栏里有小工具的跳转链接，其他部分的导航栏里没有。
  • 　　Issue链接：https://github.com/buaase/Phylab-Web/issues/192
• 上传附件的按钮消失，不同权限能看到的情况不同。
  • 　　Issue链接：https://github.com/buaase/Phylab-Web/issues/195

本次还针对之前的主页和其他等进行了浏览器的兼容性回归测试，并使用siege进行了压力测试，测试覆盖较为全面。

没有给团队的测试打五颗星，是因为还没找到支持drone.io的代码覆盖率github插件，所以暂时没法给出代码覆盖率的测定结果。

本轮迭代做得比较差一点是用户的需求分析和反馈。主要原因是在论坛的使用上还没到高峰期，论坛功能的出现时机处于一个比较尴尬的位置。并且团队缺乏宣传推广方面的新鲜创意，尽管最后使用了一些题目有关的帖子来引导用户从群聊模式转向讨论区模式，结果还是不太奏效。

代码规范方面，除了后端的php文件的代码规范外，在写数据处理前，专门定义了实验处理的代码规范与模版文件： 

   

 

5、团队项目实际进展

   

5.1 燃尽图

我们在β阶段的燃尽图如上所示，可以从燃尽图的变化看出我们团队项目burndown图的动态变化。每天都有完成一部份工作，但是完成的进度比较缓，没有预想的那么快。现状也的确如此，在α阶段项目经理new并close个70个issue，而在β阶段，issue上涨到了123个，增加了仅53个而已，去掉bug所代表的issue，其实真正做的开发近乎于于α阶段的一半而已。

我们反思了这种情况的出现，最后发现，β阶段任务完成率不高主要是因为：团队项目与队员们其他课业——主要是编译课设的冲突。

   

5.2 冲突

与无忧无虑可以天天做软工的α阶段不同，β阶段，团队面临着两个很难处理的难题：

• 编译实验带来的心理压力
• 包括课设、复习在内的课业带来的团队项目时间上的极度压缩

这两个难题一旦解决不好，团队的挫败与溃散是在所难免的。

前五次scrum meeting里，项目经理的心情是沉闷的，每次开会时表情是这样的：

 

• 队员的频繁请假　　                    ——"今天我想请个假...编译调不完了"
• 自己面对编译实验的巨大压力　　——"TuT，我的编译怎么办...没时间做了啊"
  
• 计组实验有学生作弊带来的坏情绪——"什么？你确认他作弊了吗？"

 

　　我甚至曾一度想放弃团队项目。那段时间里，每天回到宿舍就是愁每天的scrum meeting该如何写。我不想造假，但是又担心开会时有些队员又是一事无成。心理压抑，矛盾，队员的不理解，面对团队项目，我每天都是想着如何能够撑过今天的scrum meeting，总是安慰自己：挺住，撑过今天就好了。

　　为了能让团队项目依旧保持其活力，必须将团队项目作为最高优先级的我，舍弃了一些机会。作为表率，我的行为鼓舞了每一个队员，最终换得了项目每天缓慢但是持续的进展。第六次scrum meeting，会上丽叔说wecenter和laravel的对接初步成功的时候，团队活力复苏，一直撑到了最后。

　　这次危机也让我充分意识到两点：一个是团队需要有共同理想才能在面对艰难困苦的时候撑下来，否则一个团队里的成员非常容易在"大难临头"的时候各自飞。另一个就是，项目经理的心理素质真的要足够强大。

   

5.3 流水结构的弊端

在实际的开发里，即使遵循多核心的分工协作，项目仍然遭遇了比较严峻的考验。流水线开发的弊端在于，只要有一个人请假或停滞了开发，需要其产出作为输入的后续方将无法很好地进行开发。而在编译实验和团队项目β阶段几乎一直打架的情况下，想努力维持每次scrum meeting都没有人请假的情况几乎不可能。

就像是流水线里阻塞了一样，我们团队的开发也因大大小小的请假被迫延误了至少两天的完整工时，这一点是流水结构的弊端所在——影响均摊，结果整体风险加大了——因为每个人都占了一定的主导地位。

5.4 不可替换

在 β阶段，我在分 配任务时遇到的比较大的问题就是队员工作转型的问题。因为第二阶段前端需要开发的东西不算多，而我们第一阶段后将一名后端人员转离团队，所以团队在商议 后，想把佘彦廷同学调离前端的岗位，进行后端的处理。但是在操作时遇到了问题，不管是python还是latex，想写出有质量保证，可用的东西，学习耗 去的时间成本太高，最终为了不让每天的scrum meeting都是学习和请假，还是没有让佘彦廷同学学习python，转向后端的处理。

在 反复思考后其实才能明白，学生阶段与工作生产环境存在差异，可能会出现各个人学习能力与分配任务的不匹配。学习付出的时间成本是较大的，每个人所做的工作几乎都是不可替换的，比如只有邢浩一个后端，只有鲁聃一个前端，只有我这样一个能统筹规划写博客的项目经理等。每个角色的代入感很强，但是一旦在某个职位上缺少某个人，那么一个团队依旧可能会溃散。每个人都是不可替换的一份子。

   

5.5 实际最终成果

实际上，第二阶段大家在开发上所开发代码没有第一阶段多，但是第二阶段全员参与使用了github，情况如下：

这一点是相对α阶段做得很好的一点，全员参与github，大家都也熟悉了一些基本的git操作。

 

   

6、贡献分配

姓名		具体贡献		贡献分
刘乾		412行python代码 10篇scrum meeting 测试报告 发布说明 源代码管理博客 评审展示博客		60
何小松		1800行python代码		61
鲁聃		Wecenter更改配色与前端部分界面 小工具页面		49
邢浩		800余行php代码 完成了laravel到wecenter对接思路设计与实现		55
黄雨萌		6个Latex无关文件 部分测试报告		40
佘彦廷		一次调研 调研报告 400行js生成模态框 12个正确测试数据 部分测试报告		35

 

7、特色功能展示

论坛功能

小工具页面

 

8、技术难点与设计理念

8.1 遇到的技术难点

laravel主站服务和wecenter的对接

首先，两个服务虽然使用了完全不同的架构，我们的需求就是，让其能通过数据库进行交互和对接，并且现阶段的一个必要任务就是让这两个服务的用户模型在数据库中统一，并且登录和注册要共用一套接口。

在数据库的合并这个问题上，为了不让两者除users外的表发生冲突，我们在安装wecenter时给其设置数据表的前缀，这里设为wc_，之后我们保留原来laravel数据库中除users外的所有表，之后，我们把laravel的users表中的password字段更名为labreport_password，id更名为uid，其他字段不变，这样我们把这张表的结构和数据导入到wecenter的wc_users表中，这样的话算是把两者的数据库合并了，为了不改变laravel已有的代码结构，我们从wc_users表中导出一张名为users的view，view中各列与原来laravel的users表完全相同，这样就完成了其在数据库层面的对接。

之后，在统一登录和注册接口时，因为我们已经有了四五百的注册用户，我们无法从其在数据库中加密的密码来得知其密码明文，然而wecenter需要一个密码字段，我们又不能让这五百注册用户挨个改密码，这样我们想到了一个解决方案，我们在后台给wecenter设置一个全局的密码，所有用户的密码都用这个加密后作为密钥。这样的话，我们的登录接口使用laravel的登录接口，之后主站就得到了登录凭证session，之后，我们在登录wecenter时，用这个session本地回环访问（即使用I/O）主站，从某个接口中获得用户的登录身份，之后使用这个身份验证并登录wecenter，获得wecenter的cookies。

在登录wecenter时有一个登录跳转界面，这是因为wecenter登陆时有大量ajax请求，所以我们保持了其原有登录界面的结构进行登录。

关于注册接口，因为wecenter的用户表中有大量与其逻辑有关的附加属性，并且这些属性很难被我们完全控制，也就是说不好直接编码添加这些字段，所以我们不能使用主站的注册，而使用wecenter的注册接口，而主站的用户的字段我们都是可控的，都可在注册时添加进去。这里有个比较坑的地方是，laravel的密码加密方法与框架耦合非常紧，我没有做到把其算法编码实现，所以，在注册填写labreport_password字段时，我们也是使用了本地回环请求laravel的某个接口获得加密后的密码，填写入密码字段。

按照上述这样，我们就完成了用户注册和登录接口的统一。

8.2 设计理念

http://www.cnblogs.com/kibbon/p/5117674.html

9、总结

开发人员的一些感想：

佘大爷>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

M2期间其实出过许多的问题，因为毕竟不是只有这一门课，大家都有许多其他的事需要做，时间上不能分配的那么理想，组里的人也出过很多的矛盾还有意见分歧，PM天天晚上愁眉苦脸的，因为随着其他课程难度的加大，大家没有那么多的时间可以分给软工，无法按时完成任务PM也不好写scrum meeting，于是就很郁闷。其实我们完全可以像某些组那样去杜撰scrum meeting，但是我们并没有选择那么做，我不知道其他人是怎么想的，但是PM和我都是把这当做一个正式的项目去做，而不是作为一门课程的作业。组里一些人把软工放在了优先级稍微低一些的位置，而使得PM没办法尽快写出工作进度，这样的日子持续了快一周，看PM实在受不了了，感觉团队失去了活力，大概，我永远就适合当那个坏人，把一切不能说那么明白的事去跟人说出来。从那天开始，大家都开始把软工放在优先的位置了，所以即使第二阶段时间那么紧，我们依然按时完成了任务。当然，代价是有的。组里很多同学放弃了编译的一部分分数，把时间都拿来做软工了，不过这样也体现出了类似于面对工作和其他事的矛盾，我们真的把这个项目当做自己的工作了。

第一阶段的展示效果特别好，其实我们有时候都觉得第一阶段展示的东西太多了，毕竟我们网站最主要的功能就是那些，第二阶段主要就是让实验的覆盖数量更大，然而这在展示效果上并不好，不过幸运的是，我们还找到了其他可以开发的实用功能，使得我们的网站功能更加完善，更加多元化。

我们认为，产品存在的价值就是，实用而且用起来舒服，要有连自己用起来都觉得非常舒服的用户体验，即使是小细节我们的前端工程师也一丝不苟的完善着，这就是我们强大的原因。我们是一个团队。

松哥<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

不知不觉，一学期的软工即将结束了。这学期我们的任务很重，比以前任何一学期的任务都要重，但是比以往的任何一学期都要有意义。软工则是这学期最有意思的一件事。

在软工开始的时候，从个人项目开始，我真的是想好好做，但是对于一个暑假都没有接触代码的我，完成实在是有点困难，而且那个时候自己的能力并不高。因此，软工的个人项目就水水过了。结对项目的时候，渐渐地回复了感觉，直到M1阶段，我开始意识到，必须做出改变，于是，逼了自己一次。

在M1阶段的时候，学习了很多东西。从一开始的matplotlab，只是学了皮毛，虽然没派上用场，但是自己学了；然后就是Python，学习了之后发现Python是一个很好用的语言，以前在上密码学课程的时候就接触了Python，这一次深入的学习了一下Python，感觉很不错；再然后就是LaTeX，当时迫于团队的进度和项目经理的任务量大，我开始学习LaTeX，分担一些项目经理的工作，现在想来，学习LaTeX真是一个不错的选择。总之，学习和练习是M1阶段的主要工作吧。现在想来，要是我能事先掌握这些工具，M1的时候就不用过得这么累了。

在M2阶段的时候，主要就是课程上的压力。到学期末，很多课程都要面临结束，有大作业，有考试，因此，这个阶段主要就是时间上的安排。因为当时实验室的工作停下来了，所以我的时间可能比他们都多一点吧，然后就尽力多做一点东西，让我们可爱的软工项目能够活下来，而且活得更好。所以M2阶段主要就是心智上的成长，我们逼迫自己去完成一些以前看来不可能完成的任务，事实上也证明我们可以完成。

最后，我要感谢这个团队。团队中的每一个人都是那么可爱。每一个人都在项目经理的安排下，努力地完成自己的任务，提出自己的合适的想法，让我们的项目变得更好。我们都很累，但是我们合作，让每一个人原本的累轻松一点（合作愉快！“软件攻城狮”们！）。所以要感谢这个团队，因为这个团队，我成长了很多很多，谢谢！

萌萌>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

在整个软工项目的过程中，发现实践的重要性。在课本上或者在论文中的知识其实都是对实践中情况的总结和升华，但是单单从字面上还是不能体会到文章中真正想 表达的意思。从大的主题上把握，我的体会就是，没有万能杀器，只有适合的道路才是更好的。（P.S.从这句话看来整个体会是又红又专的）

    交流沟通方面。在我们的团队中，主体是一个宿舍，其余的队员也是一个班的同学或者熟识的朋友，因此在交流沟通方面的成本不大，精力可以更多地放在对项目本 身的安排上面，然而对于那些队员之间比较生疏的团队，我认为还是要在交流沟通方面下大工夫的。这一点在在一切运行顺利时不能体现起重要性，但是在遇到问题 的时候格外重要，因为与交流沟通直接相关的就是任务分配和合作。一个团队的配合和分工在项目中有多么重要相信只要经历过这个过程的人都回有体会。

     团队中角色认知方面。举个例子来说吧。我是在第一阶段体会到项目经理的重要性的。在正式接触一个软件工程项目之前，我认为的PM是一个相对而言的“闲 职”，不需要过多地码代码，只要把握整个项目的大方向即可，只一点直到看完书、参考资料也没有太大的改变。现在再回到正题，实践才是检验真理的唯一标准。 在项目的第一个阶段，我就发现了PM在整个项目中起到的是连接与动力的作用是多么重要。还是像之前说的，我们团队的项目经理坚持在每天早上或者前一天的晚 上将每个人一天的任务放在群里进行公示与明确。并在每天晚上检查今天任务完成情况，以便及时调整项目进度。以我自己的切身体会，每天的任务和汇报机制逼迫 我每天不得不挤出时间来做团队项目，从而保证了工作量。到了第二阶段，由于项目本身从磨合进入到规范阶段，我们的配合很大程度上已经取决于之前建立的不成 文的分配规定，PM的工作量就没有那么大了，但这也是在项目初期打下了的底子才能撑起来的。

    个人时间安排方面。书本上或者文章中的知识基本上是对于一个专业的软件工程团队提出的。而我们的情况是，在进行一个团队项目的同时还要面对别的课程的压 力，时间安排这一点上几乎没有可参考的内容。这时候发现前瞻性是多么地重要！！！我们的项目在alpha阶段完成了大部分的工作，这一段时间编译课设还没 有开始，时间相对充裕。为迎接之后编译数据库课设打好了可以吃的家底。如今顺利结束，回想一下，如果当时拖延，想着将任务放到后面做，想来在14-17周 的生活会相当相当难过。

     再次回到大主题吧，实践出真知。我认为6、7班的软工课程是比前大班成功的，就是因为有了一个真正的项目来给我们实践、让我们思考和体会软件工程文字的 知识是怎么应用到现实的。然而实话说，在本学期做软工的过程中，我内心曾经真的十分抗拒这门课。倒不是因为课程本身，而是时间安排的问题。当我知道我们的 软工课程考核方式是如此不同的时候，内心十分不平，认为我们付出了不同的时间精力却拿同样的分数，加之这个学期还有编译和数据库的压力，看着室友优哉游哉 生活过的滋润自己却在软工的水深火热之中内心很是不平，相信很多同学应该都有这个体会。但是我也说了，其实这样设计很好，唯一的不足在于应该把这门课与有 压力的课程分开安排。或者干脆大家一视同仁，一起辛苦，没有了心理落差或许好很多。

乾<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

一个团队只有在经受到巨大的压力与挫败的时候才能体现出它真正的凝聚力。我们团队的凝聚力不一定是最高的，行动证明一切。

最后，再热情拥抱软工这门实践课，感谢这门课让我们团队的人凝聚在一起，也感谢这门课最终让我们收获良多。

不仅是编程能力上的，更多的是关于人、协调、团队合作、团队冲突等方面的经验与感受，相信每位队员都收获颇丰。那么最后以一句话来作为团队项目的结尾：

再见，软件工程！