意外终止一个sprint

敏捷开发讲的就是适应变化。敏捷宣言的第二条原则明确指出“欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。”这就是为什么在scrum中PO负责维护产品backlog。PO对产品backlog条目的排序有最终发言权–包括从产品backlog中挑选一组条目作为一个sprint backlog,这也是PO适应变化的一种手段。 Read more

故事点是工作量,而非复杂度

是工作量,而不是复杂度
有个客户问我,“我的团队什么时候才能完成这个项目?”我已经被问过千百次类似的敏捷项目管理问题了。
但却从来没人问过我,“开发这个项目我的团队要费多少工作量去进行思考?”
客户,老板,顾客以及干系人只会关心一个产品要耗时多久,却不会去理会要交付该产品我们得多么殚精竭虑地思考,除非这些必要性的思考会带来时间或成本风险。 Read more

故事点和小时数如何对应?

我经常被问到故事点和小时数的关系。提问者经常期待我像这样回答

“一个故事点=8.3小时”。好吧,事实并非如此(尤其是我用了8.3这个数字)。来,让我们看看敏捷故事点和小时数之间的真正关系吧。

假设因为某些原因你跟踪了一个团队一段时间,来查看他们开发的每个1个故事点的用户故事。如果你把相关数据做成图的话大概会是这个样子: Read more

在合适的时间点进行估算

虽然产品Backlog的估算很重要,但是并不是所有的团队都需要做估算。那些做估算的团队更需要了解的是为什么要做估算,而不仅仅是如何去做估算。我们估算产品Backlog主要有两个原因:

首先,估算产品backlog条目帮助PO对产品backlog进行排序。 Read more

宣布产品backlog破产

当你坐在一间教室里,正享受着敏捷培训课程(你总会不自觉地抽空查看那些不断出现的分布在众多列表中的超级紧急任务),这时你却突然听见教练嘴巴里蹦出了一些话,它听起来感觉似乎很完美同时却又那么疯狂…
这些话就是:产品backlog是一个有序列表,里面放着各种类型的待做任务(比如:特性,bug,需求调研等等)。 Read more

什么项目适合使用Scrum?

有不少刚刚了解Scrum的一些朋友经常会问到什么样的项目适合使用Scrum? 什么样的项目不适合Scrum? 针对这些朋友的一些疑惑,本文从软件项目的特点,Scrum的核心要素,思维模式,Scrum能够解决的问题这几个方面来看到底什么样的项目适合Scrum。 Read more

可工作的软件胜过面面俱到的文档

没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档,来对系统及其设计决策的依据进行描述。

然而,过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间,并且要使这些文档和代码保持同步,就要花费更多的时间。如果文档和代码之间失去同步,那么文档就会变成庞大的、复杂的谎言,会造成重大的误导。 Read more

技术债务

技术债务,是指匆忙的实现一个功能,却对现有的程序库造成了破坏(在实现的过程中污染了代码库的设计),这对于一些项目经理/客户来说就像是天书奇谈。也许他们是明白的,只是不愿意承认罢了,我估计是这样的。不管怎样,我想起来一个小故事,当下次遇到这种情况,需要向他们解释增加某些新功能的代价时,也可用讲这个故事给他们听。 Read more

成功组建敏捷团队的技巧

简介

敏捷宣言(Agile Manifesto)自 2001 年发布以来就定义了敏捷方法的核心精髓。最近,IBM 以 “规范敏捷交付” 之名提出了一组最佳实践,帮助较大型软件开发团队取得与较小型团队在过去 10 年使用敏捷技术所取得的相同成就。这不是说现有的常用敏捷方法是杂乱无章的;事实上,大部分敏捷方法都需要比传统或临时的方法更加规范和严格。但是,并不总是有处理复杂企业环境中的大型敏捷项目的指南。 Read more

敏捷计划优雅应对

想要每周都能交付一些有价值的东西,需要在哪些方面付出努力呢?通过让客户亲眼见证软件交付的正确方式,我们就会发现以前提供给客户的服务是多么徒劳无益,并且还不止一次错过了最重要的东西——定期交付可工作的软件。 Read more