阿里八八Alapa事后诸葛亮

---

设想和目标

1、我们的软件要解决什么问题？是否定义的很清楚？是否对典型用户和典型场景有清晰的描述？

我们的项目希望解决用户对于时间、日程管理上不够方便、直观、易丢失的问题，因为并不是新颖高端的概念，因此在定义上足够清楚，对典型的用户与场景也做过清晰的描述。目前Alpha阶段用户量（测试）符合预期，但对重要功能的接受程度不足，这里主要的原因在于我们的开发进度未达到预期，由于经验以及合作方面仍有沟通不当的地方，最终我们未能在Alpha阶段完成应有的全部功能，已完成功能也有仍待改善之处。

2、有什么经验教训？如果历史重来一遍，会做什么改进？

最直观的教训就是成员间交流不够，一些功能与我们预先设定的样式存在偏离，没有真正理解团队要求做的是什么样的；第二点是成员对于遇到问题的解决不够积极交付组内进行共同探讨，导致每个人的问题解决进度都比较缓慢，解决非项目内的，比如IDE兼容性等问题处理了相当的时间，十分浪费。如果重来一次，我们希望在每次的Scrum中对于每个成员的进度以及计划进行询问审核，进一步确保每个人都明确自己要做什么，不走弯路，同时对于技术问题提出硬性的要求共同参加讨论，积极协助解决的成员会采取增加奖励分作为团队讨论的激励，并且解决非项目内BUG所用的时间将不计为贡献量。

---

计划

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

很遗憾原计划工作在最后并未全都做完，包括主界面的一些关键Bug仍未攻克，用户模块的功能之一尚未开发完全。主要原因还是小组成员对于Android Studio开发经验不足，解决问题比较困难，次要原因在于错误选择了开发IDE的版本，使用了不稳定的3.0版，许多问题在网络上难以找到可用方案，耽误大量时间。

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

有，首先是我负责我主界面部分UI设计，一开始只做了一个拖动悬浮按钮DragFloatingButton，但后来添加多级菜单时因功能冲突由删去，而前者耗费了我几天的时间，目前仅有未被调用的代码留在项目里。不过目前这个按钮仍有需求，在后续我会尝试将两者合并解决冲突。第二是林炜鸿同学设计添加事件的代码时，初版代码的可扩展性不强，后来需要进行修改事件的代码添加，反复尝试最后只能重构代码。第三是李嘉群同学做QQ调用的模块最初使用的调用功能包最后因功能不足暂时被取消搁置，所以目前QQ调用仍在开发中。

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

是，每项已确定的任务都有清楚定义和衡量的交付件，但目前并未全部交付。

4、是否整个过程都按照计划进行？

否，原本设定的Milestone在截止时间都多少有推迟，尽管每个人都很努力的在开发，但有些地方确实是很难在截止时间前做出来，还需要进一步学习。

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

没有，目前我们没考虑设置缓冲区，因为本身研究并开发项目的时间就已经排的满满当当，不太可以留出缓冲地带。

6、将来的计划会做什么修改？

计划增加更多集体开发的次数，提高开发效率。

---

资源

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

有，我们开发的过程中有许多有经验的人士可以咨询，比如微信群中的各位老师、助教和资深IT人士，互联网上也有一部分可用的资源，这里的一部分是因为许多早期的资源在3.0上已经会存在各种疑难杂症，解决这些问题的成本过于昂贵。

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

其实因为我们制定时间计划时对于我们实际上要做的东西难度如何并没有明晰的概念，只能通过日程来估计，实际上花费的时间超出了预计的1/3左右，大部分时间用在了学习知识上。

3、测试的时间、人力和软件/硬件是否足够？对于那些不需要编程的资源是否低估难度？

测试的时间足够，但软件上并不够，这里不得不吐槽一下Android Studio3.0甚至连原本很好用的单元测试功能都改的莫名其妙，我折腾了整整一晚上都不能使用软件自带的单元测试，如果重做一次项目我最想改的是改IDE。至于不需要编程的资源，我们的项目几乎没有，只需要花少量时间去找网络上现成开放的icon资源，基本够用。

---

变更管理

1、每个相关的员工都及时的了解变更的消息吗？

是，有需求变更时，PM会直接联系相关功能的人员进行交流，交流结束会将最后确定的方案再放到全组讨论群内交流。

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

为功能制定重要程度。显然对于一个日常软件，日常显示、添加是必须要有的基本功能，因此放在TASK2、3的Alpha阶段实现，而云同步需要用到数据库和服务器，服务器尽早搭建可以为之后的开发节省许多不必要的麻烦，因此用户模块与服务器搭建也放在第一顺位。而附加的“杀手功能”各类识别、数据分析等，放在Beta阶段实现。

3、项目的出口条件（Alpha）有什么明确的定义？

1、用户模块：可注册、可登陆、可修改信息，可与日程关联。
2、日程模块：可切换日期、可显示日期对应日程、可添加日程、可修改日程。

4、对于可能的变更是否能制定应急计划？

能，PM能及时制定应对变更的计划。

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

说实话这点做的不够好，存在两个问题，一是原本的需求未能正确理解，所以有时候需要进行调整，但调整后还是不对，经常需要反复详细沟通两三次才能正确完成。二是对于变更，能力上的短板直接体现，因为开发经验不足，一个小变更对于每个人来说或许就要用很大的精力完成。

---

设计/实现

1、设计工作有没有碰到模棱两可的情况？团队如何解决的？

有，主要是日程界面的显示虽然与需求分析上有所区别，但事实上也是可用的，功能方面没有很大偏差，并且在单日显示的部分由于我们实现时遇到的一个技术问题，无法进行按照时间轴的安排，只能以紧凑型视图显示，但反而恰恰是这个问题，让我们发现了一个更好的方案，也就是采用单事件单时间的卡片式显示，不仅可以使得事件的显示更加直观，在UI设计上也变得也更多选择，可以设计出更赏心悦目的界面，并且易于实现，这是意外之喜。

2、团队是否运用单元测试、测试驱动的开发、UML或其他工具来帮助设计实现？是否有效？

否，本尝试运用单元测试，但尝试许久未能成功，最后时间紧迫只好放弃了测试，希望在beta可以进行一次完整的测试。

3、什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的Bug？为什么我们在设计/开发时没想到这情况？

日程模块的多日显示，因为这方面可参考资料甚少，基本靠负责的同学用硬实力学习和实现，当然全组的同学也都有帮忙完成。所以选用的结构改了又改，仍是存在Bug。我们在设计/开发时也有想到这情况，但这是无法避免的，只能迎面而上去解决。

4、代码复审如何进行的，是否严格执行了代码规范？

由PM对Github的合并进行复审，存在问题将Close合并请求。代码上尽量执行了代码规范，这里的尽量是因为开始制定时对于IDE的不熟悉，有些规范的规则并不适用，比如布局文件的命名IDE内只允许全部小写，但内部的代码执行代码规范内容。

---

测试/发布

1、团队有没有测试计划？为什么没有？

未制定。这是由于PM的失误，在此道歉，因为我未提早考虑到项目还需要进行测试，就并未将测试纳入规划中。所以当发现时，可以进行测试的时间只有一天左右，于是急忙的开始测试准备。但由于我水平有限以及IDE测试模块在新版本有修改，网上可用的测试方案许多都不可用。我解决了很长时间最终失败告终。

2、有没有做过正式的验收测试？

有，在验收时我们向约20名用户左右推送了Alpha完成的版本，收集试用测试信息，在此之前我们组内的每个人也都按照了生成的APK到自己的手机进行兼容性、功能等测试，确保目前已完成的功能与需求相符合。最终全部收集后还进行了最后的修改才进行课堂展示。

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

否，尝试使用过，未成功。

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

因为工具测试失败，所以采取我们手工以使用的方式测试，数据库维护人员在后台监测后台的数据交换情况，从实际运行来看，测试确实有用，测试出了两个比较关键的功能错误，软件实际上只送数据到数据库，二次读取时读取的仍是本地数据，应该修改为读取数据库。

5、发布过程中发生了哪些意外问题？

无

---

总结

1、团队的每个角色如何确定的，是不是人尽其才？

PM采用所有人参考每个人的个人简介，进行投票选举选出。后端人员依据经验选择，前端人员因为大家都没经验，所以根据开发意愿来分配，每个人认领自己感兴趣的工作。从目前来看，大家确实都120%的发挥了自己的才干，做到了人尽其才。

2、团队成员间有互相帮助么？

有，在碰到个人难以解决的疑难杂症时，大家会在群里进行讨论，在集体编程时也尤为高效，碰到过相关困难并且解决的同学会积极帮助碰到同样困难的同学，氛围很不错。

3、当出现项目管理、合作方面的问题时，团队成员如何解决？

其实目前没有出现管理困难，每位同学对于PM分配的工作都十分配合。合作上出现过一些困难，主要是功能合并时二者选用的编写方式不够合适，需要进行修改等，但也没有碰到较大的问题，修改的过程除了功能本身就很难在短时间实现外，没有因为合作产生矛盾的问题。

个人总结

俞鋆：

在这十几天的alpha冲刺中我收获了许多，接触到了以前未知的领域，对写linux服务器也有了一定的了解；第一次作为一个团队里的成员编码，我又紧张又兴奋，害怕自己写得太慢，拖累别人而紧张，又为自己要做出来东西而兴奋，就在这样的状态下充实的度过了冲刺阶段。

刘晓：

α阶段的冲刺终于结束了(ಡωಡ)hiahiahia，然而β阶段将至。在α阶段的冲刺过程中，了解了一些安卓和Java的基本知识，感觉安卓还是很有趣的，也发现了自己的一些毛病，1.完成一个任务大部分时间花在查资料上面，看完资料实践的时候感觉不能套上去。以前没有这种冲刺经验的时候没有多大感觉，这样子边学边做之后发现短时间内自己完成任务解决问题的能力需要锻炼。2.目标是实现APP的功能，所以在开发过程中想着先实现再说，在知识点理解上面还有代码规范上面都有所欠缺，比如对于线程还是有点迷茫。α阶段的收获就是1.边做边学的效率比看完书再动手高很多。2.组里的小伙伴都很nice，在群里或者是团队编程的时候都很热心的解答问题。对于β阶段，感觉要看到凌晨四点的福大了——充实的β阶段
(ಡωಡ)hiahiahia

黄梅玲：

在软工实践之前对Android软件开发实际上是一片空白，完全不知道应该怎么做，可以说在之前，连Android开发使用的是Java语言都不知道。在α阶段过程中，慢慢地仿照《第一行代码》写程序，α阶段刚开始的时候，对Java的了解也非常少，只能边写边学习。在经过α阶段后，对Java有了比较深入的了解，但是过程中，团队的同学有发现了关于Java程序编写会遇到的一些问题，看来是代码写的不够多，还得再接再厉。另外我觉得做一个界面，最重要的是弄清楚需求，才能明确自己要写一个怎样的界面。在α阶段中，我觉得团队是非常重要的，也非常感谢团队的成员热心地解决提出的每个问题，过程中也积极地帮忙找资料。还需要跟同学们多多地学习。

李嘉群：

第一次是团队在一起做一个项目，和队友的交流总的来说不是很多，就是在开会的时候会讨论一下。完成自己的代码上传后，再把团队项目fork下来运行，还是会出现各种各样的问题，其中android软件的gradle出现问题的次数很多，会花费很长时间去找不能运行的原因。在进度方面做的也不是很好，也因为自己能力的原因，感觉自己解决问题的能力有点弱，有时一个问题会卡很久，进度有些偏慢。通过这次的合作，也学到了很多，最主要的就是android的只用以及界面，功能的应用，前端后端的对接。进行过几次集体编程，感觉效果还不错。多交流还是很重要的。希望自己多加学习，电脑玩的6一点，beta阶段吸取教训和总结，做的更好一些。

张岳：

α阶段的冲刺终于结束了哈哈长出一口气（虽然还有β阶段~），不短也不长的冲刺时间里，虽然安卓的基本知识都了解了一些，不过感觉还是依葫芦画瓢，很多东西为了赶进度，都是一种不管用什么方法都先实现效果再说的想法，就导致一些地方的代码真的有危楼的感觉，还有一个最大的问题就是发现自己解决问题的能力不强，在有限的时间内对任务的完成度不高，这也是我今后要注意的地方，如果解决问题能力增强的话必然学习东西也会很快了~ 最大的收益就是“做中学”真的是很受用的方法，实践的过程中很多之前遇到的问题和不懂的地方往往也就迎刃而解了，怪只怪自己以前太懒总是要等理论学的差不多才想要动手。还有一点就是团队的合作，团队的小伙伴都是很乐于助人的啦，组长也是一个好组长没错，大家不断讨论和交流还是很有助于增（fu）进（xiang）感（xian）情（qi）的哈哈。β要来了，希望我的β之旅愉快又充实。

林炜鸿：

1.第一次接触安卓，甚至是第一次接触java。早就听说java面向对象到了走火入魔的程度，看来的确如此。好在语法什么的基本和C++一致，所以上手还是很快的。而且java有一点好，可以随心所欲地new，甚至匿名类之类的黑科技也是支持的。这点C++就比不上。
2.刚开始玩Android Studio的时候，因为代理的问题迟迟搞不定（不能从google同步gradle）。后来研究了半天才发现，shadowsocks是sock5代理，因此只要设定一个端口转发就OK了。自此学会了如何监听和转发。
3.第一次团队编程，还不怎么会用github。虽然很早就接触了，但实际上一直把他当做个人的代码仓库来用。咨询了学长以后，学会了绑定upstream的方式来保持和源项目的同步。
4.开发的时候遇到了难以解决的问题，整个项目直接无法编译运行了。研究了很长时间，也找了很多资料，还骚扰了一下学长，最后终于发现原来是一个软件包被include了两次。搞定之后，发现已经深夜两点了。四个小时的奋斗，最后也只是注释了一行而已。
5.实际开发的时候，发现有些功能，尤其是UI部分，实现起来不如当初想的那么简单。经过小组决议以后，综合自身技术水平，决定简化一下UI，把时间腾出来给更重要的功能。在此过程中，内心还是有很多挣扎的，也借此又重新想了一下整个项目的构架，对项目乃至是安卓APP的开发都有了新的认识。

王国超：

这是我第一次接触android。这次使用的eda是as。首先，as确实比eclipse更加简单友好。上手不难。这个阶段我几乎是边学边敲代码。不断的尝试新的组件和方法。
这个阶段确实学到很多东西，不管是关于团队合作还是个人的经验。但是自我感觉学习的方法上还是有很大的缺点。就是没有系统的学习，也就是学习比较碎片化，想要做什么就开始学什么。这样没有制定学习路线，感觉效果不大好。

---

课堂展示建议收集

评价与建议

1、对我们小组的启发很大。界面方面。想要这样的加入功能比如与日程可以读取本地闹钟来一起提醒的这种。
2、感觉看似实用，结合日常生活感觉想不起来使用，希望能结合使用环境，例如在手机桌面背景上直接显示。
3、完成度可能相对低了一些，功能也相对简单，希望后续能加快进度。
4、重要功能-时间提醒未实现
5、挺好的，但是Github管理需要改进。
6、目前功能还是太单薄，作为日程管理没有很方便
7、界面友好，功能完整。对于日程安排类APP我觉得不需要登录会更好一点
8、评价：根据目前所见到的完成情况，似乎与平常见到的Todolist软件没有太大的区别，期待强势的吸引用户功能项出现 建议：设计一些与往常做计划表不一样的方式，以及做好及时通知（构思下如何去通知更让用户重视todolist），根据我们了解到的有一部分用户没有做Todolist的习惯，但是却又想培养自己这么一种习惯，却经常因为遗忘自己在xx备忘录软件上有做过计划表，而选择放弃使用这样的app（因为，做了计划表，但是，经常时间都过了才想起上面有计划表，这样的计划表就没什么意义了）。