敏捷团队之旅(2) - 新年前的第一个迭代

前面的工作已经用去两三周的时间，也接近春节，团队成员也陆续定好归家的行程，整个团队在一起的剩余只有六个工作日，这样我们就面临三个尴尬选择：

• 春节后人回来齐了，再启动第一个迭代。
  显然这不是一个好选择，好不容易鼓舞起来的激情，可能会烟消云散。

• 启动这个迭代，剩余的4天延续到节后。
  大家都认为这个选择也不太好，中间横跨着十多天的假期，很难接起来。

• 启动一个六个工作日的小迭代。
  尽管时间没有两周，无法积累正常的产能数据，我们认为应当乘热打铁，先做一个迭代，交付一个版本给公司作为新年礼物。

公司为了避开早晚高峰，采用弹性上班时间，早上10:00 ～ 10:30 上班，下午 19:00~19:30 下班；中间的半小时时间属于弹性，也就是说早上10:30前到公司都不算迟到，非常不错的制度。

技术部的伙伴由于都习惯了朝九晚六都节奏，就申请了09:00～09:30上班，18:00~18:30下班。

因此，我们便把每天的会议时间定在上午11:00举行。

---

第一个迭代计划会

第一个迭代计划会，团队没有的历史产能数据，对功能规模估算也不是太熟悉，故事也还没有完成相应的验收标准确认。

大家理所当然的拍脑袋承诺交付范围。我们强调一个原则 no over promise.
PO与团队交涉范围，现场编写并审核验收标准, 计划会花了半天时间。

Iteration 1 : 2017年1月17日 - 2017年1月23日，6 工作日

User Stories：12个

交付范围：用户邮箱手机的登陆与注册功能，共12个用户故事。
团队能承诺交付这么多故事，主要有两点：

1. 这些功能之前已经实现过一次。
2. 只交付iOS版本。

计划

看板：

第一天看板

燃尽图：

第一天燃尽图

实际执行

看板：

i1_d6_kb.jpg

燃尽图：

i1_d6_b.jpg

提前一天完成交付的功能，最后一天的时间，主要用于人工回归测试。

评审会

团队向PO演示了交付成果，展示过程中发现了几个缺陷，以及一些有争辩性的需求范围问题。估计由于大家都想着过年了，PO也比较好说话，还是接受这次交付。

回顾会

团队经历了一个短小的Sprint，对Scrum的5个活动和交付，都有了初步的体验和认识。总结了本次发生的问题：

1. 计划会议前准备不够充分，导致计划环节占用了过多时间。

2. PO由于经验原因，对AC的审核，不够严密。导致有些故事的AC不够全面。PO背这个锅，并承诺在后续Sprint中改进这一点。

3. 第一次做交付演示，准备工作与环境准备不够充分，导致回顾会开始超过半小时才能进行演示。

4. 由于App前端对ReactNative的熟悉程度不够高，以及架构分解设计能力问题，导致功能交付粒度变粗，燃尽图上曲线先平后陡。

5. 同时，App验收测试工作是人工测试，在功能未完成前，其他人无法帮上忙，只能依赖app开发人员自己边实现边测试。这是本次交付质量问题的主因。

6. 后端开发，由于从一开始就做了充足的测试用例，因此后端的质量得以有效保障。 但是此时，后端的测试，是人工启动测试脚本，还没有做自动化持续集成。

7. UI设计师不会SketchUp，用Photoshop来做各种标线，影响了前端开发的效率和还原效果。

8. 团队仍然未能累积实际速率数据。

改进

1. 团队中没有测试人员这个角色，再加上，APP测试用在是全手工，第一个迭代中，我们就已经遭受质量问题，完全用手动来做全回归测试，对于我们来说，是个不现实的做法。因此我们需要寻找全自动化测试的方案，来解决全回归问题，确保每一个交付的质量。

因此也就有了我的第一篇简书分享 《敏捷实践 (1) - 我们是如何自动化App验收标准》

2. APP开发人员在春节期间，提示对ReactNative的熟悉程度，以及功能实现的依赖解耦能力。

3. UI设计师学习SketchUp。

4. 计划会之前，做好用户故事细化准备工作，控制计划会的时间占用。

5. 评审会前，做好演示准备工作，演示设备、环境....

---