软工团队 - 预则立&&他山之石

软工团队 - 预则立&&他山之石

团队任务计划

时间	人员	任务
10.23-10.29	张昭锡	初拟Android代码规范
	李永盛	初拟PHP代码规范
	刘晨瑶	初拟Git代码规范
	刘晨瑶	组织对规范文档的讨论、修改完善规范文档肯定终板
	李永盛	服务器测试、框架搭建
	苏伟鹏	学习项目的PHP框架
	陈龙江	学习Android测试工具的使用
	张昭锡、熊立强、陈龙江、胡俊钦、骆景昭	学习Android MVP模式、对照项目需求和原型界面学习Android控件
	李永盛、张昭锡、刘晨瑶	初步架构设计
	刘晨瑶	需求规格说明书终板
	刘晨瑶	完善原型设计
10.30-11.05	刘晨瑶	Alpha终板原型
	刘晨瑶	组织讨论和修改架构设计
	陈龙江	编写测试计划
	李永盛、刘晨瑶	接口设计文档
	李永盛、苏伟鹏、刘晨瑶	数据库设计
11.06-11.16	刘晨瑶	组织每日站立式会议、把控项目进度
	张昭锡	Android MVP模式框架搭建
	张昭锡、熊立强、胡俊钦、骆景昭	Android客户端编码
	陈龙江	客户端测试
	李永盛、苏伟鹏	服务器端编码
	李永盛	服务器端测试
11.17-11.19	李永盛、张昭锡、熊立强、骆景昭、苏伟鹏、胡俊钦	项目完善
	张昭锡、熊立强、胡俊钦、骆景昭	学习和初步实现推荐文章算法
	李永盛、苏伟鹏	学习垃圾过滤算法
	刘晨瑶	收集用户试用反馈，造成总结和改进方案
	陈龙江、刘晨瑶	测试计划改进
	刘晨瑶	Alpha阶段总结
11.20-11.26	刘晨瑶	组织每日站立式会议、把控项目进度
	张昭锡、熊立强、胡俊钦、骆景昭	完善客户端编码、加入推荐算法
	陈龙江	客户端测试
	李永盛、苏伟鹏	完善服务器端编码、加入垃圾过滤算法
	李永盛	服务器端测试
11.27-12.03	张昭锡、李永盛、骆景昭、苏伟鹏、熊立强、胡俊钦	正式版本完善
	陈龙江	同时在线人数等压力测试
	刘晨瑶、张昭锡、胡俊钦	撰写用户手册
12.04-12.10	刘晨瑶、胡俊钦	撰写宣传文案和推广
	刘晨瑶	发布正式版本、做出开发总结

细化后的issue：https://github.com/StardustProject/Stardust/issues

他山之石采访记录

采访是的“一不当心就火了”队，队长逸超学长和咱们团队的个别成员认识，交流起来也至关的轻松愉快~

项目开发经验

• Q： 咱们有看到其余学长写到，项目的开启能够由一个比较有经验的人把项目的架构写好，而后再由其余人进行填充，可是负责安卓端的开发人员都没有项目经验，如何开启一个项目？
  A：咱们当时是写着写着就写起来了，就我本身来讲，安卓的话，到目前为止，整个项目的结构大概就是activity，adapter，请求代码工具包之类的。具体的话，能够学一下MVP模式，尝试一下。用这种方式的话，整个工程结构、层次确定比较清晰，可是初期可能会碰壁，遇到不少坑。或者说大家也能够用本身的一套规定。​

• Q： 关于接口方面，有什么建议，须要团队一块儿制定吗？
  A：接口的话，至因而不是一块儿定义，若是其余人都不熟悉的话，由熟悉的人一我的来定义也是能够的。另外，接口文档要写好，记录工具的话就不要再用word了，咱们本身的经验就是后期文档太乱，多使用协同工具，apizza能够尝试使用一下。

• Q： Android客户端和后台PHP端有使用什么框架吗？
  A： Android端的话好像没有。可是大家Android不是要作图片，通常不本身写，能够用glide，网络请求库的话，如今比较流行的是Retrofit+RxJava。PHP端咱们当时用的是ThinkPHP的框架，固然作接口开发的话，也有不少轻量级框架能够用：Lumen、Slim。大家已经搭好的Laravel，比较倾向于全栈方向，属于比较集成的，固然这些框架的选择，只要大家以为OK，均可以。

• Q： 咱们对项目测试尚未一个清晰的概念，学长能说说要如何测试及制定测试计划吗？其中要注意一些什么吗？测试是手动测试仍是自动测试，若是是自动测试用的什么工具？
  A：当时的软工项目上，咱们没有主要的项目测试人员，项目基本上没有什么测试，写过一个自动化测试测试过登陆界面，主要是对接口进行一些测试。大家要作的话，能够写一些单元测试、自动化测试，对每个功能函数进行测试。对于服务端接口的测试，经过堆栈发起请求去请求接口，进行压力测试。目前暂时能够不考虑高并发问题，项目后期，对于这个问题，能够考虑限制流量方式来解决。

• Q: 看《构建之法》里面说到测试驱动功能，我在结对做业中使用的是测试先行的方式，结果编码量和编码时间都指数爆炸。学长是倾向于测试驱动功能呢仍是先写功能再测试？
  A: 通常我写是先写完再测试，好像无论是公司里面仍是其余团队都是这个样子。

• Q: 整个Alpha阶段只有10天，编码时间相对紧。在这么短的时间内发布一个release版本，是一个什么概念？
  A: 建议的话就是，大家在作以前要把各自的工做给作好，分工要明确。由于咱们以前作的话，最开始分工不明确，并且当时相比咱们上一届，4我的，他们人数更少。这种编码的工做不是人越多写得越快，由于大家还要解决各类冲突，包括代码的冲突，还有队员交流这些。因此这个就须要组长好好协调。

• Q: 团队成员基本没有项目经验，学长有没有什么建议？
  A: 这才是锻炼啊！Android端，个人建议就是，learning by doing，就是你要这个功能，就去找，以后想深刻了解的话，再去扩展。大家如今作的东西都是会去用而已，好比大家要去实现什么功能，就去把这个控件学一下怎么用，然后面若是要深挖的话，就不是只是会用的程度了，要去了解底层是怎么实现的。因此大家这个阶段没作过什么是不要紧的，就是基本上要去学会怎么用，若是有兴趣的话再去深挖。你要写这个东西的话，最要看的就是，他整个逻辑是怎么传递的，若是你搞清楚了的话，顺着那条路慢慢写，最后确定写的出来。

团队成员协做

• Q： 有出现团队里某个队友进度落后全团队都在等的状况吗？这时候怎么办？
  A： 咱们当时的服务端的接口都已经完成了，可是其实咱们是在Alpha阶段最后一天才开始对接口的。致使这个的缘由主要也是分工不明确。分工模糊，咱们那时候项目有四个端，不少东西是重复，好比查看结果是同样的，后面对于重复的界面要用谁的，就炸了，谁也不服谁。

• Q： 学长们都说好基友千万不要在一个团队是为何？是后期冲刺常常闹矛盾吗（我的能力致使代码没法交付亦或是由于以为他人写的代码“过丑”）？团队情绪如何把控？
  A： 写代码就会有冲突嘛，主要你们要相互理解。咱们当时Alpha阶段，安卓端的开发人员就有三人发生冲突。每一个人能力不同，掌握的技能也不同，走在前面的人可能须要等待刚开始起步的同伴，这时候就要耐心一点，固然，每一个人手头上有可能各类事情，在这种时候要表现出足够的耐心也是比较难的。另外，各类规范要制定清楚，也能减小一些冲突的发生。对于团队成员中代码不优雅的状况（好比四个for），现阶段对于大家团队的状况可能比较次要，先把要作的功能作出来，保证功能能正常使用，标记tag，后期来进行产品的优化，由于大家团队现阶段最首要的任务就是如何在这么短的时间把大家的产品比较完整的作出来。

时间周期安排

• Q： 离第一次的Alpha版本发布只有一个月左右，学长们是怎么解决在这么紧的时间完成大部分的功能的？
  A： 其实大家不要太过紧张，完备规范，明确分工，注释清晰（注释必定要写清楚！！），这样就能够了。

• Q： 是否有发生在某一环项目的实际进度赶不上计划的状况，应该如何调整？
  A： 熬夜啊。
  Q：？？？

其余

• Q: 学长的项目分工的时候，为何没有一个负责测试的同窗呢？
  A: 由于咱们那个选导系统功能复杂项目太大，任务作不完，后面测试都比较水。接口是有测的，Android端这边虽然测也是有测，可是单元测试作的就比较少，作了一个登录界面的单元测试、自动化测试。测试这一块，后面整合系统的时候也没有怎么测。并且中间有个队友去比赛了种种缘由，后面分工要磨合很困难。并且有些人不熟，人手也不足，因此就没有作很系统的测试。

• Q: 逸超学长是团队的PM，可是在Alpha阶段也参与了不少编码工做，为何？
  A: 其实贯穿整个过程，个人编码工做仍是挺多的。也是由于这个，致使后面整个组的分工也比较不明确。并且Alpha阶段和Beta阶段是不一样人在管，后面磨合也出现一点问题。因此我给大家的建议就是，组长就不要参与编码，专门管控整个项目就行了。你要的是别人完成得怎么样，而不是你也直接参与。

• Q: 那所说的分工不明确是什么样，好比说只分了谁去写服务端，谁去写客户端，而没有分具体谁到某一个模块这种程度？
  A: 对。由于两我的作不一样模块，后面协调起来，冲突会比较少一点。若是两我的作同一个模块，一来代码会冲突，二来两我的之间也要互相询问对方的代码。

• Q: 我看到有个学长的博客说到AS的git功能很好用，但后面他又说图形化的界面虽然能提升效率，但根本的仍是命令行，以为命令行更好。git只是一个工具，若是用图形界面开发效率更高的话，为何要执着于命令行？
  A: 那些图形界面，本质的话用到的仍是命令行。但对于大家现阶段的话，为了追求效率，为了完成做业，仍是推荐使用图形界面，就是AS自带的git功能。可是大家学到后面的话，其实仍是命令行比较好用。由于你选择命令行的形式的话，你确定对git了解更多更深，对于回退、合并、切换分支，你能知道他们具体的命令是什么样子的。而后图形界面的话，有个优势的话就是，你能够看到那条分支线，合并操做的话也很简单。因此二者各有优势，若是你会用命令行的话，你用图形界面也确定很好上手。最根本的仍是命令行。

• Q: 我看到当时学长们软工的commit注释有相似“整合上届代码，气煞我也，在里面发现了错误”、“队友须要，改了返回数据格式”、“写的快奔溃了，感谢产品不杀之恩Orz”，为何长这样的pull request也让过了呢？学长们如今在公司作项目是否有一套固定的git规范？对于commit的注释须要甚至详细到操做了哪一个类的什么函数吗？
  A: 学长A：你回答，学长B：你是PM你回答，学长A：当时咱们对于git基本没有制定必定的规范，因此才致使了这个问题。对于git，能够给大家说说我最近的使用经历。最开始确定是提交一个最初的master， 而后从master拉出一个dev的分支，按照dev分支这条线，开发人员根据实际拉出一条feature分支，对于feature的命名规范 “版本_开发人员名字_功能描述”，测试好了，再merge到dev分支。

任务分配比例

刘晨瑶	李永盛	苏伟鹏	张昭锡	骆景钊	胡俊钦	熊立强	陈龙江
20%	20%	5%	20%	10%	5%	5%	15%

反思&总结

在采访学长以前，把他们队伍的博客从第一篇起一直看到了最后一篇。看到每日站立式会议照片里的学长们从薄薄的短袖T恤一直到后来厚厚的羽绒服（其中一个学长正搓着手取暖），忽然间即便还没开始这段旅程就已经感慨万分。固然，其中也看到了学长们博客中体现出来的一些问题，都带有疑虑的在采访中问了这些不算太正儿八经的不解之处。好比为何任务分配中没有测试人员、为何commit注释千奇百怪、为何Alpha阶段结束后54张issue卡片还剩下多达12张...虽然问题自己看起来有点不是太友好qwq，但正是经过这些得知了一些很是真实的感觉和真实的状况，包括后来还问了很多技术上的问题，太多很细致的问题就没有一一在上文列出，总之受益不浅。

以及一些本身的反思。问了本身不少次，为何全部任务不管多早开始，都会在deadline的最后一秒甚至后一秒后两秒后三秒完成？这个千古难题其实以前在线下就问了学长，学长的回答是安啦，都是常态。可是多次如此，仍是以为有点难受。

---

据说逸超学长去了美团，然而接受采访的时候身上穿的仍是美图的文化衫 （逃