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