标签：style 使用 sp strong on 数据 问题 bs 代码
M1阶段的开发结束了，在周四的课上我们组也进行了alpha阶段的汇报。我们的努力得到了应有的回报，下面我们将针对M1阶段产生的一些问题进行分析和反思。
一.设想和目标
1.我们的app更像是一款针对北航学子的“知乎”应用。这款app可以实现基本功能：用户管理、搜索、分类、上传下载、用户贡献与交互等。
2.在alpha阶段，我们利用第一周的时间对学长的代码进行解读和分析，制定出相应的计划。我们认为制定计划的时间是非常充裕的，但是由于我们的经验不足，在测试原有网站的功能时出现了一些问题，导致后期修改原代码中的bug占据了过多的时间。
3.由于团队中只有一个人是真正做过安卓应用开发的，在制定大体计划时并没有产生多少分歧。可能在开发过程中遇到其他问题时，团队的核心技术人员会根据情况不同给出不同的解决方案。我们一直处于多沟通，多交流的开发模式，我认为这也是整个团队能够在alpha阶段取得阶段性成功的重要因素之一。
首先，由于我们的搜索功能在今天才正式完成，还没有将应用放在其他平台上推广，因此用户量比较少。但是我们对alpha阶段的成果进行使用测试的时候，基本的功能已经能够使用了。这也说明我们一个月的项目开发是成功的，尽管经历了一些波折。
因为最后作报告的时候才发现其他做有关“学霸网站”的小组拿到和我们一样的代码，bug也是很多。如果历史重来一遍，我们可能一开始就会召集四个组的成员集中精力先修改bug。我们组的队员能力很强，但也花了将近10天的时间去修复。如果一开始就让四组同学一起商量分析修改bug，可能我们还会做的更好。
二.计划
1.我们原有的计划就是初步实现学霸网站的基本功能，事实上，在组员将近一个月的熬夜后我们也确实完成了。
2.一个月的开发时间，每一个人都在尽自己最大的努力去做好每一件事。我们只在过程中发现我们自己的一些不足，但是还没有发现哪件事做了无用功。
3.在并不熟悉项目的时候，每个人都是摸索着尽量不去纠结细节，只求做出大概的一个成果，在beta阶段再继续修复。
4.项目的计划是第一周解读代码，第二周和第三周进行软件开发，第四周进行测试，当然这是非常理想的一个状态。但是在开发的过程中我们遇到两个比较大的挑战，打乱了我们的计划。第一次挑战是在测试原代码的时候，发现的bug让我们的项目在10天内几乎没有进展。第二次挑战是在第三周周末的时候发现了一个连接数据库的重大问题，为了解决这个问题我们又花费了将近一周的时间去调整。究其原因，还是我们开发项目的经验不足，没有想到各方面的问题。但是这也成为我们今后项目开发的一个经验教训。
5.本来计划有三天左右的缓冲时间，但是在接连遭遇两个挑战后，我们的缓冲区没有了。庆幸的是，组员的技术很强，这才能让我们的软件如期发布。
6.在将近一个月的时间内，组员在项目上花费的时间是平均每天5-6个小时。核心技术人员平均每天将近十几个小时，远远超出了我们计划的工作时间。因为我们的软件已经能实现基本功能，因此下一阶段的主要任务就是修复bug。
三.资源
1.组员的能力强是我们项目最终得以成功的最重要的保证。最初我们可能还是低估了这个项目的难度，后期遇到的问题也着实给了我们很大的打击。
2.各项任务的最初分配是由核心技术人员讨论得到的。在开发过程中，PM根据每人每天的工作量酌情分配。
3.我们在开发的过程中就做了简单的测试，由于存在的bug确实比较多，我们打算在Beta阶段做更加细致的测试。
4.我们在项目开始前就经过会议讨论了每个人的强项，技术不行的就去认真写文档，技术能力强的就带领大家一起攻克一个个难题。
四.变更管理
1.我们在项目初期就建立了一个QQ群，方便大家随时交流。因为项目中有两位女生，没法和男生随时碰面交流，因此QQ群的交流显得极为重要。
2.因为软件的基本功能确定，我们在决定一个功能是推迟实现还是必须实现时是围绕基本功能确定的。和基本功能相关的，影响alpha阶段成果的功能是必须实现的。
3.我们在认定软件的出口条件时以是否能够实现基本功能为准则，如果能够实现，那么可以发布。
4.对于之前遇到的一些问题和挑战，我们都及时召开会议商讨解决方案。因为在项目中，我们在前端设置了两名人员，后端有两名人员，还有一位机动人员，相对能力更强一些，可以随时处理一些应急事件。
5.从团队创立到现在，我们没有一个人因为懈怠而放弃自己的工作，每个人几乎拿出了200%的热情去对待项目。意料之外的工作请求大概每天都会出现，主要原因还是原有代码中问题过于多，以至于在进行开发的过程中，不得不花费超出一倍的时间去修复，而不是去创造。
五.设计/实现
1.设计工作在项目开始的第一周结束的时候由团队中熟悉安卓应用开发的人员完成了。因为第一周开会的时候计划先看一周代码，在这一周的时间内大家互相帮助尽可能多的读懂代码，然后再进行开发。我们的项目可能在设计上不用太费工夫，需要我们考虑的是每个人的分工。
2.设计阶段并没有产生模棱两可的情况。
3.因为开发时间非常长，导致没有进行深入测试，将在下一阶段进行。
4.在测试阶段，发现用户管理和搜索两个部分的bug非常多。主要是因为原有代码中这两部分几乎是空壳功能，团队的两个人分别负责这两个部分。在不到两个礼拜的时间内处理完这么多的bug非常难。
5.前端后端分别有两名开发人员，并且一名机动开发人员可以随时互相审阅代码，查出漏洞。
六.测试/发布
1.初期我们确实制定了一个测试计划，预计是在第四周进行。但是开发在第四周才结束，并且开发过程中做了一些小的测试，所以最后计划没有实现。
2.暂时还没有进行正式的验收测试。
3.发布的过程中由于发布平台的账号要审核，测试平台的账号也要审核。因此我们只在百度网盘上发布了我们的alpha版本的应用。
经历了萌芽和磨合阶段，我认为我们的团队正在逐步迈向规范阶段。M1阶段结束的时候，我们看到了我们付出的回报，完成了既定的计划。
对比敏捷开发的原则，我认为我们团队做的最好的就是“以有进取心的人为项目核心，充分支持信任他们”和“无论团队内外，面对面的交流始终是最有效的沟通方式”。我认为我们最后能够在有限时间内开发出一款功能如此多的应用不仅在于项目核心人员的技术能力强，更是因为我们充分的互相信任以及频繁的沟通。试想，如果我们在开发阶段没有相互理解，沟通，在bug产生的时候没有交流，而是一味的自己闷头苦想，可能软件的发布又会有所拖延。在接下来的一个阶段，我们将继续保持我们的热情和责任心，迎接其他的挑战！
M2阶段的计划：
1.继续完善功能，修改UI
2.和其他学霸组进行项目整合
3.修复bug
标签：style 使用 sp strong on 数据 问题 bs 代码
原文地址：http://www.cnblogs.com/hotsbuaa/p/4132395.html
