(Alpha)Let's-M1后分析报告

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