文章

意外终止一个sprint

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

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

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

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

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

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

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

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

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

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

成功组建敏捷团队的技巧

简介

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

敏捷方法学家Scott W. Ambler:敏捷最困难的地方是变通

敏捷的推广

 记者:能否介绍一下您目前所从事的工作以及关注的方向?

Scott: 我目前的主要工作是帮助企业理解敏捷。Disciplined Agile Delivery是我近期关注的一个方向,它主要讨论的是如何从项目启动开始,到产品成型,再到系统交付的整个软件生命周期里进行敏捷开发。其中涵盖的内容要比我们通常在主流敏捷社区中所见到的方法学还要多。像Scrum、XP 这些主流的敏捷技术都是相当不错的,但是它们并没有涉及软件开发全生命周期的方方面面。 Read more

网易有道云笔记的敏捷开发实践

网易有道笔记负责人蒋炜航谈敏捷开发的实战经验。

有道云笔记团队成立于从2010年,从成立伊始我们就一直积极地在实践中尝试Scrum(敏捷开发的一种项目管理方法)的做法。到2012年底,3.0发布时,我们在5个主要平台(PC、iPhone、Android、iPad、Web)上总共发布了46个版本,累计了近千万激活用户。在这个过程中,我们逐渐摸索出一套适合以产品和技术创新为核心的中等规模(数十人)研发团队的Scrum实践经验。 Read more

Sprint中的承诺

承诺(commitement)是Scrum所强调的核心价值观之一。也是执行Scrum时的关键概念。

有人认为,在缺少开明管理的情况下,团队的承诺将只是一种大的、自我强加的指挥棒,在每次团队未满足目标时敲打他们。还有人认为团队会走各种捷径来履行承诺,可能在必要时降低质量。 Read more

敏捷的心跳

一直以来,如何在Scrum中预测团队可以在一个Sprint交付的工作量都是一项挑战。很多人把一定的工作量定义为一个故事点来尝试建立一个基 准,而没有留意团队的实际工作方式。例如,有些团队把对一个有8个字段的数据表的CRUD操作定义为一个故事点数。这种方法实际上是行不通的,因为团队里 面的每个人都有不同的经验、专长和特质。每个团队都拥有自己的特质,每个团队完成同一项任务所需要的时间也不一样,所遇到的困难也不尽相同。总而言之,对 于一个由人类组成的团体而言,也许会有生产效率的统计标准,但是永远不会有可预测的而且精确的工业标准。这个时候,我们所面临的问题是:是制定一个计划, 然后为了合同或者公司利益按照计划勇往直前,还是先制定一个目标,然后一直跟踪团队的效率成长来不断调整项目计划,为团队创造良好而且高效的工作环境,最 终令客户满意更好? Read more

战壕里的敏捷用户界面设计和信息架构师

六年前,我是一家大型网络设计公司的技术总监,他们没能够成功应用Scrum。 当时管理当中存在相当多的障碍,尽管如此,富于创意的经理是最坚持的。起初,只是不想让架构企业软件的现实阻碍他们当时在做的图像处理 (Photoshop) 或平面设计 (Illustrator)的美好设计。自然,在开发阶段当这些人工产品与现存企业构架相碰撞的时候会有许多问题。 这种障碍导致了延期,高强度压力,低质量编码,以及每年40%的雇员流动率(和漂亮图表)。这家公司激励了我对于UX和敏捷的兴趣, 我也因此而找到做敏捷的基本方法。 迄今为止,在编程尤其是网站的所有修炼中,UX人是最坚持也最好的应用敏捷并投入实践。 Read more