Chronos团队Let's项目
Postmortem结果
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
在最初的用户需求和市场调研方面，团队进行了详尽的调查，也策划了Alpha阶段需要实现的功能，因此在软件需要解决什么问题这点上我们的目标非常明确：开发一款能够融入线下生活，以活动交友的APP。Alpha阶段的目标即完成软件基础功能，包括注册登录，用户与活动之间的联系。关于典型用户和场景，已在之前的博客中做了清晰描述。
2. 是否有充足的时间来做计划?
有时间，但多数时间都用于盲目地一把抓式开发，缺少详细策划。
3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
每个人的不同意见都会得到尊重，若出现分歧，则会让各自在每天的scrum meeting时阐明自己的理由，最后由组员共同商讨决定团队最终采用哪种意见。
计划
1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
所有功能性工作都已完成，剩余部分bug以及细节显示尚未优化，如：图片无法加载的问题，还未实现上拉加载，百度地图API在部分手机上无法加载等。其原因部分是因为时间分配不够合理，导致部分时间耗费于可有可无的细节上，而忽视了关乎用户体验的细节。另一方面，和我们先前未运用好代码托管机制，以及Android Studio极低的编译效率都有很大关系(每次pull代码经常因为配置文件修改出现模块丢失的情况；编译运行一次基本都要3-4分钟)。
2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
有，例如首页界面的搜索框缩放效果。最初看重这个框架的缩放效果，一心想着将其应用于软件中，却耽误了其它实质性功能的开发。
3. 是否每一项任务都有清楚定义和衡量的交付件?
对于代码编写的任务，一般在下达任务之前PM会规定好任务细节，并要求完成基本功能，通过单元测试（如搜索模块）。但对于UI方面，Alpha阶段PM的安排过于笼统，使得任务定义模糊，无形中浪费了很多时间。这点在Beta阶段将进行改进，UI任务将由大至小，从统一改善整体风格，到各个组件的设计，将要求提交设计稿等一系列材料。
4. 是否项目的整个过程都按照计划进行?
经常实际完成时间都要比预定完成时间晚一天。通过反思总结，原因有以下几点：所有组员先前都没有安卓开发经验，初次开发难免绕许多弯子；开发过程中效率不够高，经常以“天”为时间单位进行规划，却没有精确到“小时”甚至“分钟”，导致屡犯拖延症；时间分配不合理，导致捡了芝麻丢了西瓜；部分成员的投入时间难以保证，开发人力有限。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
有缓冲区，在计划中只给Alpha阶段开发留了三周时间，并且在每周的任务中也会预留一至两天。这样是为了一定程度上杜绝拖延现象，另一方面可以有更多的时间对开发工作进行审核修改。
6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
PM将会明确任务的定义，并且合理分配各个任务的时间和人力，避免不必要的浪费，并督促各位组员的任务完成时间，考虑加入惩罚措施；将采用敏捷开发模式，针对每一个阶段的任务逐个攻破，避免Alpha眉毛胡子一把抓的方式；改变评估方式，站在用户的角度考虑开发方向，而不单纯依靠开发者自己的喜好。
资源
1. 我们有足够的资源来完成各项任务么?
机器的限制还是蛮大的。尤其Google强推Android Studio后，大部分成员的电脑跑这个吞内存的家伙都非常吃力，且编译时间浪费挺多。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
Alpha阶段对时间的估计较为粗略，对难度的预估偏差较大，经常以天来分配Task，导致经常出现一个任务拖延多天的情况。在Alpha阶段经历了整个流程，了解了安卓开发后，Beta阶段将会更合理精确地分配任务。
3. 用户测试的时间，人力和软件/硬件资源是否足够?
由于Alpha阶段最后修复bug导致发布时间拖延，以及最初对Alpha阶段的功能设计存在缺陷，导致整个软件功能漏洞较大，无法在较大人群中推广，测试时间较短。但通过组员的推广，已经在100+安卓机子上进行了安装体验，并受到了许多反馈，我们将利用这些反馈进行Beta版本的优化。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
这点较不好界定，尤其体现在前后端的工作上。前端的工作究竟是设计和xml界面编写，还是包括代码实现的动效，交互事件？（如下拉刷新时加载动效，箭头的转动等）
变更管理
1. 每个相关的员工都及时知道了变更的消息?
因为任务拖延，不经常Pull最新代码，部分组员的工程文件经常远远落后于最新的版本。但所有push的更新都会在工作组中提及。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
从用户的角度出发，决定哪些功能是必备的，哪些是附加功能，哪些是可有可无的，排出优先级。
3. 项目的出口条件（Exit Criteria）是否得到清晰的定义?
Alpha的出口条件简单粗暴，即没有导致crash的大bug，预期功能健全完善。
4. 对于可能的变更是否能制定应急计划?
从Eclipse到Android Studio的一次转变应该是比较突然的，实在受限于Eclipse的拓展性，我们决定利用缓冲区的一两天时间将整体工程转移到AS上，并熟悉新的IDE。从结果来看，计划的制定和缓冲区时间的利用还是比较成功的。
5. 员工是否能够有效地处理意料之外的工作请求？
这些任务通常分配给较为积极的组员，从完成情况来看这些组员能够有效地完成这些意外请求。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
Alpha阶段对UI设计的任务时间都划分不当，使得UI的设计较被动，通常由后台提出请求再转至UI，其中PM作为交接人。在Beta阶段将为UI设计做详细的阶段策划。另一方面，软件框架的设计由PM完成。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
较少，多数情况下PM一人对这些情况进行决定，但也导致了一些设计缺陷。下一阶段将让更多组员参与讨论。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
单元测试要求在提交代码前要完成，没有借助其它工具，因为多数模块与安卓机的交互有关，直接在机子上运行测试。
4. 什么功能产生的Bug最多，为什么？
页面加载，布局错位的bug最多。最大的原因还是安卓机型的繁杂，以及开发者对界面代码编写的经验缺乏。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
团队开发中没有专门进行代码复审，代码复审基本上都在各自调他人bug的过程中完成了。。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
我们制定了测试项，从界面显示，交互功能到后台情况都有涉及，并且针对多种机型测试，编写了测试矩阵。
2. 是否进行了正式的验收测试？
发布v1.1前进行了最后一轮测试。
3. 团队是否有测试工具来帮助测试？
无。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
利用TFS，但在Alpha阶段我们未利用好TFS的bug记录，且并不是所有的Task都记录在TFS中，其中TFS任务分配无法同时分配多人这点比较麻烦。
5. 在发布的过程中发现了哪些意外问题？
最终的release版本APK在部分机子上无法安装运行，但这些机子的系统已经高于软件要求的最低版本。以及部分机型上显示的错位，空余等。这些问题都已经记录，将在Beta阶段进一步解决。
其他成员的心得体会
>> 康家华
“有没有一些声音，呼唤你给自己一点喘息。”
连续几天的熬夜已经严重扰乱了我的生物钟，这种混乱的作息也终于跟着M1答辩的结束一起消弭殆尽。M1结束之后，也抽出一些时间对M1进行一些总结和分析。
在整个工程中我负责的主要是UI设计部分，对于从来没有开发过安卓应用的我，需要从零开始学习XML语言，并且能够达到脱离所见即所得的UI设计模块直接在代码层面上直接进行设计的水平。
在开发前期，我一直使用安卓自带的传统控件进行设计，做出来的界面基本上是拿不上台面的，于是我们在一次会议中讨论到了Material Design的设计风格，大家一致决定要按照这样的设计更改，所以我们对之前的成品进行了“大翻新”。
在向Material Design的设计发展的过程中，我们遇到不少的并且有的还严重影响到整个工程进展的问题。
首先，是框架不兼容的问题。我们从开源的代码中找到的合适的界面框架想要移植我们的程序中，但是由于后端的代码已经基本完成，我们不得不对框架和后端代码的接口进行修改。在这个过程中，本来应该属于测试的时间也都被大量的占用在耦合调试的过程中了。
其次，由于时间紧急，来不及设计和Material Design搭配的相关控件，我们只能用不太搭调的来应急，以至于我们在展示时的界面还是多种风格鱼龙混杂的场面，根本就不是Material Design，这也是我个人对前端设计的不满意之处。
在接下来的M2中，需要改进的有很多，包括在风格设计上面的统一，在开源代码的使用方面等等，还需要对实际的用户体验进行分析，尽可能的让用户更舒服、更享受地使用我们的软件。另外，团队之间最需要的就是“沟通”，沟通做得好，队员之间的距离也就缩小了，我们的开发就会更有效率。
>> 刘彦熙
软件工程阿尔法阶段的工作告一段落了，在这一阶段的工作中，我感觉个人收获很多，也有一些体会想要谈谈。
首先，自己之前没有过团队开发的项目经历，通过这次的开发，了解到了团队合作进行项目开发的常规模式，并且对于团队合作有了全新的的认识。一方面是一些版本管理工具的使用，另一方面是学到了很多如何与队友沟通协作的知识。
另外就是学会了一些基本的安卓开发知识，因为之前一直想要学习一些有关APP开发的知识，但是感觉专门去学比较费劲而且效率不高，结合项目进行学习更有针对性一些。并且在开发过程中能够看到自己自己所做的东西变成实际能够看到的东西，所以比较有成就感，也就能更加促进开发的热情。
以上是一些这次开发过程中的收获，接下来谈谈体会。
越是庞大的任务就越需要妥善的规划，所谓规划包括以下几点：
首先，需要制定一些列阶段性的任务：因为开发的过程非常漫长，任务非常的繁重，面对着如此庞大的工程，难免会很打怵。所以要将任务分成若干个阶段。
在每个阶段我们需要对项目的整体面貌有一个统一的认识：诸如一些类似界面的布局图以及接口的书面材料，虽然在定义的过程会耗费一些时间，但是能够大大提高开发的效率。并且能够在以后的开发中提供依据与参考。
另外体会在于：当你真心想做好一件事的时候，你就会积极主动地去完成任务，并且在意你所做的工作的质量。既然是团队开发，团队中的每个人就都有责任和义务为团队做出贡献。
希望我们团队能够在下一阶段的开发中排除编译带来的困难，越做越好吧。
>> 马瑶华
持续几周的紧张M1阶段结束了，下面来总结一下我的收获以及感想。
首先，这门课以及这种团队合作形式让我对于软件工程有了全新的认识。以前我们编程顶多是自己做个小作业，或者是几个人弄个小程序，而像这样大规模的持续的团队合作以前并没有经历过。两个月的时间，和小伙伴们一起做个应用，同时还要兼顾学业，不是个很容易的事，至少没有看上去那么简单。
在M1阶段，我们主要是在进行将一个软件从无到有的生产过程，也就是类似于原型的软件。可想而知，这个东西不会那么完善。在界面方面，一开始的工作做的不细致，当然也是因为第一次接触到原因：我们能做到什么样子，能做多少，心里都没有底。一开始的xml布局结构完全是边看边学边写。恨不得就是一半屏幕放着IE网页教程，一半屏幕是eclipse。在最初的原型有了以后，肯定最先想到就是这个效果不好，想要自己重新设计界面。然而自己设计也并没有想象中的容易，如何形成统一的风格而非拼凑？如何选用规范的标准？伴随而来的都是问题。而客观上时间不够，主观上付出不够，我们的UI还是没有达到目标效果。虽然这是必然的，但在接下来的开发中却又必然是会改进的。
M1阶段给我的还有一个感受就是，我们的应用是要上架在真实市场的，而非学校里自己小打小闹的产物。一切都要向市场上的成熟应用看齐。如何有竞争力，如何从一个安卓菜鸟一下就向最酷炫最前沿的理念看齐，真的是个不小的挑战。以业内的标准，而非一个学生的课堂作业的标准来衡量作业，这是第一次。
在M1阶段中，大家需要在一个团队中共同做事，颇像一个开发小组。如何互相沟通、磨合，如何互相衔接，都是需要自己在实践中去学习的。好在组员们非常给力，给了我很大帮助，PM以及其他人非常负责，非常感谢他们，他们身上有许多我需要学习的品质。
在接下来的阶段中，我认为我需要更加主动的和其他组员的沟通并且时刻跟进我们的项目，在UI方面形成一个整体的设计并且花更多的时间在我们的项目上。学业很忙，但如何统筹安排，别老把事情拖来拖去，这绝对是我最需要思考以及改进的地方。
>> 张启东
经过这两个多月以来的软件工程的学习，还有团队项目的经历，总结反思如下：
首先，一个月的软件工程团队项目的进行让我对软件开发有了比较实际的认识，以前我们的编程多是个人编程，两人编程，程序难度低，代码量少，也很容易配合。这次团队作业，我们6个人一块做一款app。我们组实力还算可以，虽然没有能够独自承担起全部任务的大神，但大家在编程方面基础都还不错，还有两人有过些项目经验。同时我们每个人都是认真对待这次作业的，不只是为了期末的分数，更是珍惜这个能够一块参与编程的机会，同时还有这我们对这款活动平台app的共同希冀。
在团队编程中，任务量是很繁重的，如果只是一个人来承担，自然是十分困难的，这就需要凝结团队中的每个人的力量。团队中的每个人应该按时完成pm分配的任务。同时多沟通，彼此知道别人在做什么，这在一个不超过10人的小组，并不是困难的。而且多沟通能够节省很多自己研究代码的时间，符合敏捷开发的思想。
由于是团队开发，每个人都需要修改版本的代码，所以一定要学会用好仓库管理，这样可以让多个人共同开发，同时容易知道代码变动，避免了繁重的不同的代码的合并。
当然，团队编程有时候也会存在一些问题。比如说我们往往把任务细化到每个人的身上。但通常会有各种各样的原因导致不同的任务进度不同，这就会造成有的进度会出现延期现象，给整个项目的进度造成影响，这就需要在分配任务时做到合理化，使得彼此之间可以有效的衔接上，这样团队项目的实现就会变得迅捷许多。最好团队编程中也存在结对编程，这样可以保证如果一个人有事情，另一个人可以补上这个缺口，我们组就是这样做的，我和另外两个人都结对编程过。
同时还在必要的时候承分担某一慢进度的开发工作。除了PM的协调，当然还需要各个模块负责人之间的沟通和交流，做好模块间的通讯工作，方便一方出现变化时另一方能够迅速做出调整。
我们组的pm统筹能力比较强，他能够合理给每个人分配任务，力求做到进度之间彼此衔接。
关于个人的建议，其实我不太建议选学长代码的完善，我更倾向于选一个新的问题从头做起，这样我能够从头到尾经历一次比较完整的开发过程，才能真正体会到团队项目的特点和交流，整合以及优化测试的重要性，这样也让我认识到了大工程不仅仅要重视算法，更要重视架构上和变化上对软件目标实现的综合整合。
付出越多，收获越多，这门课程很难得，需要珍惜。
>> 仇栋民
连续几天的熬夜的工作，已经完全打乱了我的生物钟，最后一点精力已经被消磨殆尽。现在就这两个月来的软件工程的团队项目的M1阶段做总结与反思。
在M1阶段中，我主要负责的是后台功能的开发与测试。对于从来没有学过android开发相关知识的我，这其实是挺有挑战的。
遇到的第一个困难是对android机制的理解与应用。安卓的Activity、Intent、Handler、Bundle等类都比较特殊，我都是在用到之前在网上简单学习一下，就开始写，这导致了我的初次代码质量很低。学习的太粗略，太粗浅了，下一阶段学习新技术的时候应该注意理解透彻技术的机制再使用，避免后期调试为开始的粗心埋单。
第二个大困难是JAVA多线程机制的使用，在这里就不赘述了。
另外由于是第一次开发安卓应用，在开发过程中，我们写到一定程度后，结构框架不是非常合适，意图对我们的工程进行一次重构，然而紧张的时间进度不允许我们进行重构。所以只能先改了一些方法内部的代码结构进行了调整。
这种情况在真实的软件开发过程中应该是很常见的，我们团队既然遇到了这样的问题，一定程度上说明了我们体验到了一种真实的软件开发过程，这是非常宝贵的经历。
同时，时间节点的限制，也使得我们整个过程都在“试用”敏捷开发的方法，说“试用”是因为我们有的地方还用的不到位，但是总体原则和大方向没有偏。
最后，我在M1阶段中遇到的困难与问题，会在M2阶段中努力克服与解决。
OUR TEAM
