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斤肉片，吃得了吗？“ “当然吃得了。” 饭后，肯定是一片肉都不剩下。
尊重：围坐一圈，大家的筷子伸在一口锅里，互相平等，其乐融融。

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

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

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

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

Read More

“让蜕变发生!” 优普丰的CSM敏捷认证课生动有趣，学员反映干货十足。参训客户的大老板也在场，当堂要求下属思考回去如何开展实施。大家还把老师的画带回去贴在办公室里面。通过视觉表达 (Visual Facilitating)来引导大家提高代码设计能力，体验敏捷开发过程。[愉快]

 

Read More

当人们着手估算某项任务时，尽管已有超支完成类似任务的经历，仍然有低估所需工作量的趋势。通过与相似场景的统计数据进行对比，可以改善这种情况。计划扑克™的鼓励不同的参与者独立估算工作量，并以达成一致为目标。
UPerform的计划扑克™（Planning Poker）是一种基于共识的估算方法和讨论工具。每副内有4套序列可供4个人使用。每套序列由说明卡、0、½、1、2、3、5、8、13、20、40、∞、?，共13张牌组成。

计划扑克™玩法：

1. 游戏参与者每人各持一套序列，包含不同的数字和符号。
2. 主持人引导大家共同选定 1 个相对简单的任务作为基准。
3. 接下来，主持人从待估算任务中挑选 1 个，并解释其内容，以供大家讨论。
4. 每个游戏参与者围绕待估算任务进行讨论，并提出问题。然后每个人按自己的理解，将待估算任务与基准5. 任务进行对比来估计完成这个任务所需的相对工作量，并从自己手中的牌里私下选择 1 张合适的数字。注意，数字是相对值，并无任何单位。
5. 所有人一起亮牌展示给大家。如果大家亮出的牌比较接近，就以此点数作为估算值。如果相差悬殊较大， 各位参加者需要讨论各自的估算理由。可以从亮出数字最大和最小的参与者开始。
6. 根据每个游戏参与者的解释，可以重新估算并再次出牌，直到大家达成一致。
7. 重复步骤3~6。

ps：计划扑克™是优普丰咨询顾问机构(www.uperform.cn)的注册商标。本产品在淘宝由shiningstudio店铺代理。

敏捷的工作模式强调个体及团队的互动和频密交流，为了及早反馈和频密交付。但这对于分布在不同办公室甚至不同国家的团队成员带来不小的沟通和合作方面的挑战，很多人会觉得沟通的负担超重，或者浪费无谓的等待时间。基于我们的经验，如何应对其实也没有什么大秘密，只要遵循以下一些原则和策略，就能减少分布式的合作之痛，同时确保良好的敏捷交付效果。

Read More