TDD中变形动作的优先顺序 - Transformation Priority Premise

在TDD循环中,重构(Refactoring)是不改变行为而改变内部结构的动作,保持测试常绿。而变形(Transformation)是改变内部实现来使测试由红变绿。这些变形的变化使代码形式从特殊specific到一般generic。

Uncle Bob的一篇文章。http://blog.8thlight.com/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html
中用了bowling game kata 和 Prime Factor kata来解释。

继续阅读 More

Do you like my piece of paper?

What I see every day is people creating pieces of paper to take into a room for people to look at and decide if they like that piece of paper, and if they don’t totally like it they say what they would prefer to see on that piece of paper.

This repeats until everybody is happy with a piece of paper.

capture3

继续阅读 More

SVN pre-commit hook

某团队希望做到Continuous Code Review, 想在每次check-in 到SVN之前,先判断特定用户群体否在commit log里面包含了”Review By: xxx”的字样。

记得以前NSN里面有人用过这个法子,记不太清了。

于是研究了一下脚本,其实SVN/GIT都提供了类似的hook, 在<your repository>/hooks 目录下,都是shell或cmd脚本(要看服务器的操作系统了),会在不同的事件时触发。

为了实现更复杂的功能或者需要跨平台,那不妨用shell或cmd去调用Python脚本咯。

继续阅读 More

python中的比较运算

python语言对于各种类型都可以比较。

例如int类型,当进行大小比较时,其实是调用了cmp函数,或者可以显式调用cmp(),返回值为{-1, 0, 1},表示小于,等于,大于。

对于str类型,list类型,,class类型等,其实是调用eq, ne, gt,ge,lt, le等函数,分别对应==, !=, >, >=, <, <=等.

可以根据需要覆盖这些函数达到重载运算符的目的。注意,这里有个坑,就是eq, ne是两个运算函数,而不像Java里面,只有一个Object.equals()函数。

继续阅读 More

固定范围、固定交付日期情景下团队盲目做出不能实现的承诺,如何改善?

在我给客户提供需求培训和教练服务时,以及在各种敏捷社区活动中,被多次问到scope fixed,deadline也fixed的时候,团队被强制“承诺”必须完成全部需求,此时除了抱怨还有其它方法吗?我把这类问题定义为“固定范围、固定交付日期情景下团队盲目做出不能实现的承诺,如何改善”的问题。

除了背地里大骂那些经理们无知之外,我们真的无计可施了吗?非也,”THERE IS ALWAYS A WAY OUT”, 我整理了下我在不同场合的回答和思考,做成了一个脑图,敏捷教练不传之秘也,供大家参考。

更多敏捷教练经验观点见 https://www.uperform.cn/blog-article/

如何理解用户故事INVEST规则中的独立性和破解依赖?

用户故事INVEST规则中的第一个“I”,Independent独立的,是说用户故事应该是自包含的,没有对于其他用户故事的内在依赖。但在实践中,很多人觉得这个基本很难做到,甚至完全不可能,造成很多困惑,那到底该如何理解这条规则呢?

借鉴前人的知识,结合本人的认识和经验,这篇博文从理论和实践角度对此做一个深度剖析,希望能对你有所帮助。

继续阅读 More

Scrum团队的度量

谨慎选择要度量的内容…因为,你度量什么就会得到什么

文中介绍了几种对于Scrum团队的度量,包括:

  • 团队”完成”的速率(故事点)
  • 下个迭代的预测速率(故事点范围)
  • 下个迭代团队计划的速率(故事点)。团队不见得能一直按照预测来保持速率。
  • PO接受的实际速率(故事点)。注意团队“完成”的与PO接受的速率可能有差别!
  • 开始了但却没完成的故事(故事点及个数)
  • 迭代中新增加到Backlog的故事(故事点及个数)
  • 迭代中范围变动情况
  • 迭代中引入的技术债务(故事点)
  • 迭代成本
  • 发现/移除/上报的障碍
  • 迭代成功失败率。按照固定时间固定范围作为基准。

原文:http://agileatlas.org/articles/item/large-scale-scrum-less-is-more

大公司里技术专家转做基层敏捷Product Owner,前途何在?

同一般小公司或互联网公司的产品不同,电信设备行业软件系统很复杂,动辄几千人做一个系统。即便在敏捷模式下,为了支持Scaling Agile, PO也是分层次的。三层很常见,越往上,越倾向于管理和协调,越往下,越倾向于实际需求管理和技术。最基层的PO往往是从技术专家转型而来,在初任PO的几个月里常常存在不少困惑,比如:无法投入更多时间花在自己喜欢的技术上;需要同很多人打交道,不仅花费了很多时间,争吵也是常有的事,很多看似简单的事情并不容易推动,很不适应这种工作状态,常有想回到过去纯做技术的冲动。

PO到底是个什么职位呢?在互联网类的公司里,PO做为产品经理是科技,商业与用户体验的综合体,有权决定产品的未来。但在电信设备类的公司里,情况稍有不同,我总结为PO乃技术、管理和人性的综合体。

继续阅读 More