homework-Agile Software Development

对敏捷开发的一些思考

    这周的作业是对敏捷开发的相关阅读和思考。

    在阅读的过程中，可以看到作者是一位具有丰富编程经验的大师。在开发的经历中，作者经历了极限编程等开发过程，但是在作者的多年经验中，作者还是给敏捷开发这样一种开发方法很高的评价：From Nothing, to Monumental, to Agile

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

1 The Key of Agile

通常敏捷开发都被认为是以代码为导向的，把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成。但是作者却并不这么认为——Lack of documentation is a symptom of two much deeper differences:

1 adaptive rather than predictive：在开发过程中，开发者会对软件做出事无巨细的规划，而这些规划也将限制软件功能的走向，保证开发在自己预测的路线内发展。因此，开发的过程更多是对自己计划的适应，而不是一种预测。

2  people-oriented rather than process-oriented：敏捷开发在开发过程中以程序员为中心，这样更适合程序的开发。

在接下来的文章中作者详细的论述了上述两点：

1 adaptive rather than predictive

首先作者提出了客户需求的不可预知性。这点在大多数软件开发者看来的确是一件非常让人头痛的事情，但是在作者看来这是一件非常普通的事。因为In building business software requirements changes are the norm, the question is what we do about it。这句话，在我看来不免觉得有些头痛，因为，即使是作为一名学生，我也可以想象到开发软件时候面对用户每天变化的需求的烦恼。但是，软件开发者就是为了满足用户的需求而进行软件开发的，用户的需求变化是一件非常正常的事情，而我们能做到的就是满足用户。这说起来义不容辞，但是做起来的时候却是一件非常痛苦的事情。但是，we have to。

这是因为用户需求的变化，开发过程的可预知性在作者看来是很难做到的，但是，这也不是说我们完全不能控制，“Instead you need a process that can give you control over an unpredictability”。

所以，作者在此提出了一种可以适合这种不可预知性的开发方式——iteration，迭代开发。

在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。通过这种方式，开发者能够降低风险，得到早期用户反馈，从而进行持续的测试和集成，使用变更，也提高了代码的复用性。

2 people-oriented rather than process-oriented

这里的people-oriented指的是programmers，开发人员。开发人员一般都是能力极强的人能够胜任这项工作。但是在选取开发人员时候对开发人员的责任心要有一定的要求。

这样的一支团队无疑是优秀而且强大的团队，在管理方面就更需要注意一些技巧以使这些开发人员能够互相配合。这需要做到两点：一，适应工程的进度而不是随意加快进度。二，开发人员能够做出一定的决策而不是只是评估。

2 Flavors of Agile（敏捷开发的不同风格）

    接下来作者叙述了敏捷开发中的一些方法。事实上，“敏捷”这个词是指软件开发的一种理念。很多方法都可以归入敏捷型旗下，如极限程序设计（XP），Scrum，精悍开发（Lean Development）等等。每种方法都有自己特定的思路、社群和领军人物。

1 极限编程XP

    极限编程具有更多的知名度，因而也具有更为成熟的开发模式。极限编程将敏捷开发的一些理论和实际的技术做到了很好的结合，因此，在敏捷开发起初还被人们质疑的时候，极限编程这样一种开发方式证明了敏捷开发的可行性。

2 Scrum

    scrum更多的强调的是管理。它将软件开发过程分成一个30天的冲刺阶段，在每一次冲刺开发团队创建可用的（可以随时推出）软件的一个增量。

3 Crystal

    Crystal根据项目规模和项目的重要性来区别项目,并赋以相应的方法,所以,crystal是方法的组合。相对于其它敏捷方法,Crystal强调软件开发流程的纪律性,所以,它比其它敏捷方法易于使用,但它的生产率不如XP等其它敏捷方法。

 

4 Context Driven Testing

    测试人员需要积极发挥主观能动性，而不是墨守成规的遵守一些通用的规定和流程。总之，这是一种为以人为本的测试方法论，强调主观能动性，而不是固定的流程和方法。

5 Lean Development

    Lean movement（精悍生产运动）是由丰田公司（Toyta）Taiichi Ohno首创，并以 丰田生产系统（Toyota Production System）著称。Lean Development有如下原则：

消除浪费，增强学习，尽量延迟决定，尽快发布。但是作者却对此并不是十分赞成：indeed the engineering separation between design and construction got us into this mess in the first place.（工程领域中把设计和建造相分离这种 思想首先导致了软件开发中的混乱）

6 (Rational) Unified Process

    RUP是一个非常大的实践指引的集合。它实际上是个过程框架，而非一个 单一过程。它寻求的是提供一组软件开发共有的实践指引，让开发团队来从中 选择以为一个具体的项目所用。RUP最主要的特征是用例驱动开发（Use Case Driven）（即，开发是以用户可见 的系统功能特征来驱动的），迭代，和以架构为中心（需要优先考虑的一点是， 尽早设计出一个架构以贯穿项目始终）。

    RUP存在着一个非常明显的缺点就是： infinite variability，极度的灵活性。作者在文中描述，他曾看到有些团队RUP应用为传统的瀑布式开发过程，也曾看到有些团队将RUP应用为类似于敏捷开发。从而完全失去了RUP本身的特点。

3 Should you go agile?

    敏捷开发没有非常长的历史，因此，敏捷开发也发展的并不像瀑布式开发，迭代开发等开发方式那么成熟。因此，敏捷开发仍然需要很多人的实践，运用和总结。

    因为敏捷开发是people-oriented 而不是 process-oriented，敏捷开发对于开发团队具有一定的要求。例如，开发人员应该具有比较丰富的经验，对项目也有一定的了解。而且开发过程中开发人员也应该保持一定的联系，这要求开发团队的凝聚力。因此，有很多人都建议，大型开发团队不要用敏捷开发。不过，作者在文中表示，他曾参加过一个100多人的项目，应用的敏捷开发也取得了一定的成绩。所以可以总结，敏捷开发的适应性还是具有很大的空间的。不过，这都取决于参与开发的人员的综合素质。如果是刚刚接触敏捷开发的初学者，那还是从小型项目着手，慢慢学习。

 

4 对于敏捷开发的思考

    敏捷开发的一大特点就是“敏捷”，因为它相比于重型方法，步骤要少得多。因此，对于一个比较重视过程的团队可以考虑敏捷开发。因为马上要面临软件工程的团队作业，我们团队的人员分工已经确认，等到真正着手开发的时候，我们只有八周的时间。我觉得，我们可以考虑将敏捷开发应用于真正的开发过程中。

敏捷开发有很多方法，通过阅读文献，我个人觉得，我们小组可以考虑使用XP极限编程的方法。具体原因如下：

    在查询资料的过程中，我发现水晶（Crystal）系列，相关环境驱动测试（Context Driven Testing），（理性）统一开发可以查到的资料相对于文中提到的其他三种方法比较少，而我们又是敏捷开发的初学者，必须需要很多的资料的支持，而这种的状况无疑不适合我们的情况。

    Scrum具有较长的迭代周期，而且在开发过程中每天都会开一个15分钟的组会，在查询资料的过程中可以看到有些程序员并不适应这样的高强度的开发方式。认为这种方式对开发人员心理承受力和压力的承受力有一定的要求，而且我们平时还有其他的课程，并不是全部用来忙软件工程。所以这种方式并不适合我们。

    而XP在各种方法中，具有最高的评价和最成熟的理论。可供我们学习的资料很多，而且注重测试这种思想我们也是非常支持。所以，综合以上考虑，我个人认为，在接下来的团队作业中，我们可以考虑XP。