Alpha冲刺之事后诸葛亮

标签：.com   没有   代码规范   平台   每日   分享图片   开发者   查找   轻量级   

1. 设想和目标

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

??我们的软件要解决的是需要进行财务管理的用户的痛苦, 给他们一款轻量级、易用性高的记账小程序，能够实现日常记账以及账单分析；是，我们在做这个选题时有下载过几个记账app，以及在网上查找到一些关于使用记账软件的反馈；是，在通过根据对用户需求分析之后，我们对典型用户和典型场景有清晰的描述。

1.2 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高？具体提高了多少？如何衡量的？

??我们目前刚结束完第一阶段alpha阶段，并没有上一个阶段可以进行比较，所以这个问题不能做出回答。

1.3 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

??我们实现了alpha阶段制定的功能，原计划的功能共有记账和查询功能，都已经实现了，也在alpha阶段结束将alpha版小程序发布出去，按时将项目交付了。
因为还在alpha测试阶段，并没有进行公开推广，使用的人目前就是同学，亲人（预期用户数20人），以达到。

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

??用户量已达到我们预期估计的用户数量，用户对我们发布的记账小程序的重要功能（记账和查询）的接受程度和我们事先预想的一致，通过咨询使用过我们小程序的用户，小程序的功能符合他们的需求（记账和易用），我们离目标更近了。

2. 计划

2.1 是否有充足的时间来做计划?

??是，我们花了一段时间来做这个项目的需求分析，人员的分配，以及有七次（15分钟）的站立会议来讨论一下项目进度以及遇到的问题。

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

?? 对于处理团队团员之间的意见不同时，我们先让每个团队队员先讲清自己的意见想法，然后采取少数服从多数的原则，确定最终的决定。

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

??我们alpha阶段的工作计划都有做完。

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

??没有，我们团队在开始alpha阶段时就已经进行人员工作的分配，每个人都是按照自己分配到的任务去完成，所以都是些必须的事。

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

??是，我们的每一项任务都是在分析阶段已经协商确定了的，每个任务该完成什么功能都已经清楚，并且在码云上有相应的源代码、软件规格说明书、代码规范文档以及alpha阶段七篇冲刺博客标明项目的进度。

2.6 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

• 项目整个过程并不是一直按照计划进行的，计划有出现一些变动。
• 在项目进行过程中，出现了一个重大的意外，就是我们在安装Eclipse的SDK插件时，安装过程出现了错误，导致软件不能运行，整个项目的进度都被耽误了，并且后来为了项目可以正常进行，我们只好更换了微信小程序平台来开发项目。
• 安装软件失败问题导致项目无法推进，差点出现“开天窗”的结果是当时没有估计到的。
• 因为当时还没有开始项目之前，我们只觉得代码上可能会出现一些问题，就将前期的精力主要放在代码的学习和准备上了，就没有提前进行软件的安装和软件的学习、准备，但是没有想到最后居然是在安装软件时出现的差错。

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

• 在计划中有留下缓冲区。
• 缓冲区有作用，我们团队主要是利用缓冲区的时间里进行我们项目代码的测试、查找项目的Bug和修复项目的已知Bug。也利用了缓冲区这段时间进行团员之间的相互交流，并根据交流的结果对项目进行了完善，像是有些地方的设计改成这样会更好之类的修改。

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

??将来的计划会做出的修改有：

• 我们将会预留出比Alpha阶段更多一些的缓冲区，毕竟预留出缓冲区可以应付一些紧急事件，也可以帮助我们将我们的项目进行完善。
• 然后的话，我们会将工作安排得更加合理吧，避免像这次一样一直在熬夜加班的状态，争取能够少熬夜。

3. 资源

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

• 相对于其他团队，我们团队的人力资源可能就不是特别丰富了，我们团队中有两名成员在编程方面的能力不是很出众，导致大部分项目的任务需要有其他三位同学担起来。
• 时间资源上，也因为安装软件和插件不成功的原因，导致时间上很紧张，我们就只能够利用上一切我们可以利用的时间，还每天熬夜，这才赶在项目截止时间前完成。
• 学习资源很丰富，因为当前微信小程序是比较热门的，网上的教程比较多，可以很容易找到自己需要的学习资料和视频教程。

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

• 各项任务所需的时间一般是按照任务的难度进行预估的，像是界面的排版不是很难这样的任务分配的时间就不会太多，像界面中功能的代码编写就需要分配比较长的时间。一般会根据头一天的任务进行情况来分配今天的任务，像是今天需要完成哪几个任务这样。而其他资源的话，像是人力资源，就会根据每个人的编程能力的大小来分配相应的任务，这样可以节约时间，更好地完成项目。
• 但是我们团队的任务的各项资源分配的精度并不是很高，都比较精度低。

3.3 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

• 各个模块的测试时间相对充足，每完成一个模块，就会对这个模块进行验收，验收合格之后这个模块才算真正完成了，不合格的模块是要重新进行更改的。在整体项目完成后，我们就用缓冲区的时间进行了整体项目的测试，像是模拟用户使用微信小程序的测试，项目自身的测试，像是安全测试，CPU占比等测试，时间上还是挺充裕的。
• 人力资源和软/硬件资源是足够的，本团队共有5名团员，人数充足，并且每个人都安装好了所需要的软件，需要的硬件资源也准备好了。
• 美工设计的难度没有被低估，一开始我们的团队就很重视美工设计这块，毕竟软件不仅仅是有功能就好，而且还需要有美观的界面，才能够令人赏心悦目，让用户满意。所以我们的项目的最终成果的界面还是挺美观的；
• 文案的难度没有被低估，我们整个团队在写博客上每个人都参与进来了，按照每个人分配好的任务进行撰写，保证每个人的参与度和任务的完成度。

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

??有在一些情况下感到我做的事情可以让别人来做更有效率。像是与其，我们每个人在进行编写代码时，都对界面进行美工设计，导致界面风格不一致，最后还要重新修改过，还不如一开始就由一位擅长美工的团员进行界面的美化设计。

4. 变更管理

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

??每个相关的员工都及时知道了变更的消息。我们团队有自己的讨论群，有变更的消息，我们都会在群里发通告，并@所有人，让她们收到回复，这样就能够保证每个人都通知到位了。并且大部分的团队是一个宿舍的成员，基本上都在一起，消息变更的话，知道的会比较迅速。

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

• 我们采用的方法是从用户的角度出发，来决定哪些功能是主要的，哪些是附加功能，哪些是可有可无的，从而排出功能的优先级，来决定哪些是必须在Alpha阶段完成的功能，哪些又是可以推迟到Beta阶段完成。
• 根据我们项目的实际情况，我们首先实现的是项目的主要功能。“必须实现”的功能包括了：每日的收入、支出情况，当月账单的显示，账单的修改、删除及账单的查询功能。完成这些功能之后，我们的项目就可以运行，可以实现用户的需求了。而其余的功能就是可以推迟的功能，我们就可以放在Beta阶段在实现它们。

4.3 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

??有，我们的项目基本能满足用户记账的需求，包含记账，修改，查询，删除的功能都能使用。

4.4 对于可能的变更是否能制定应急计划?

??可以的，就像这次冲刺过程中，我们环境搭建就出了问题，导致我们几乎浪费了一周的时间，眼看时间要来不及了，我们小组成员一致决定更换开发平台，改成做微信小程序，原本的项目根本内容不变；能够及时作出变更决定，以至于我们团队终于在期限内完成了我们的项目。

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

??可以。虽然目前还没有遇到意料之外的工作请求，但是我相信我们队员的能力，以及大家团结在一起的精神，什么困难我们都能克服。

5. 设计/实现

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

??开发初期，我们队员约定先按最简洁的设计来做，但是大致风格要一致，到后期风格再统一设计美化；我们队内有很适合美工的成员，后期能很好地完成设计工作。

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

??我们的设计工作基本上是按照原型设计来走，基本符合预想，虽然也有碰到过模棱两可的情况，但是经我们队内讨论后都能统一意见。

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

??由于我们是做微信小程序开发，使用微信web开发者工具，其本身就可以实时测试代码，所以没有用到其他工具。

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

• 没有什么功能性的bug~（可能是由于我们的项目太简单了~。~）
• 发布之后发现的bug
  • 页面高度设置失误，导致有的手机显示时可以上下滑动
  • 输入备注时，整体框架往上跑了
  • 查询页面没有提示用户点击哪里选择日期
• 对于页面高度这个问题，我们设计时是有考虑的，不同机型可能情况不同，但是没有一个根本的解决办法；日期选择这点是我们欠考虑了，会改进的。

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

??一开始写了代码规范文档，编写代码过程中有疑问都可以去查看；代码复审是边写边进行的。

6. 测试/发布

6.1 团队是否有一个测试计划？

??有的，事实上由于我们使用微信web开发者工具，我们可以实时进行测试，通过不断测试，然后修改达到我们想要的结果。

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

??我们团队并没有进行正式的验收测试，没有客观的用户和测验人员来进行这项工作。

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

??团队有测试工具来帮助测试：优测网的云真机、微信开发者工具的测试。

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

• 团队是如何测量并跟踪软件的效能的
  • 首先总结代码实现过程中自己找到的bug，
  • 然后以用户的身份来使用软件，并根据实际运行情况找出明显的bug ；
  • 其次进行场景测试，对比当初的需求分析，看团队是否实现了核心功能，抓住了用户的痛点；
  • 在不同的平台测试软件；
  • 使用测试软件测试。
• 从软件实际运行的结果来看，这些测试工作的作用：
  ??有用，这些测试结果可以直观的表现出软件是不是“好”
• 可进行的改进：
  ??测试应该尽可能的覆盖所有的情况。

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

??我们的软件的发布是发布到微信平台的，就是将我们Alpha阶段的最终版本提交后进行审核，审核完成后就可以发布，这过程中并没有出现意外。

7. 总结

7.1 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

• 我们团队目前的状态 处于CMMI阶段。
  • 在Alpha冲刺阶段，我们通过码云管理项目代码，分配任务，每天会开站立会议向组长汇报自己的工作量以及工作进度，组长由此知道整体项目的进展，决定接下来项目的发展。
  • 在Alpha冲刺阶段之后，团队有了类似项目的开发经验，一定程度上可重复类似项目的软件开发。

7.2 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

• 我觉得目前团队已经经过了萌芽、磨合的阶段，现在处于规范的阶段。
  • 经过Alpha阶段，团队的每一个人都互相了解，PM分配任务也会考虑每个人不同的情况，根据每个人的强项去安排。

7.3 你觉得团队在这个里程碑相比前一个里程碑有什么改进?

• 经历过一次敏捷流程以后，我们对于软件工程比较了解了，不像之前只是纸上谈兵。
• 有了一些项目开发的经验，在接下来的Bate冲刺阶段，不会很慌张。

7.4 你觉得目前最需要改进的一个方面是什么?

??目前最需要改进的是功能方面。在接下来的Bate阶段，我们要增加一些其他的功能，例如扇形图。

7.5 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

• 我觉得我们小组做的最好的是：
  • 1、尽早并持续地交付有价值的软件以满足顾客的需求。我们在一周的时间里实现了一个有价值的软件，也就是项目的MVP版本。
  • 2、业务人员和开发人员在项目开发过程中应该每天共同工作。团队所有人员每天都要一起工作，并连续7天开站立会议，展示项目的进展，决定项目接下来的发展。
  • 3、以有进取心的人为项目核心，充分支持信任她们。团队以PM和主要开发人员为核心，其他队员作为辅助人员，围绕她们的思路进行进一步的开发。由少部分人带动其他的人。
  • 4、无论团队内外，面对面交流始终是最有效的沟通方式。每日站立会议中，我们会轮流发言，说出自己所负责任务的进展以及遇到的问题，其他团员帮忙解决问题，这样就可以高效率完成项目。
  • 5、试试总结如何提高团队效率，并付诸实践。团队每天有固定的时间来完成项目，这段时间是这样分配的：首先用半个小时或一个小时审核昨天的代码，剩余时间才开始写今天的部分，这样后期代码复审就简单很多。

8. 团队会议照片

9. 成员贡献

Alpha冲刺之事后诸葛亮

标签：.com   没有   代码规范   平台   每日   分享图片   开发者   查找   轻量级   

原文地址：https://www.cnblogs.com/coolgirls/p/9030824.html