慢阻肺疾病管理APP——第一次迭代心得

时光匆匆，不知不觉就到了第十二周。——第一次迭代都完成了，最终迭代还会远吗？

一、第一次迭代的设想和目标：

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

软件要解决的问题：针对慢阻肺病人的后期康复，减少医患沟通负担，给予病人一个更好的平台去问医、监督个人康复进程。

典型用户：慢阻肺病人和治疗医生。

典型场景：家庭治疗。

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

原计划：实现登陆注册、患者端接受和查看护理计划、医生端制定以及发送护理计划、医患聊天界面、消息列表、医生端患者列表、医生端和患者端个人中心、患者端健康中心。

实现功能：可以登陆注册（手机验证方式）、患者端查看当前使用的护理计划、医生端制定并发送护理计划、消息的发送和接收。个人中心和健康中心未整合。

alpha 阶段的最终验收，可以按照计划完成，但是个别小的细节有待改善。目前还没有到最终发布阶段。

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

从学会去设计数据库、撰写需求文档、uml的使用、再到安卓知识的从0->做出成果。甚至是人与人之间的沟通。这些都是这短短一个多月给我的成长。

如果能重来，我们一定会精简需求，给自己做一个好的定位，明白团队在短期内能做到什么，不能好高骛远，否则过程中会是痛苦的。

二、第一次迭代的计划：

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

时间十分充足，只是后期实施上和美妙的计划有差池。

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

计划阶段小白们更倾向于向指导老师求助。大体上先私下讨论出来，再去咨询指导老师的意见，看看是否可行。如果有不同意见，还是要给予保留，然后再总和老师的意见，共同商讨。毕竟姜还是老的辣！

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

原计划是很美好的，预计在短时间内能完成的工作实际上也完成了，只是因为团队还处于一个磨合阶段，所以队员之间的有效沟通是有限的，导致模块之间没有完成整合，所以成型的部分是差强人意的。这一部分主要是队友之间，不仅要共同工作，还要保持进度，一个都不能落下！

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

我认为，所有的事情，做了就一定有意义。这次迭代过程，是一个从无到有的过程，肯定要自己学习很多新的知识。没有人能够保证，你学到的知识肯定能用的上，正是因为走了很多弯路，才知道走正路的不易，才会更加珍惜自己做出来的每一个预期中想要做到的成果。

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

团队来说，这项定义不是特别清晰，大家都是对着需求文档和需求模型来做的，有模糊的地方会互相咨询，但是最终交付标准，由于队员之间能力差异问题，一些严苛的标准还是有待实现。所以这也是我们下一个迭代要严抓的问题。

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

也就是我一直说的，团队的模块之间的整合没有预期完成，这个是出人意料也是让我崩溃的。但是出了这种意外就要想办法去面对。团队的沟通，沟通，沟通，这一点太重要了！

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

当然有缓冲区。项目中的难点，往往是要留有缓冲区的，因为它的难度和实现时间是谁都说不准的，所以要做好一切准备，给这个部分留一些时间、空间。往往是不那么紧迫，倒是能实现细致的效果，减少bug的出现。熬夜是不会总能得到好的结果的，身体是革命的本钱。

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

第二次迭代还是要留有缓冲，偶尔那么几天，该睡睡该玩玩，放松后再去工作效率是很高的，前提是能把心思收回来。现在团队已经在计划中实施了，正在紧锣密鼓相约工作。这样可以绝对保证团队的每个人都在认真做事，并且能真正及时沟通。

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

Of course,所有经验教训背后都有一个上火的夜。For example, 第一次迭代终止日期前，我们这帮小白纷纷慌张，为什么？没有整合好！这时老师的那一句：做一点整合一点的话语开始围绕着我们，可惜只能熬夜用头发换成果了！本来alpha版本可以做的更好，可惜，人生没有再来一次的机会！如果上天再给我一次机会，我一定会和队友天天沟通，共同前进，而非各自单飞！

 三、第一次迭代的资源：

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

老师、助教、甚至各种网站，这都是我们的资源，甚至我们可以找大神指点。资源是有的，但是有没有精力去完成“各项任务”，那就要看自己的努力了！还有很重要的一点，计划和时间的关系——计划是否和剩余时间匹配。如果计划远大于剩余时间能完成的量，那么时间资源可能是不太充足！所以我们现在都属于一个加班状态！

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

时间是根据个人能力来预估的，每个人都有每个人的任务完成时间。但是总体上还是要赶上团队计划。

由于每个人的空余时间点不统一，前期时间精度不够好，所以后期，大家有事没事都要在一起工作，把效率最大化，最大化利用可以利用的资源。

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

前期只是简单的测试，对于我们的开发来说，测试不是一个难题，开发过程中能力是一个最大的问题：团队成员能力参差不齐，能者多劳恐怕是必须要有的了。美工设计是我们一直在跟进的，由于不需要有过于浮夸的界面，基本的美工对于团队来说还是小case。

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

我想这是每一个人，在面对大神的时候心里都会有的想法。我承认，在技术上我可能花两倍时间都不一定能完成技术猿半小时能完成的量——我之所以这么说，是因为我目睹了组长的神操作。但是我也可以自信的说，我在团队中是无可取代的。我相信我的审美肯定要好很多，那我就可以在前端多下功夫！能做什么就尽力去做！千万别因为自卑或者自愧不如的心理，变成一个自暴自弃或者一味去依赖团队的人。

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

时间上团队成员要尽可量统一，在可能的情况下，大家要共同去利用自己的时间资源。此外，要学会合理地利用队友的智慧，不能一个人埋头苦干，可以去通过团队解决自己解决不了的问题。

四、第一次迭代的变更管理：

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

是的，这是一定的。并且这样的变更往基于团队成员的许可。毕竟这不是属于某个人的项目，而是所有人都应该负起责任的项目。

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

首先是基于项目的侧重点，也就是核心功能，将其设为必须实现的功能。其次，一些细小的部分（可有可无的，无关紧要的，不会影响预期解决问题的），会被设为推迟。然后再基于团队的能力，在过程中做一些小的调整。

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

能实现预期的功能，解决软件要解决的问题，不出bug。

患者端：护理计划、健康中心、消息列表、个人中心。

医生端：护理计划、患者列表、消息列表、个人中心。

推迟部分视情况而定，但是这些大的模块要保证完成。

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

这是必须的。变化的不只是需求，还有过程中的一切。对于可能的变更，组内商讨有一个应对措施，但是对于将来可能发生的不可控的因素，还是要走一步看一步，具体情况具体分析。

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

现阶段还没有意料外的请求。但是就第一次迭代的情况来看，组员们还是很有应变能力的，所以我对大家都有信心！

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

对于变化，是没有人能预测到的。做好自己的本职工作，才会有精力去应对变化，以不变应万变。所以对于团队，一定要按时做好自己的任务，互相监督，减少自身因素给团队带来的意外！

五、第一次迭代的设计/实现：

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

设计工作在项目初期和指导老师共同商议决定，时间合适，团队人员都参与到了这个设计工作。

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

这也就是我们所说的模糊定义——这样也可以，那样也可以。二者必选其一。往往纠结都是我们团队私下讨论的时候纠结，然后保留意见，和指导老师沟通，确认最终的方案。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

UML有使用。活动图类图用例图都使用的UML完成。UML文档随着项目的进行，不断改变——牵一发而动全身。有些细节问题，呈现到UML上，会有很大的不同。UML文档是随着里程碑而不断上传更新的。

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

天气信息的获取部分是一个很大的bug，一些接口都是要我们付出一些代价的，所以现在还没有完成。设计时，还是没有参考好自身的能力，导致过程中因为能力不足，给自己的带来了很大的麻烦。

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

目前是小组互评。但是由于安卓和java有一些差距，所对于不同小组不同标准互审的结果，我们还是保留自己的意见。对于团队来说，第一次代码规范互评，我们还是很遵守安卓代码规范的。

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

当初我们设想自己能完成巨多的任务，实际上上手操作，和想象中还是有差距的，这也许就是现实和梦想的距离。前期期望过高，就会造成过程中的尴尬，还好这些问题也被我们的机智给化解了。这也是我们在第一次迭代过程中一大缺憾——队友进度不一，所以在未来几周，我们已经决定要多多沟通，常常沟通！

六、第一次迭代的个人总结：

对于安卓，我一无所知。但是从无到有，虽然过程是让人崩溃的，但是当看到结果，心里还是很欣慰的，我想这就是一个程序员能从早到晚面对代码毫不懈怠的原因——因为有所期待，所以才会坚持。

自律和自学的能力在这个过程中显得无比重要。这时候就会比平时学习的时候更加意识到度娘的伟大。csdn、博客园等可以汲取能量的网站在这个时候无疑是救命稻草。此外，好队友在这个时候会带来希望，会让人感觉：明天会更好。

在这个过程中，error不是最令人绝望的。队友之间是否共同进步，竟然成了我心里最大的挂念。团队合作，真的太重要了！团队、合作，缺一不可。

———————————————————————————————————————————————————

当我们还在安卓的大海里自由自在慢慢悠悠地钓鱼，前方的渔夫提醒我们：准备好！看看你们谁捕的鱼又大又好！这个时候，往往是慌乱的。

当团队的结果放到一起，那时候，才会领悟到老师强调的：做一点，整合一点。但是欣慰的是，迭代验收之前，我们还是完成了基本目标。强大的队友牺牲自己的睡眠，找bug、调试代码.......还好验收完，心情轻松了一晚上！

———————————————————————————————————————————————————

当团队坐在一起，众人拾柴火焰高，效率往往是很高的。尤其是对于组内实力不均的情况来说，团队可以共同处理那些一个人没有办法完成的问题，一个都不能落下！

还有，针对第一次迭代过程中的不足第二次迭代要注意：

1. 团队要经常及时有效地沟通。

2. 及时整合彼此的代码。

3. 彼此监督，按时完成各自的任务。

完成了第一次迭代，队友们的感情比以前增进了很多，一些共同学习的时刻，真的想让人用相机捕捉。

言归正传，海豹突稽队大家都要加油！我们一定能行的！

尽管世界上有99个人说你不行，但是只要有那么一个人说你可以，你也要坚持！