IMVU如何在实施持续部署的同时确保软件质量

本文是IMVU(一个社交网络公司)在32个月之前发表在他们的技术博客上。你可能会羡慕这种发布状态(每次代码修改在20分钟内就可以部署到生产线,而每天部署50次),以及他们如此强大的工具和基础设施。然而,你看到的只是结果,而背后却是他们坚持的理念——“持续交付、持续学习”的精益创业开发理念;以及在这一理念支持下,大量艰苦的工作。那么,这些工作都包括哪些内容呢?详情如下。

---------------------------------------

我们公司有时也会由于某个特性抢速度上线而对顾客造成一些负面影响,但是这些负面影响也是我们得到教训的一个来源。有时,我们做的特性对于顾客没有什么价值,有时也会在生产环境中引入一些回归问题或是新的缺陷。

然而,有的时候,对于我们小心翼翼做出来的一些特性,客户也并不买账——可这的确消耗了我们很多精力,因为我们要花了更多的时间来研究、学习和调整方向。举一个例子吧:我们曾用 一个月的时间开发完了一个叫做“更新”的特性——有点像Facebook的“Friend feed”(朋友新鲜事),而用户对这个特性的反应和我们预想的完全不同。这表明,我们花了很长时间却交付了一个没人要的功能,而导致的结果就是:这延迟了另一个更加重要的特性(群组特性)的交付。

Continue reading IMVU如何在实施持续部署的同时确保软件质量

剖析“持续交付”:五个核心实践

原文发表于 InformIT

持续交付 是一种软件开发策略,用于优化软件交付流程,以尽快得到高质量、有价值的软件。这种方法让你能更快地验证业务想法,通过直接在用户那里进行试验,做到快速迭代。 尽管《持续交付》一书主要讲的是工程实践,但持续交付的概念对整个产品交付过程都有重大意义,包括对特性的”fuzzy front end”、设计和分析的意义。

持续交付的一般性原则如下:

与其设计一大堆特性,再策划一个持续数月的版本发布,不如持续不断地尝试新想法,并独立发布给用户。通过充分思考,即便很大的特性或者大范围的变更,也能够通过一系列小步骤得到更快反馈,而且一旦你认为有必要停下来的话,可以随时停下来。利用 跨功能团队 在几小时或几天内交付这些小且增量式的功能,就能比竞争者有更多的创新,将投资回报最大化。

持续交付五个关键实践,为你建立一个从猜测到持续反馈的最有效途径,它们就是:

  • 从最小可行产品(MVP)开始——Start with a minimum viable product
  • 衡量新特性的价值——Measure the value of your features.
  • 做恰好充分的预先分析——Perform just enough analysis up front.
  • 少做——Do less.
  • 用户故事中要包括特性开关——Include feature toggles in your stories.

Continue reading 剖析“持续交付”:五个核心实践

围绕最终交付物,而不是角色来组织软件交付活动

——持续交付与跨功能团队

在实施持续交付的过程中,我们很容易聚焦于自动化和工具,因为作为起点,它们通常是最容易做的。然而,持续交付的成功实现,还依赖于根据最终交付物而对组织结构所做的优化。对于持续交付来说,最大的障碍是依据角色和分层结构来组织团队,而非业务上的最终交付物(即产品或服务)。

Continue reading 围绕最终交付物,而不是角色来组织软件交付活动