经常听到有人抱怨说，敏捷实践中会议太多，形式主义严重。在真实了解实际情形后，我们会发现并非这些敏捷实践本身没有价值，而是因为没有正确地领会会议的目的，采取了不恰当的会议形式，或其它深层次的问题，导致会议不能产生预想的结果。每日站会就是一个例子。

首先必须明确，每日站会的目的：基于迭代目标的团队协作和快速反馈。更详细点地说，每日站会提供了在达成迭代目标过程中的团队协作同步点，以及快速反馈循环中的检查和调整点。它的目的不是汇报状态，不是要知晓每个团队成员昨天把时间花在了哪里，不是要知道每个人将要把时间投入在什么地方，而是对目标的跟踪和校准，以及加强在达成目标过程中的协调和合作。

Read More

在梳理用户故事时，一个常见问题是：我们应不应该有独立的性能测试相关的用户故事？

Read More

1) 在用户故事中，将开发中的相关人员作为系统用户角色

比如 As a po/apo/ppo/developer/tester/manager/integration engineer， I want 。。。

必须注意，As a 中的role是运行时实际使用该系统的用户角色，不是开发时干系人的角色

包括客户文档相关的用户故事，也要以实际使用该文档完成某项任务的视角来描述：什么角色，什么情况下使用该文档用来做什么，达到什么样的可衡量的目标等，而不是某经理要求该文档。

2) 把系统的发布版本放入用户故事标题中

Read More

python’s decorator is like Java’s annotation, but more flexible and easy to implement because of python’s syntax. Both is to use a time way to realize AOP, to insert job of other aspect and make you class/func concentrate to bussiness logic.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

def anna(fn):
 def new_func(*args):
 print 'by anna args=%s' % args
 return fn(*args)
 return new_func

def annie(ar):
 print 'by annie1 ar=%s' % ar
 def _A(fn):
 def new_func(*args):
 print 'by annie2 args=%s' % args
 return fn(*args)
 return new_func
 return _A

class ccc():
 @anna
 def __init__(self):
 print 'ccc'
 @anna
 def ff(self, a):
 print a

 

@anna
def test1(a):
 print a

@annie('hi')
def test2(a):
 print a

test1((1,2))
test2((3,4))

Scrum is a starting point. In fact, it’s a great starting point. But, as a framework rather than a full-blown methodology, Scrum is deliberately incomplete. Some things—such as the best technical practices to use—are left for individual teams to determine. This allows a team to create the best fit between their project and environment and an assortment of technical practices.

Scrum是一个起点。事实上,这是一个很好的起点。但是,作为一个框架,而不是一个成熟的方法论,Scrum故意是不完整的。一些措施——例如使用最好的技术实践——留给每个团队自己来决定。这允许一个团队在他们的项目和环境和各式各样的技术实践之间创建最适合自己的方式。

Read More

至今，我仍能记起当我顿悟并最终产生下面文章时所在的地方。那是1986年的夏天，我在加利福尼亚中国湖海军武器中心担任临时顾问。在这期间，我有幸参加了一个关于Ada的研讨会。讨论当中，有一位听众提出了一个具有代表性的问题，“软件开发者是工程师吗？”我不记得当时的回答，但是我却记得当时并没有真正解答这个问题。于是，我就退出讨论，开始思考我会怎样回答这样一个问题。现在，我无法肯定当时我为什么会记起几乎10年前曾经在Datamation杂志上阅读过的一篇论文，不过促使我记起的应该是后续讨论中的某些东西。这篇论文阐述了工程师为什么必须是好的作家（我记得该论文谈论就是这个问题——好久没有看了），但是我从该论文中得到的关键一点是：作者认为工程过程的最终结果是文档。换句话说，工程师生产的是文档，不是实物。其他人根据这些文档去制造实物。于是，我就在困惑中提出了一个问题，“除了软件项目正常产生的所有文档以外，还有可以被认为是真正的工程文档的东西吗？”我给出的回答是，“是的，有这样的文档存在，并且只有一份——源代码。”

Read More

几年前读过，现在重读一遍，又发现一些当时忽略的或者不理解的细节，开场、结束尤为重要，回顾引导者需要控场能力，包括时间盒、节奏、气氛、主题、形式等，对观点尽量保持中立。

1. Set the stage.
2. Gather data.
3. Generate insights.
4. Decide what to do.
5. Close the retrospective.

Read More

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

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

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

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

对于很多初步接触极限编程（Extreme Programming, XP）的同学来说，XP似乎宣告了程序设计的死亡。不仅限于很多设计行为被嘲笑为“冗余的前期设计”（Big Up Front Design），而且连像UML，灵活的框架（Framework），甚至连模式（patterns）这些设计技巧都被轻视乃至被完全忽视。实际上，XP中包括很多的设计，只是不同于以往软件开发流程中的做法。XP通过允许进化的实践技巧使演进式设计（evolutionary design）成为一种可行的设计策略。它还为设计人员（Designers）提供了新的挑战与技巧，令他们去学习如何使设计简单，如何利用重构保持设计的整洁，如何在一个演进的形式下使用模式。

Read More

2001年，一群美国码农去滑雪，整了个敏捷概念出来。2013年，一群中国敏捷教练何尝不可聚会一起吃个涮羊肉，兴许也能整出些引领世界的新玩意儿。

想象大冬天一群人围坐吃着铜火锅，似乎也能体现敏捷Scrum价值观。

开放：荤的，素的，都可以涮。爱吃辣的，爱吃韭菜花，各取所需。
勇气：挺烫的肉，出锅直接就往嘴里送啊，就是要享受肉片在嘴里融化的感觉。
专注：特别是传统铜火锅，筷子一定要夹住了肉片放进锅里涮，绝不能松手，要不就找不到了。
承诺：“咱们今天来5斤肉片，吃得了吗？“ “当然吃得了。” 饭后，肯定是一片肉都不剩下。
尊重：围坐一圈，大家的筷子伸在一口锅里，互相平等，其乐融融。