多么可笑的公司呀，他们是搞Scrum工具的

本文主要是介绍多么可笑的公司呀，他们是搞Scrum工具的，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

今天收到yahoo group中极限编程组（extremeprogramming@yahoogroups.com）的一封求助信，大意是：“需要自动化构建和持续集成的收益数字，好让他们的VP能让他花上一段时间专门优化他们的构建脚本，以便将时间从3、4天缩短到12个小时。因为他们的单元测试运行时间太长，而且构建经常因为单元测试的失败而失败。”

这也没什么可笑的，因为这种事在很多公司都常见，但是，当这件事发生在一个号称“敏捷”，而且是买Scrum管理工具的软件公司里，就变得有些可笑了。

不过也难怪，他们是搞Scrum的，Scrum才不管你的构建呀、单元测试呀、持续集成呀。

笑过之后，指出一些可能的bad smell和可能的对策。当然，不是指说服他们VP的对策。——哈哈哈。

做为一个开发人员，优先构建和开发新功能并不矛盾呀，是开发人员自己让事情发展成这样的呀，你为啥怪VP不给你时间呢
- 因为一直为了讨好VP，只管快速开发功能，忘记自己应该做的事情了吧——只管赶工，等债台高筑了，VP说是：“你自己欠的，自己加班还吧”
构建时间较长
- 需要看看编译和打包脚本，估计有很多浪费
- 如果是C/C++，可以使用分布式编译啊
单元测试时间太长
- 写的根本就不是单元测试
  - 可能是集成测试（比如那些talk to db, file system, network），依赖于很多基础环境，而这些环境经常有问题
  - 可能是这些集成测试本身写的不好，有很多wait(10s)，并且一个测试中有测试很多场景
- 单元测试真的很多（这个可能性不大，数千个单元测试的话，在分钟内也可以跑完呀）
  - 失败较多的话，很可能根本没有做持续集成中的基本实践（六步提交法），开发人员本地不跑单元测试
  - 没有使用并行运行策略来缩短时间

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

求助信原文：

“Can anyone point me to some real numbers on the benefits of automating the builds and continuous integration.

Perhaps there's a good white paper on this topic.

I don't need to be convinced, but trying to make a case to our VP on doing this first rather than working on new features.

We do have automated builds but the unit tests take forever to run and often times the build fails due to unit test failures.

We want to make a substantial effort to get to builds in 12 hours from 3 or 4 days.

Just hard to quantify the benefits.

Thanks
jack”