正规的软件开发过程太烦琐，我们真的需要一个简单高效一点的开发模式，比如XP和Agile。至于什么是XP和Agile，我以为关键都是要充分发挥开发人员的主观能动性，而不仅仅把其当作一颗螺丝钉。

自从上次安装了一个 Mingle的测试版， 就觉得这就是我想像中的Agile项目管理工具，相比之下MS Project太过于烦琐！Mingle最让我喜欢的地方就是Use Story和Release Iteration的管理。因为相比那几十页的软件规格需求文档，Use Story就显得很简洁明了，也容易量化和跟踪。同样，可以在Release Iteration里自由拖放安排Use Stroy也是很方便的，比Project的甘特图什么好多了。软件开发还是没有达到其它行业的成熟程度，无法准确的估量工作量到人日。但是Mingle的运行速度太慢，启动后我的T43就动不了了。不知道正式版会不会快一点，还没有时间试用呢。

今天收到了一封Mingle的新闻邮件，点击附带的链接来到了 Agile Journal，发现真是一个好地方。正好有空，就随便浏览了起来。

Balancing Skills For Agile Team Success

一个开发团队里有些人精通业务，有些人则精通技术，相互之间就会产生意见分歧。因此，你需要提拔那些既懂业务又懂技术的队员来充当仲裁者（Tie-Breaker）。敏捷开发，最忌讳的就是自以为是。

FEATURED BOOK: Continuous Integration: Improving Software Quality and Reducing Risk

Martin Fowler也推荐了《持续集成》这本书，主要是讲CruiseControl和xUnit等工具的使用。持续集成在敏捷开发里占有很重要的地位，当年看《微软的秘密》就知道MS是靠强大的Build机器战胜对手的。CruiseControl我们也用了两年，感觉很好。但是如何跟xUnit等工具结合使用，那还真得看一看这本书。

Make it Fun,Make it Agile

在大企业里做软件开发越来越没有意思了，高手们都跑去了Web2.0公司了。不要让繁琐的计划和官僚压抑了开发人员的热情，如何让开发变得有趣？关键还是要把工作交到开发人员的手里，要对其信任放手让他们去做。要让他们真正喜爱自己的工作，并为其工作成果感到自豪。

Behavior Driven Development -- An Evolution in Testing

测试，就是完成后再去校验，这并不符合TDD的精神。TDD其实倡导先写测试用例，再开发。写测试用例的时候，你就要设想对象的外部行为，实际上就是在做设计了。TDD测试的其实不是单个的方法，而是设计了一个应用场景。从这一点上来说，现有的IDE为类的每个方法，甚至包括私有方法，自动生成测试用例其实不是一个好的习惯。因为私有方法并不对外表现，而且隔立的看待每一个方法其实是没有多大意义的。所以，作者提出了“行为驱动开发（BDD）”，通过应用场景来描述和校验对象的对外行为。最好能把test这个字眼给换成更自然的描述，并举了一个rSpec的例子（再次让我们见证了Ruby的灵活语法，使得 DSL变得简单）。你也可以在现有的xUnit框架上使用BDD的思想，只要把测试用例的类和函数名起得有意义一点，比如 test_shouldHaveOneElementWhenAddedTo()。

没错，太同意作者的观点了。

Challenging Why (Not If) Scrum Works

在告诉别人如何做之前，你最好能让他相信为什么这样做是好的。有信心，才会有勇气克服困难坚持到底。Scrum开发模式为什么得到大家的青睐呢，是什么使得它能够成功呢？

Structured Flexibility: Creating Sustainable Large-Scale Agile Adoption 如何大规模的应用敏捷的开发模式，特别是如何在大项目里还能保持软件的随时可用状态。Build Pipeline把持续构建的过程分为了编译，单元测试，功能测试以及非功能测试几个阶段。只有在前一个阶段通过之后，才能进入下一个阶段，这样开发人员就可以得到快速的反馈而不是要等到所有的测试都结束，从而大大的加快了发布的速度。在小团队里使用小纸片和Excel表格来管理Use Stroy的方式，在大项目里也不适用了，我们需要更好的ALM工具，比如Mingle。 原文链接：https://www.f2er.com/javaschema/288153.html