第一次迭代开发心得

一、设想和目标

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

我们的项目是高血压家庭管理系统和后台管理平台。

高血压家庭管理系统是高度智能化，管理综合化的血压管理平台，为高血压患者提供完善的高血压管理服务。

本系统将移动互联网应用于高血压的大量数据处理、长期监控、有效管理，把这三个方面进行很好的结合。为了便于用户使用和系统的普及，高血压管理系统软件的设计界面友好、直观易操作，实现病人——基层医生——专科医生三方长期的互动式对话。

• 典型用户：高血压患者
• 典型场景：家庭高血压测量

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

• 实现情况：
  • 病人可以上传血压数据并生成走势图，以及用药方面的管理
  • 后台管理平台已实现用户的基本操作（增删改查）
• 交付和用户：软件功能基本实现，但实际投入使用存在困难，暂时无法投入使用

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

• 暂未投入使用，用户实际接受成度未知
• 产品完成度好，当然离目标更近了

1.4有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

因为之前没有过项目开发的经验，所以我们一开始的开发进度很慢，不知道从哪里开始下手，第一周基本就浪费在相关的demo的学习上了，大部分的开发是在后两周完成的。如果再来一遍，我们会将开发进度推前，可以让小组内基础好一点的先做，然后带着不会的一点点跟进，以点破面

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

二、计划

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

我们在第一次迭代的过程当中，因为我们的项目分为一个APP（患者端）和一个web端（后台管理系统），我以我们分工很明确，两个人做APP，两个人做web端，一个人负责服务器和数据库搭建，这次毕竟是第一次团队的合作，正处于磨合期。所以效率上面不是很理想。第一次迭代总共的时间只有四周外加除了这门课程之外还有其他的课程。所以第一轮迭代时间不是很充足。

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

• 计划阶段讨论都很顺利，没有太多不同的意见，可能这也是不足的地方

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

第一次迭代计划我们都完成了，能够完成的原因有如下几点

1、我们分工非常的明确

2、我们的每周任务非常明确

3、我们每周有固定的线下编程

4、组长组织有效，快速进入第二阶段至第三阶段的过度阶段

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

有，我们在一开始花了大量的时间去看github上的类似项目，包括项目需求，这让我们浪费了大量的时间。完全可以在边学的时候，边写东西，而不至于看完之后还是一头雾水，什么成果都没有，一旦你动手开始写，就发现很多乱七八糟的问题来了

 

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

因为我们的项目是APP的开发，所以每一项任务都很清楚，每一个需求都能够从APP中展现出来

 

2.6 是否项目的整个过程都按照计划进行?

开发过程中，少数情况下由于学业任务和突发情况，或者任务过于困难，导致当周的任务没有及时的完成，但是一般在次周都会及时补上。其他的情况基本都能够按照迭代计划完成

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

在计划中我们一直留有缓冲区的习惯，但是由于各种限制因素，导致我们团队的时间不能够统一，所以有时候缓冲区并没有起到真正意义上的作用

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

我们会在原来的基础上抽出周三和周六全天的时间进行线下开发和讨论

2.9 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

我们会将计划超前，留出足够的缓冲时间来应对一些始料未及的问题

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

三、资源

 

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

我们完成了任务，但时间限制，没有做到完美，有很多地方用户体验不够好

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

第一次开发没有概念，一开始就是先能做多少就做多少，有问题再拿出来一起解决

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

测试没有系统、详细的安排，在最终整合之后，有做了简单的测试，但是测试时考虑的不是很全面，美工是做的很不好的一点，在后期实施上出了很多问题，低估了难度

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

没有

3.5 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

重来一遍我们会提高对接的频率，增加对软件测试的时间

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

四、变更管理

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

我们队有一个qq群，每次有情况就及时通知，收到通知并及时回复

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

我的部分是服务器和数据库的搭建，都是比较重要的部分，所以都必须实现，至于小组的其他成员不是很了解

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

 能够满足项目的需求文档的所有需求

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

没有提前制定应急计划，但有变更时会及时做出反应和调整

 

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

大家的及时调整都很棒，对于意外的发生也能做出迅速的反应

 

4.6 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

增加缓冲时间，应对可能发生的影响进度的问题

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

五、设计/实现

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

团队的设计工作是在需求分析阶段小组成员一起确定的

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

没有

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

有UML图来帮助设计

 

5.4比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

文档更加丰富了，会在项目推进中，不断完善、更新文档

 

 

5.5 什么功能产生的Bug最多，为什么？ 为什么我们在设计/开发的时候没有想到这些情况?

我们的项目主对于数据的处理很关键，我们的bug出现在数据的处理上，因为我们前后台是分开开发的，有的数据是在后台进行验证，有的是在客户端直接进行验证，所以导致有些数据的验证会遗漏。在第二次迭代中我们会将每一个数据的检测做好记录。其次，我们的团队没有专门的测试人员，而且时间有限，我们的测试数据的规模不是很大，范围不是很广，导致有些情况上的遗漏。

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

我们团队有web端，android端，和服务器端，所以代码的规范都不太一样，我出现的主要问题是，没有对不再使用的资源进行及时的回收，类命名上没有完全按照标准来

 

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

六、测试/发布

6.1 团队是否有一个测试计划？为什么没有？

有制定详细的验收标准，但没有详细的测试计划

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

否

 

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

暂未考虑

 

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

暂未考虑

 

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

暂时不考虑发布

 

6.6 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

还是以完成项目功能为首要任务，测试方面暂时没有精力、时间考虑

 

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

七、团队的角色，管理，合作

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

团队角色确定，以尊重个人意愿为首要因素，再根据实际情况协商确定角色

7.2 团队成员之间有互相帮助么？

团队之间经常交流，开发氛围很放松

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

项目能够顺利推进，离不开小组每一个人的努力，我们的分工很明确，没有出现过很大的团队开发问题

 

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

八、总结

1、我们仍然处于一个过渡阶段，也就是虽然大部分的规范规则已经定义，但是仍然有不少东西还处于未定义、未规范化的状态。

2、正式开发前没有完全定义好接口，使得整合工作难度加大，今后的项目开发我们会在设计阶段定义好大部分接口

3、分工上没有完全利用好团队资源，我相信经过第一次迭代的磨合，团队的开发效率会有很大的提高

4、对软件的测试不够全面，后期我们会增加对软件测试的范围和力度

5、小组使用线下开发模式，不够效率，我们第二次迭代会适当增加线上开发的时间

6、用户体验不够好，一些输入过的数据需要重新输入，很多数据不能够提交，没有弹窗提醒数据错误，比如说验证码发送失败，后期我们准备邀请其他人来试用我们的app，然后根据建议进行改进

 

 

转载于:https://www.cnblogs.com/hnuzb/p/10075847.html