使用排序法对User Story进行相对估算
软件项目的估算历来是一个难题。由于软件开发活动还无法实现土建工程那种成熟度，所以也无法像做土建工程那样通过预算速查手册来评估。但是，对于一项投资来说，总要说出要投资多少吧，软件开发也要给出投资额，这就需要做估算了。本文主要讨论敏捷软件开发中的用户故事（User Story）估算。
InfoQ
InfoQ
促进软件开发领域知识与创新的传播
编辑特辑
乔梁
乔梁，十多年软件开发及项目管理经验，专注于提高软件企业提高交付能力，推广最佳实践。曾为多个大型电信企业、互联网企业提供专业的软件交付咨询服务。现任百度项目管理部高级架构师，负责百度敏捷过程改进与持续交付推广实施。译有《持续交付》。曾任Thoughtworks资深咨询师，对敏捷项目管理及持续集成有深入的理解与丰富的实践经验。
“乔梁”相关的内容
乔梁的最新专题内容
乔梁的新闻
持续集成之“Everything is code”
随着互联网的飞速发展，以及基础设施的改进，越来越多的业务被放在了“云”端。管理数千台服务器和各种应用程序的不同版本已经是一种常规事务了。那么如果管理好这些机器和代码吗？本文将介绍一些最佳实践，来帮助大家更好的完成相关的事务。
持续集成之“软件自我识别”
作为一名运维人员，是否曾经有人走过来问你这样的问题：“当前生产环境上部署的是哪个软件版本？”你是否遇到过这样的情形，即使手里拿着一个jar文件或dll文件，也无法知道它到底是哪个版本。也许你可能认为，这算不了什么，到某个管理平台上查一查部署记录就行了。然而，如果发现在生产环境的集群服务器上，不同机器上部署的同一个程序文件的大小却不相同，作为运维人员，你的心情会是什么样？
持续集成之“自动化部署”
作为软件开发人员，你是否遇到过星期日早上被运维团队的电话叫醒，让你火速赶到升级现场，解决升级故障。作为运维团队的一员，你是否有这样的经历：每当新版本升级时，你就提前就准备了夜宵，整个团队的人都为奋战通宵做好的准备。如果才能能够做到“Release, Relax”？本文也许在这方面对你有所帮助。
持续集成之“依赖管理”
所有软件在最开始时都不会很庞大，随着时间的推移，软件平台不断膨胀，各组件或模块之间的依赖变成越来越复杂。如果管理不当，就会陷入一个泥潭。在前文《分支策略(续)》中，我们讨论了多组件应用程序的持续集成策略，即：为相对独立的组件创建自己专属的代码库，然后通过现代持续集成工具进行组件间的持续集成。Joe的团队在首次发布之后，开始使用这种方式。然而，没有多久，他们就遇到了一个问题：一次提交构建所花费的时间太长。
乔梁的文章
“持续集成”也需要重构——持续集成实践在Cruise开发过程中的演进
本文是ThoughtWorks实践集锦专题系列的第五篇。作者在本文中结合Cruise团队一年多的实际历程，讲述了如何利用“回顾”和“重构”，演进持续集成实践。
M三兄弟－精益三人组
关于软件开发中应用精益原则的讨论，大部分集中在识别和消除浪费（浪费在日语中叫作：muda）。同样，精益思考的目标是消除过重的负担（过重的负担在日语中叫作：muri）和不必要的变化（不必要的变化在日语中叫作：mura）。Roman Pichler对“Ｍ三兄弟”之间的关系进行了讨论，并建议将消除过重的负担作为走上精益之路的第一步。
乔梁的视频演讲
DevOps，让持续交付成为可能
敏捷的出现打破了用户、开发和测试之间的隔阂，实现了团队的协作。而最近出现的DevOps则借鉴了敏捷思想，将敏捷原则应用于运维领域，使交付团队与运维团队建立起更紧密的合作关系。DevOps让企业能够获得更快交付高质量、高价值软件的能力，从而增强企业竞争力。本演讲通过真实案例分享，与听众一起回顾某产品团队如何从传统开发走向持续交付。我们将讨论在产品交付中如何应用DevOps原则（协作、自动化、度量和信息共享），达到快速且可靠地发布高质量的软件，同时描述过程中遇到的难题及解决方案，并进一步探讨持续交付的意义。
持续交付的魅力——百度持续集成实践经验分享
百度从2009年引入敏捷，并结合自身情况，从项目管理、需求管理为起点。随着业务的发展，对研发效率的更高要求，自2010年起，在各产品线引入持续集成实践。众所周知，在引入敏捷的过程中，与管理实践相比，技术实践更困难，阻力更大。百度在实施初期，也同样遇到了很多问题和挑战，但经过产品线与项目管理部的共同努力，带来了很好的效果。此次演讲将围绕“软件交付”这一业务目标，分享我们在这方面的经验和心得。
