第二次团队作业——预则立&&他山之石

队名：Aruba

coding.net
 

分工

学号	姓名	分工
408	黄辉昌	代码测试、代码开发
409	李陈辉	界面设计、文档控制
410	林炳锋	代码开发
428	鄢继仁	代码开发
429	张秀锋	项目管理、文档控制
431	章    鼎	代码开发

 

团队任务计划

时间安排	学号	项目	阶段成果展示形式	备注
10.17~10.21	410 428	拟定需求大纲：根据《计算机软件需求规格说明规范》，确定功能模块	需求初审	要求做一次真实客户或用户的访谈交流
	408 431	对大纲进行初步审核
	409 429	撰写需求文档
10.22~10.28	409 429	编码规范完成+UI设计	编码框架+需求复审	要求真实用户进行一次确认
	410 428 408	平台环境搭建、初步架构搭建
	431	需求规格说明书最终版
10.26~10.30	409	UI设计改进	设计评审
	410 428 429 431	架构设计
	408	测试计划
10.30~11.05	429	冲刺阶段主持每日立会大家依次报告：昨天做了啥、今天要做啥、碰到了哪些问题；代码开发	发布alpha版本	尽早邀请真实用户参加版本发布后的测试
	409	立会要点记录；代码开发
	410 428 431	代码开发；git项目管理
	408	代码测试
11.06~11.11	409 429	采集用户试用反馈、用户体验改善计划	改进总结调整
	410 428 431	项目完善；除虫
	408	测试计划改进
11.12~11.18	429	第二阶段冲刺主持每日立会大家依次报告：昨天做了啥、今天要做啥、碰到了哪些问题；代码开发	beta版本发布	真实用户试用+反馈
	409	立会要点记录；git项目管理
	408	代码测试
	410 431	代码开发
	428	git项目管理
11.19~11.26	409 429	编写用户手册	发布用户手册
	408 410 428 431	确定正式版完善
11.27~12.02	410 428 431	继续完善正式版本		真实用户使用
	408	版本代码测试
	409 429	收集用户使用反馈，提出改进建议
12.02~12.19		根据反馈及建议，实施改进；部署上线		交付用户使用。申请软著

 

“他山之石”：

关于团队开发经验：

• 多看优秀开源项目；多看大牛博客；多学多看多敲代码
• 与其分散的每天编码一小时,更宁愿每周4,5,6集中编码(傍晚到半夜),随时讨论及修正
• 当发现某些事情重复或浪费时间的时候，考虑自己写脚本实现。
• 有效的会议讨论对于编码有着不小的帮助，有时候想不明白的事讨论一下就出来了。
• 分工需要更细致，很多技术壁垒要讨论，不能自己闭门造车
• github的使用对团队的协作效率上的提升很大，告别QQ流，越早熟练github越好
• 很多编码的规范应该提前做好，小组成员对于文件的命名也要规范，有利于程序开发
• 有些功能的实现需要建立在其他功能的前提上，先前的规划要考虑到这点。
• 分工的时候是分给了一个人去学习，他在没有做成之前别的组员都要等待，遇到这种情况应该做完手上任务的组员帮助分担。
• 在项目开始之前，就应该先确定alpha版本要实现哪些功能，哪些功能要留在beta版本实现。
• 跟队友解释清楚问题需要耐心去理解去阐述，等队友解释完，而不是轻易地否定。
• 把整体进度给队友看，让他们知道完成到哪一步了，还剩哪一些工作。让他们越清晰越好，这样大家会更有信心。
• 不要让PM一开始就参与编码，让他好好学学项目管理。参与编码很容易陷入细节而忘了大局。PM要以项目大局为重。
• 队友一开始学得比较慢。耐心点，不要抱怨，不要放弃，你会看到他成长得越来越快。
• 不要过分地去将编码作为全部，这是软工实践课，对软件工程知识的理解更为重要
• 遇到困难时:
  要灵活运用百度和查看各种大神的博客
  不要抱怨队友（虽然有时候会习惯性地说两句），解决问题才是关键。

 

关于团队成员协作：

队员的分工：
1.编写功能描述，完善文档，主持站立式会议,markdown文档编辑。
2.编写随笔及需求分析规格书模板，分析用户场景。
3.设计并描述界面原型，设计验收验证标准。
4.提出用户需求，设计类图及最终完善文档。

• 学好GitHub的团队合作流程，能为团队省掉不少时间
• 跟别人沟通的时候，如果意见不符，就去了解对方的基本假设，也就是对方的相关知识储备。

 

关于如何开始着手：

• 细化目标。仅仅有一个模糊的目标是不够的，要通过一步步分解，将其转化为一个个可行的小目标。

• 一定要做好需求分析！一定要做好需求分析！一定要做好需求分析！

• 当团队项目迷茫不知道怎么继续进行时：
  让队友尽可能指出当前项目还有哪些未完成的地方。然后带着这些去把整个项目的代码看一遍，可以重新把握住项目的进展

 
"前辈们"还“说”：

“这世界上，一个事好好做和随便做，效果差很多。基本动作的严格执行挺重要的”

“让Github和团队融为一体”

“最后对程序员的一个忠告：千万千万学好英语！！！！”

“夹缝中保持节奏是考验哦，请坚持，必会有收获。

“请PM 事先计划好，哪天工作，哪天休息。这是PM 的基本功。”

“工程的事，有时候就差别在是否能保持节奏，就像良好的代码质量一样，需要的是每天的编码都保持质量。”

“一般我们都不建议养成看视频学技术的习惯，速度太慢了，效率低。”

“如果底子差一点，要付出更多努力哦”

“组长一放弃某些坚持，组员就散了”

“自己单纯的看书会有很多细节的地方不知道，经过询问才会注意到，所以在学习的过程中，要大胆的去问。”

"其实对于过来人的话，我一直是不愿意听太多的，我总觉得有些路和感受还是要自己真切体验过才有用，别人告诉你那条路再艰险或做这件事再无用，都还是别人的话。那我就权当是对曾经那个大一的自己说吧。"

"一门课程教会不了我们太多技术上的东西，但是却让我们在各种重压下摸爬滚打起来。现在的我们去看开学初的自己的时候，一定也能真切感觉自己变得强壮了。"

"人是情绪的动物，三明治并不好做，不过有时只要想明白要解决的问题是什么。职业素养是指：在其位，谋其职，既然还在做，就得尽量适时屏蔽不理性的情绪，基于共同的目标，解决问题。如此，事后再吐槽会更有价值：D"

“团结一致，团队为共同的目标努力！: ) ”

分工比例：

项目	408	409	410	428	429	431
立会	0.166	0.166	0.166	0.166	0.17	0.166
“他山之石”	0.17	0.17	0.18	0.15	0.16	0.17
coding.net	0.166	0.17	0.166	0.166	0.166	0.166
项目计划讨论	0.166	0.166	0.166	0.166	0.17	0.166
材料整理	0.17	0.17	0.17	0.16	0.16	0.17
总记	16.7%	16.85%	17%	16.25%	16.5%	16.7%

对，其实应该可以看得出来，我们没有做采访，由于一些原因，什么原因就不说了，事实摆在那里，我们没有做采访。经过我们组员的讨论，我们对前辈们的博客进行了“采访”，有建议，有体会，有“好评”，或许对我们今后的前行有牵引，有价值。
没有完成预期的任务，组长难辞其咎，希望有所反思，引以为戒。感谢队友们辛苦地“采访”，谢了哥～

转载于:https://www.cnblogs.com/aruba/p/5967366.html