[敏捷软工团队博客]The Agiles 团队介绍&团队采访
| 项目 | 内容 |
|---|---|
| 课程：北航-2020-春-敏捷软工 | 博客园班级博客 |
| 作业要求 | 团队作业-团队介绍和采访 |
团队名称来源
The Agile is The Agile.
敏捷就是敏捷。我们只是敏捷的践行者罢了。（狗头
团队成员
| 头像 | 姓名 | 博客园名称 | 自我介绍 | PM | 测试 | 前端 | 后端 |
|---|---|---|---|---|---|---|---|
 |
段zx | 秃头院的大闸蟹 | 大闸蟹是1706菜市场里无菜可卖的底层水货。大闸蟹喜欢音乐（但可惜不会），喜欢lol（可惜上不去大师），喜欢pokemon（可惜买不起游戏机）。虽然大闸蟹能力不突出，但大闸蟹认真负责任劳任怨。希望在这门课中与大家成为朋友，一同努力奋斗，收获知识，并结下羁绊。 | √ | √ | ||
 |
陈c | cc17373432 | 喜欢像素rpg。c,java,python,c++都用过，但是都不熟。希望在这学期的软工中和大家共同进步。(争取不拖后腿！) | √ | √ | ||
 |
杨jy | MagicJim | 1706底层群员，无名小卒，在1706菜市场买菜时于一水产摊子前相遇组员大闸蟹。没有特别的喜好，没有特别的专长。学过C和Java，还会一点点C++、Python和Ruby。之前没有接触过软工，也没有参加过团队项目。虽然经验不足能力有限，但是交付的任务不咕不鸽，保证认真完成。希望能向同组的大佬们好好学习，在这学期的软工课程有所收获。 | √ | √ | ||
 |
王jx | Kidogu | 目前可以披露的情报：熟悉C, C++, Python, Java, 有一定编程经验。刚刚接触软件工程，不够熟悉，希望和大家携手共进，斩获佳绩。 | √ | √ | ||
 |
迟ss | sugarorange | 1706底层群员，无名小卒。奶茶里喜欢加的配料是奥利奥和脆波波。希望和大家合作愉快，加油，奥利给！ | √ | √ | ||
 |
杜lf | blueshift | 星际玩家，最近因狂看CPP Reference视力进一步减退。目前掌握的编程语言有：C/C++(accumulating)、Java、Python(limited packages)。期待与各位敏捷侠开发出让用户满意的软件。 | √ | √ | ||
 |
滕q | starmiku | 干员星级：★★★★。招聘合同：大水群群员滕琦，将 |
√ | √ |
前辈采访
我们的采访对象是周雨飞前辈，他们的团队博客为BuaaRedSun。
问题1：请问你们当时具体做的是一个什么项目呢？
我们当时做的是一个为 北航校内社团提供信息发布、成员招募和社团管理功能的平台 ，以微信小程序的形式呈现给用户。
问题2：当时大概有多少社团使用呢？现在还有社团在用么？
在学期结束的时候一共有67个社团入驻，50个社团使用过我们提供的配套的网页端社团信息编辑工具进行过编辑。目前现在这个项目暂时处于搁置状态（因为课程组提供的服务器资源到期了），没有用户即时使用了，但是用户信息依然有留存，如果有需要的话可以随时恢复启用。
问题3：那请问这个项目能否给我们这一届学生继续开发，源代码/文档还有么？
可以，由于我们当时使用gitlab进行版本管理工具，所有的源代码都有所留存；我们采用的前后端分离的开发模式，开发人员针对各个工程都撰写了完善的文档，也都在gitlab中存储着。源码和文档都有，继续开发应该没有问题。
问题4：请问当时你们组内沟通是否有效，如何保证有效沟通？
我们当时组内沟通比较有效。我们根据成员分工的不同建立了不同的工作小群，有任何问题的话会先在小群提出来，如果问题在小群内无法得到解决再上报大群大家一体解决。每天晚上我们还会召开工作例会，每个人展示自己今天做的工作并与其他人交流问题。持续、定时的例会作为沟通方式对于保证沟通的有效性来说是非常必要的。
问题5：在一开始大部分人都不知道自己具体能干什么的时候你们是如何分工的？合作了一段时间后分工有变化么？
我们一开始确定组内成员之后立刻就先交流了一下自己擅长的领域；有些人擅长前端就去做前端，擅长后端就去做后端，以技术栈作为大的分工标准；之后由产品经理划定产品的功能以后，对前端/后端内的小功能进行更细粒度的分工，交给每个人去做。前端/后端/产品经理/运维的分工我们在alpha/beta/gamma阶段都变更过，因为组内成员想体验一下不同的开发工作，也想对整个项目的全貌有着更好的理解。总体上而言分工不是特别大的问题，只要每个人都对自己的技术能力有正确的认识，并且能认真负责地对待项目就好。
问题6：也就是说一开始你们团队成员都对自己的能力有着明确的认识么？
应该是比较明确的，至少以前应该接触过某方面的开发，并且知道自己了解这个技术领域的基本知识；即使这样的认识不够准确，因为有着良好的基础，后续学习起来也不会特别困难。所以建议你们一开始就沟通一下各个组员的技能，以便更好的分工。
问题7：多谢学长的建议 那请问你们工作小群是采取什么工作方式，是每个人都有具体的任务单干，又或是像结对那样分成两人小组还是其他的工作方式呢？
每个人都有具体的任务单干；每日任务统一由项目经理在前一天晚上进行划分，并且得到组员的确认。在小团队中这样的工作方式相对来说高效。
问题8：请问你们是怎么管理进度的？你们的项目花费时间和预期一致吗，是否出现超时的情况，如果出现了，是什么原因导致的，最后又是如何处理的？
我们管理进度的方式是在每个阶段开始的时候先进行阶段总体目标规划，每周会由项目经理定出一个每周目标，然后在每日例会上由项目经理牵头大家一起讨论出自己接下来的一天要做的事情，并在第二天晚上的例会上加以确认；我们几乎没有出现超时的情况，偶尔会因为技术的困难性导致有些任务无法按预期时间完成，这个时候其他组员会分担相关的工作，尽快赶上进度。为了避免超时，最好一开始规划进度的时候就预留一点时间，以避免临时发生的意外。
问题9：请问正常情况下每个人每天在这个项目上花费的时间有多长，每天时间表是怎么安排的？
正常情况下每人每天在项目上花费的时间在1-8小时不等（取决于当天忙不忙），每天的时间表就是由项目经理在和组员讨论出下一日的任务后，汇总到一张总表上，并在当晚的每日例会上对完成任务的情况加以确认和记录
这是我们的alpha阶段贡献表，每日任务表和这个差不多，只是没有贡献分的部分。
问题10：那你认为项目经理每天为每人分配的工作量为多少小时最合适?
我认为这个不能僵化，还是要看组员自身的情况；事实上我们在分配任务的时候并不是以时间为基本单位，而是以任务为基本单位，每天组员上报自己完成相应任务所需的时间，并得到所有组员的认可。最后通过任务难度和花费时间综合评估出贡献分数。我觉得正常来说，平均每天2-4个小时的工作量是比较合理的.
问题11：请问你们当时是刚完成软件的基本功能就发布 之后再去优化，还是在发布的时候已经是一个比较完备的状态？
由于我们用的是微信小程序作为最终产品，小程序平台本身提供了在 开发 和 发布 之间的一个中间状态，叫 预览 。我们会把每日开发的工作合并到小程序预览中去，大家一起做检查/这个预览和最终的发布版效果几乎是一样的。因此最后我们是全部测试完成，达到了一个比较完备的状态之后才正式发布出去，但之前在内部已经进行了多轮准发布测试。
问题12：那请问当时你们团队贡献度是怎么分的？是严格按照图中的得分来分 还是 考虑到同学之间的关系所以分的比较平均？
严格按照图中的得分来分。由于大家每日例会对自己的进度交流得都很充分，也得到了全体组员的确认，因此最后没有出现什么矛盾。
可以参考我们的贡献分汇总博客
问题13：请问你们在这个项目的开发中有什么经验和教训？
最主要的经验就是项目组需要一个认真细致负责的项目经理和一个技术足够强大的技术带头人（恰好这两个人现在都是你们的助教）。此外，每日例会、各位组员公开自己的任务进度、单人负责制对于项目的开发都是非常有积极意义的。至于教训，代码的复审不能放松，要从始至终保持高质量，不然很可能后期会发生项目质量滑坡。
问题14：请问你们刚接手的时候这个项目是什么样的 或者说 你们团队为这个项目新增了哪些功能？
这不是我们接手的项目，我们从零开始完成了全部功能。
问题15：学长认为这个项目有什么你们想实现但是没有实现的功能么？
我们原来想做入会申请、申请通过等等消息通知的实时微信通知推送，但最后限于微信的政策限制放弃了。这个功能很难绕开微信，可能得自己开发独立的app才能实现了。
问题16：之前说过这个项目已经很完善了，那学长认为继续开发的空间有多大？
我觉得继续开发的空间还是有的，可以在界面和交互上多做一些功能，以及社团信息导出等功能，但确实相比从零开始一个全新的领域，这个项目的开发空间没有那么大了。
问题17：最后想请问学长对学好软件工程有什么建议？
我的建议是积极学习积极交流，千万不能因为和组员不熟而埋头闷着做自己的东西，最好一上来大家先一起开个会之类的。每日例会真的非常重要，保持长期的高效沟通对软工项目帮助非常大。从个人角度来讲，不要惧怕软件的复杂性，毕竟再庞大的项目都是从一个个小的原型开始的。使用搜索引擎多学习、多掌握一些技术，试着从架构的思想考虑代码的组织形式。大概就是这样。
实际花费时间记录
本次采访耗时为90分钟，小组首次会议时间为20分钟，博客写作时间为30分钟。
