TD学生助手——alpha版发布

1.设想和目标

---

 1.我们的软件要解决的问题

　　TD学生助手的主要核心思想就是帮助学生安排他们忙碌的学校生活。主要是通过以下几个方面

　　1.通过学生的需要进行分类（考试，实验，发博客等等），添加日程，保存日程到数据库中，将日程模块化管理；

　　2.用月视图和周视图，日视图三个视图来管理添加进去的日程，让日程管理起来更加直观，方便，增强用户体验。

2.是否有充足的时间来做计划

　　我们做计划主要是在Sprint计划刚开始的时候进行计划，并在以后实施计划时进行调整，但是由于我们的敏捷开发的经验不足，不知道如何控制任务的进程，给每个人分配的功能在规定的时间内也无法按时完成，所以到开发的后期制定的计划对我们的开发反而没有什么用了。

3.团队在计划阶段是如何解决同事们对于计划的不同意见的

　　我们组在讨论TD学生助手主要功能设计时，经常出现分歧，因为每个人对用户体验的想法都不同，我们就让持不同意见的写个详细的调查报告，分析这个功能的可行与否，用户体验是否会良好。

1.1用户量

---

1.用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

　　我们的重要功能就是能让用户直观，简洁的看到自己一天，一周，一月要完成的事情，并对添加的日程模块化管理，关于这个主功能我们做的还算完善，基本功能都有，但是在用户体验上离真正的目标还尚有一定的距离，我们会在beta版的发布时进行大的改进。相信用户量会是我们预想的那样的。

假如历史重来。。决定换一个软件做。。这个太繁杂，不会写，一个功能一个坑。

2.关于计划

---

1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?　　

　　在整个敏捷开发阶段我们总共做了两次sprint计划，每次Sprint计划我们都有没有完成的功能，并且还有决定要放弃的功能，这些功能在以后的日子发现也没有太大的用处。但是很多东西与其不断地争论有些事情有没有必要，还不如做了再说。

 2. 有没有发现你做了一些事后看来没必要或没多大价值的事?

　　有。现在算起来两个计划中用不着的功能有一些，比如GPS导航功能，去除它有两点原因。1.这个软件主要是管理学生生活的，跟GPS没有直接和太大的联系；2.做起来太复杂，最后为了保证Sprint计划正常进行，我们去除了这个功能。

3. 是否每一项任务都有清楚定义和衡量的交付件?

　　有。我们在每一次Sprint初始阶段的会议中会根据每个人的编程水平分配一些功能给团队中的成员，并把他们绑定在一起结对编程，而且功能和功能间有交叉的就进行互相联系，避免只敢自己的事情，不管团队整体进度。每一项功能我们也制定了最终要达到的效果以及可以衡量的标准和演示状态。

4. 是否项目的整个过程都按照计划进行?

　　整个项目基本上都是按照计划进行的，主要也是团队成员比较给力，但是有些时候由于PM制定计划的失误，导致整个项目在一段时间内偏移他真正要到达的目的，但最后我们还是回归在轨道上。

5. 在计划中有没有留下缓冲区，缓冲区有作用么?

　　有。我们的加班主要是集中在冲刺快要结束的后两天，为了保证Sprint计划顺利完成，团队到最后都会加班加点，保证主要的功能按期完成。

6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

　　我们已经完成了Sprint2计划的内容，最后一次冲刺也就是Sprint3计划，我们要做很多事情，在制定计划的时候要充分考虑用户的体验和软件的实用性。

3.关于资源

---

1. 我们有足够的资源来完成各项任务么?

资源总体来说还是挺充足的，网上有各种模板和代码，还有各种教学视频。

2. 各项任务所需的时间和其他资源是如何估计的，精度如何?

任务所需时间一开始时是尽量给予充足的时间，以免发生突发状况；任务精度一开始时只是确定大方向，随着项目的进行和任务的加重，各种小功能被细分出来，再根据情况分派任务。

3.用户测试的时间，人力和软件/硬件资源是否足够?

此类资源都不欠缺，足够了

4. 你有没有感到你做的事情可以让别人来做（更有效率）?

没有，因为自己的工作自己最熟悉，也是专门学习的有关此方面的程序设计及代码编写，每个人都有自己的专攻，如果交给别人，可能会导致工作进度延迟或完不成，甚至乎影响整个项目的开发进度。

4.变更管理

---

1. 每个相关的员工都及时知道了变更的消息?

因为我们的团队每天都会有站立会议，而且还专门建立了一个项目开发讨论群以便大家进行讨论，所以各种消息都会及时知道。

2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?

我们会根据项目的核心功能及各项功能实现的难度及复杂度来决定哪项功能必须实现那项功能推迟。

3. 项目的出口条件（Exit Criteria）是否得到清晰的定义?

大家都不太懂“出口条件”是什么，经过这一个项目之后，稍稍清楚了一些。但是说实在的，在这个项目里面我们没有用到太多。

4. 对于功能的变更是否能制定应急计划?

能，第一次冲刺结束后，组长感觉各项功能及界面太过粗糙，所以重新编写，各个组员积极配合两天完成。

5. 员工是否能够有效地处理意料之外的工作请求？

可能会临时给某个组员增加一些任务，组员也会积极配合，尽快完成。

5.设计/实现

---

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

此类工作有本团队中专职人员（静姐，叶姐，娇哥）完成，由于是三人专职负责次部分设计所以设计上，时间上不会出现太大偏差，基本都能按时完成。

2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

很多，大家都不知道如何解决。就看具体执行的人是如何解决的，有的解决得好，大家并不知道出过问题；有的经常拿出来讨论，但可能会出现分期或多种结论，那就投票吧。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

没有使用这些工具，不会用，也没必要

4. 什么功能产生的Bug最多，为什么？

日历时间处理，导入数据库，读取数据

5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

这个方面要求不是太严格，可能大家都感觉太繁琐，所以要求不是太苛刻，但大家在写时会注意书写。

6.测试/发布

---

1. 团队是否有一个测试计划？为什么没有？

测试计划是有的，这个方面大家还是做的比较好的，所以阶段测试及后期测试时比较翻遍明白，就是有点繁琐。

2. 是否进行了正式的验收测试？

正式验收时有些bug还未解决，所以说验收是不成功的

3. 团队是否有测试工具来帮助测试？

有。效果还是很明显的。

4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

TFS 还是很有用的，至于改进，有这样一些建议：

（a）通过不断的想像用户体验

（b）作用还是很好地工作方便，快捷

（c）吧错误提示改成汉语好不好

5. 在发布的过程中发现了哪些意外问题？

有些功能不还不太理想，没有达到预期目标，而在实际运行时还存在一些bug。

这一阶段我们的主要任务

---

ID	名称（NAME）	重要性（IMP）	初始估算（EST）	注       解 （NOTE）	认领人 （OPERATER）
1	日程单事件、多事件处理	9	2	①能增加课程 ②与课程相关信息 ③根据实验项目、作业等增加事 ④能导入数据库 ⑤实现增删改查	刘铸辉 胡宝月
2	显示日程在日历中	8	3天	①直观显示每周每天都干什么 ②能在日历表中添加、删除、查询及修改事件	刘 静 刘铸辉
3	显示日程在时间表中	8	3	①直观显示某一时间的事件 ②能在时间表中增删改查事件	何晓楠
4	日期转换	8	4天	①能实现日期阴阳历的转换	胡宝月 刘铸辉
5	界面调整及美化	9	每天	界面美观大方，提高用户体验效果	刘铸辉 胡宝月
6	产品测试	10	2天	①界面测试 ②需求测试 ③功能测试 ④书写测试文档	解凤娇
7	文档书写	10	2天	①项目设计文档 ②产品说明书	王洪叶 胡宝月 （解凤娇）
8	会议记录	6	每天	①记录没人三句话 ②确定站立会议的时间及地点	何晓楠
9	博客编辑和发布	7	每天	将会议记录和项目进度进行编辑 汇总	刘铸辉 何晓楠

我们这一阶段的核心就是让数据表中的数据表现不同的方式，让用户在时间表和日历表中同时管理自己的日程，而且我们还对日程进行了模块化的管理，这样使用起来就更加的便捷，用户体验也就更强。

1.显示并绘制完整的日历

我们的日历包含农历，各个节日，阳历，星期等信息，实现方法主要是给每一个Gridview添加item值。

2.给日历中每一个日期添加响应事件

可以添加日程，并将日程模块化管理，根据学生的需要进行分类（考试，实验，发博客等等），并且保存日程到数据库中

3.已添加的日程在日历表和时间表中同时显示

在某一天添加的日程，日历表上会有标记，时间表上会显示所有已经添加过得日程，并按时间先后顺序排列

这里面显示所有日程主要用了ListView  这篇文章ListView讲的很详细，给了我们很大的帮助http://blog.csdn.net/p106786860/article/details/10596339#comments

4.日期转换

能实现日期的农历和阴历的转换

关于具体是如何实现的会在之后的详细设计中详细介绍