摘要：好久没有更新结对Review的实际情况，让我们来看看团队自己的理解和总结。下述内容摘自团队成员的邮件，隐藏了敏感信息。结对Review在好几个项目（项目名称隐藏）中试点以后，在项目各阶段都进行了一些尝试，也收获了许多，其中最大的收获就是项目信息更流畅了，项目成员相互补位更容易了。很多项目组同学也想尝试一下，方便大家分享更多结对Review的经验和感受，整理了一个参考的模板提供给大家，大家可以在一定阶段后将结对Review的心得分享出来，晒一下，邮件抄送xx（人员姓名隐藏），我们可以帮助一起收集，形成知识积累。结对Review的核心价值：通过分享和互通让结对Review成为习惯，成为形成知识库的
阅读全文
摘要：龙年即将到来，先预祝大家新年快乐，龙年大吉！在新年来临之际，也许下自己的新年心愿，2012年将写一本敏捷软件开发方面的书，至少也是电子书吧，以帮助更多的人认识敏捷和玩转软件开发。暂定书名为《用敏捷玩转软件开发》。如果你有更好的建议，欢迎提出。其实是否玩转敏捷并不是那么重要，真正重要的是如何玩转软件开发。作为一个软件开发实践者，我的职业生涯一直与软件开发相连，一直在思考和实践各种软件开发方法，希望不断取得软件开发的成功。本书的目标是借机总结自己软件开发的认识和经验，以帮助自己和他人在软件开发的路上越走越好。2011年9月在北京与@Thinker姜志辉和@我是晴耕雨读聊到，国内现在已经有大批的10
阅读全文
摘要：程序员A碰到了程序员B。“Scrum糟透了”程序员A说。“为什么啊？听说Scrum很好啊，我们公司也在准备实施Scrum。”程序员B回答。“千万别，你们会后悔的。”“你们实施的是真正的Scrum吗？”“当然，Scrum里面的3个角色、4个会议和3个产物我们都有啊。”敏捷非常简单，却又极其困难。敏捷方法学由一系列敏捷实践组成，而当人们实施敏捷的时候，却急于一次性实施整个方法学。他们看重敏捷实践简单的形式，却不了解或者不想花费心思了解任何一个敏捷实践背后的内涵，从而导致没有一个敏捷实践能够做到位，不能享受到对应的好处。最后却发现投入那么大，期望那么高，收获却那么少。敏捷实施带来的只是无穷无尽的伤痛
阅读全文
摘要：随着敏捷日益成为主流，各种各样的敏捷会议召开，一本又一本的敏捷图书出版，一个又一个的公司前赴后继的迈向敏捷，好一番火热景象。这让我回忆起了当年看报时的一个感受，当时每张报纸的显眼处都能看到牛皮癣和肝病的广告，咋一看感觉会治病的人很多，仔细思考下才发觉是根本原因是能治好病的人很少，否则市场上不会那么热闹。敏捷的现状是不是也是如此呢？“与其做敏捷，不如变敏捷！Be agile rather than do agile.”但对于大多数公司来讲，如果没做过敏捷，怎么知道如何变敏捷。而且做敏捷可以检查和测量，变敏捷则不能，这违背了“不能被测量则不能被管理”的管理定律。但大多数敏捷实施会失败！那些被敏捷后
阅读全文
摘要：一天，程序员甲遇到了程序员乙。程序员甲就问程序员乙了，“听说你们公司也在搞敏捷？”程序员乙答：“是啊，别提了，纠结着呢。感觉现在加班比以前还多了，一个迭代接着一个，比以前累多了。你们公司呢？”“我们啊，现在不怎么提敏捷了。敏捷这一套东西在我们这里不好用。” 上述对话并非个案。对大多数人而言，敏捷实施给他们带来的更多是痛苦，而不是成功，而且即使是成功，大多也与他本人无关。所以一方面来讲，敏捷越来越火热，敏捷大会上人潮汹涌，另一方面，又有很多的声音在声讨敏捷，包含那些在敏捷上栽了跟头吃了亏的。 如何才能形容很多公司敏捷实施的现状呢？我苦苦思索。当“苦逼敏捷”这个概念从我脑海浮现出来的时候，...
阅读全文
摘要：每一味药都是有副作用的，每一个实践也是。通常的想法是尽量减少和避免其副作用，然而这绝非最佳做法。有些药就是因为其副作用而广为人知，例如伟哥。软件开发中各种各样的实践也都有副作用。如何降低有害的副作用，放大有益的副作用？结对Review不是一个全新的实践，而是旧有实践的包装，主要原因恰恰是因为其副作用。结对是最小的团队，在这个最小的团队中如何进行团队合作，如何促进团队学习，结对Review开了个好头。1. 实践介绍1.1 实践简介在开发人员完成一份任务后，由开发人员和团队的另一名成员坐在一起进行结对Review。Review的方式是由该开发人员来讲解他对于这个任务的理解、他的设计思路和他的实现。
阅读全文
摘要：时间过得飞快，转眼间C项目已经来到了第五个迭代。在第五个迭代，C项目的情况如何呢？答案是还在磕磕绊绊。 对很多人来说，这种敏捷实施的成果是难于接受的，实施这么久了，还在磕磕绊绊。实施敏捷看起来就像一场运动，人们总期待实施敏捷有个结束的时间，但是这就是敏捷，实际的敏捷。（敏捷不仅是马拉松，它还永不结束。） 记得以前听Scrum的讲座，敏捷的三大支柱之一就是透明性。意思就是，敏捷本身不解决问题，它能在实施过程中让问题不断的暴露出来。敏捷社区有个形象的提法，“水落石出”。 解决问题依赖于组织自身。然而对大多数组织来讲，都没有做好不断面对问题并解决问题的准备，实施敏捷磕磕绊绊甚至失败也就是意料中事了.
阅读全文
摘要：就这样，C项目组糊里糊涂的开始了敏捷之旅。在第一个迭代完成后：基本情况2011年2月21日-3月4日，项目组成员每天站在白板前进行每日站立会议。如果发现了需要讨论的话题，就在会后进行讨论。2011年3月4日，项目组进行了第一次回顾会议。没有评审会议了，因为项目组仅完成了预估工作的不到一半，仅提供了一个Demo。第一次回顾会议团队在白板前进行第一次迭代回顾，会议总耗时一个小时。会议结果如下：1. 做得好的a)成功完成Demo，所有Bug都修复了。b)每日站立会议对团队有很大帮助，可以清楚知道团队其他成员在做什么。团队协作比以前更好了。c)感谢美国团队的及时响应。d)感谢团队成员的认真负责，开发和
阅读全文
摘要：本系列将记录项目中引入敏捷的过程和相关的一些思考，欢迎进行交流。流水帐2011年2月16日前，与项目经理和开发组长进行过两次前期交流。2011年2月16日，公司领导确认对项目进行过程改进，确定由我协助项目进行改进。2011年2月17日，与中国团队的项目经理进行面谈，确定引入迭代开发模式。2011年2月18日，与中国项目团队进行第一次迭代计划会议。会议会议总耗时两个半小时。团队坐在一个白板前，使用即时贴记录Backlog的工作项和分解后的任务。主要会议内容：简要介绍迭代开发模式，确定每2周一个迭代，每天上午10：30召开每日站立会议对需求进行优先级排列，形成最简的产品Backlog团队对产品Ba
阅读全文
