# Second week in india | 大染志
上周是TWU的第二周，Session 变少了，取而代之的是我们的项目“Freewheels”，这一周给人的感觉的很累，每天很努力的做Story，也帮其他同学解决一些问题。 Session这一周我们还是有几个Session, 加上上周学习的有 TDD, Mock与Stub, 重构，非技术的有 TW Finance, Story的生命周期。也许是因为Story的原因，让我对某些Session的印象都模

大染志

Junv's blog

# Second week in india

发表于 2013-09-17 更新于 2026-08-04

上周是TWU的第二周，Session 变少了，取而代之的是我们的项目“Freewheels”，这一周给人的感觉的很累，每天很努力的做Story，也帮其他同学解决一些问题。

##### Session

这一周我们还是有几个Session, 加上上周学习的有 TDD, Mock与Stub, 重构，非技术的有 TW Finance, Story的生命周期。也许是因为Story的原因，让我对某些Session的印象都模糊了。最清楚了应该算是Mock与Stub了。
来印度之前一直没有搞明白Mock与Stub的区别，我只是知道他们都是用假的对象来模拟真实的对象。而通过这次的Session算是搞明白了。
Coach 给了个题目，这里有三个类 CashRegister（接口）, Printer（接口）, Purchase, 现在在CashRegister中会调用 Printer打印 Purchase，现在需要测试该方法，问如何测试， CashRegister， 和printer 的执行方法 均为 void,无返回值。不能用Mockito 框架。
拿到这个题目，我是完全没有头脑，因为我之前用过的 测试都是通过结果来测试数据的，而这次测试的方法不仅没有返回值，而且被测试的类还是接口。
就这样按照coach的指导，基本模拟出了简单版的Mockito来测试这个方法，如果使用Mockito我们只需要使用：

    1

    verify(cashRegister,times(1)).process();

最后coach总结出了，Mock和Stub的区别在于，Mock会验证，而Stub则是你让他干什么，他就给你什么。瞬间感觉豁然开朗的感觉。

##### 项目

从这周开始，项目就是TWU生活的主体内容了，当然coach们是希望我们把session中学到的东西全部利用到项目上面来，但是结果是残酷的，第一周我们表现得并不好。在项目正式开始之前，我们两两Pair做了一个在用户注册表单中添加地址、城市、国籍、邮编等信息，当然也需要在用户详情页面中显示。有人半天时间几乎完成了大部分story，我和我的pair完成了1/3左右的工作量，其他同学也或多或少都完成了一些。演示代码的时候，做得很快的那对pair，他们将所有用户地址相关信息也都全部添加到用户表中，其他实现也都是在之前的基础上进行复制，粘贴，修改，添加。从这个时候开始我就明白了，每个人来TWU 的目的真的是不一样的，有些人是想提升自己的技术能力，能多学一点东西，有些人希望用自己的能力帮助团队提高效率，解决问题，有些人希望帮助管理、组织团队。
在之后的Iteration planing meeting上面，大家普遍对小组完成story的能力比较乐观，我们小组计划在一周内交付40点。
何为1点，在界面上为登录用户显示欢迎信息为1点。为用户注册、用户详情查看、管理员详情查看页面，当然包括编写funtional测试，这个story是5点。按照我们自己的计划我们一周内可以交互 3/5 * 6 * 5 = 50点。大家想到每天可能会有session会耽误时间，所以将点数减去10点，因此我们需要交付40点。我们小组来自中国的两个同事，包括我在内，是反对交付40点的。也许是因为在项目上滚过一段时间吧，知道40点没这么容易。
在接下来的这一周里，大家也意识到了时间的紧迫，我们也知道了我们小组是计划了最多交付点数的小组，同学们都非常努力，每天的standup 也很积极，story 墙上的story也在墙上快速流动，似乎我们就可以完满完成我们的交付点数了。
但是，我们很多地方并没有按照session中学到的东西来做，在讲story挪到ready for dev 的时候我们并没有对AC进行详细检查，所有story也没有mockups,所以必须靠我们自己来想象。比如dev在拿新卡的时候，基本上没有和QA(因为我们项目中没有BA，所以QA既当妈，又当爹)对story进行kick off,遇到story里面描述得不清楚的地方也许首先会自己想想怎么样最好，然后再去问QA和PO，有时候我们也在做assumptions,dev开发完story后有时候并没有跟QA进行演示和确认。所以我们看到墙上的story流动的比较快。
到了showcase的那一天，在showcase 之前的10分钟，不少同学都还在提交代码，我也在其中，当然我们的QA也在很负责的进行代码的手工测试，那天我做聪明做了很多UI的美化工作，但是结果是把两个地方弄巧成拙了，一个地方是我自己做了assumptions ，给商品的展示进行切换排序，在修改一个按钮的css样式的时候，我也没想到那居然会影响到其他一个页面，当然之所以没影响，是一个一个同学copy另外一处的代码，并且没有修改。
毕竟因为我们项目的细节大部分没有测试到，最后我们只交付了4点。当然有很多story是因为bug的原因不能交付。

在项目上的第一周，就给我们的感触很多，当然教训也是很多，现在已经太晚了，已经凌晨1点了，这里只想提几个问题：

- 在这样的情况下，我们到底是更多的关注与每个人定的自己不同的目标，还是全心全意把所有的心思都放在项目上？
- 在这个情况下，到底是项目的正常交付重要，还是保持代码的质量更重要。
- 在TWU中4个小组，共享一个client，只有一个印度同事来担任PO适合足够？因为很多和story相关的事情都需要和client确认。
- 在这样的情况下，能力稍强的同学是否应该快速自己的速度，帮组团队完成交付目标，而放弃与某些编程能力相对较弱的同学pair、交流？
- 在这个情况下DEV 是不是只应该关注自己的开发和单元测试、functional测试任务？ 在我们项目中没有BA,12个DEV，2个QA
- 很多同学为了尽快完成story，通常晚上也会pair到较晚的时候，最近逐渐发现，不少同学已经开始疲劳了，早上的session的活跃度感觉有点下降，这样到底是不是对的？

这些都是我自己心里面的问题，我有一些想法，但是肯定里面有些是很主观的，不对的。所以就不写自己的想法了，暂且提及问题。

0%