Second week in india

上周是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的活跃度感觉有点下降,这样到底是不是对的?

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