敏捷方法和实现（一）

序

从现在开始，我将发表一系列关于敏捷开发的博客。这些博客都是我译自《professional codeigniter》一书中的第二章的内容，他的第二章的标题是“敏捷方法和实现”，在书中作者以一个跟用户面对面访谈的分析人员的身份，来阐述敏捷方法在实践中的实施过程。作者的思维足够敏捷，书中访谈人员面对的只是一家零售店的老板，当然这位老板没有什么技术背景，但是访谈人员却能以最直观的方式——画草图——跟自己的顾客来交流，两者合作的非常愉快。通过两者的合作，访谈人员得到了需求并且形成了设计的雏形，而顾客也把自己想表达的意思原原本本的和盘托出，这不正是我们想要的结果吗？

很抱歉的是本人的英文水平实在是半斤八两，可能还是对大家有误导。只好小心翼翼的翻译，顺便把原文给出，翻译的不对的地方还请包涵。啰嗦了这么多，我们还是一睹为快吧。

 

通过我们对MVC和codeigniter的初步预览，现在先稍微兜个圈子。不用担心，并不是让你去兜风，这个圈子只是展示一下一些非常重要的基础知识。话句话说，本章的目的是让你能够把你所学的MVC和敏捷方法结合起来。理解MVC和敏捷并且将这些知识和Codeigniter有机结合将会使你的编程更加快捷。

什么是敏捷开发？

对于敏捷开发存在很多定义，有的肤浅的，有的专断，有的过于钻牛角尖。并不是每个定义都是有用的，也并不是每个定义都真正适用于你的软件开发工作。当你发现各种敏捷方法的存在时，情况会变的更加复杂，他们只会扰乱你的注意力。在一天结束时，最重要的事情是要记住：敏捷的开发的基本概念是这样的，它试图在短期内最大限度地降低软件开发的风险。一个典型的迭代可能持续1至4周，在这期间，一个软件团队执行一个完整的项目周期（规划、设计、任务编码、测试、文档）。每个迭代以需求分析开始，到潜在的开交付的软件结束。敏捷方法的另一个重要的方面是，团队自我管理和于相关机构和其他团队成员沟通的能力。

如果你对敏捷开发不是很熟悉，可能会有以下两种感觉：

❑     他跟牛仔的编程（http://en.wikipedia.org/wiki/Cowboy_coding）的区别是什么？敏捷方法听上去就像我曾经经历过的修复混乱代码的工程。

❑     怎样使任何人在这么短的时间内作出所有事情呢？敏捷方法听上去像我们曾经烧掉的仓鼠轮。

 

 

首先，如果你对第一次使用敏捷方法感到疑问，那么欢迎加入俱乐部。请放心，任何一个将敏捷开发的研究付诸实现的人都会将它掌握。

其次，许多人开始时错误的将敏捷开发等同于某种形式的“轻量级”（和某些类似瀑布的重量级的模型相反）或者无计划的（这也助长了敏捷开发者是无章法的错误观点）。

正确的看待敏捷开发的说法应该是，整个过程是具有适应性的，而不是预测性的。例如，假设你想用瀑布模型开始招手一项工程，你可能要花费大量的时间来确定进度、资源、需求、截止日期、重要事件等等。如果其中任何一件事情发生变化，你必须返回去重新定义你的初始化输入。这非常像前往拉斯维加斯的一路上的进行了详细的准备（包括在哪停下来休息，在每个加油站应该加多少油，准备什么样的食物），但是却在城市郊区遇到一场暴风雨，不得不回家稍后再试。

利用敏捷方法指导的去拉斯维加斯的旅行就不一样了。这个过程将首先关注拉斯维加斯的赌博，然后稍微花费点功夫去发动汽车。每个人都是带上她或他的购买快餐和汽油的钱。一旦上了路，旅客可以自由地利用各种机会。可能一些人在他们离开的城市的郊区见识过赌场，然后他们打算去那里赌博。总之，目标是为了赌博，是吗？正是这种适应性的想法给了敏捷方法已力量和灵活性。

第三，许多外行对于敏捷开发的短周期鸡蛋里挑骨头。他们不相信一个高质量的软件可以在一至两星期内开发出来。正常情况下，这种主张是正确的，但是必须在拥有正确工具的前提下（例如，codeigniter还有其他的MVC框架，尤其是那些专注于通过配置文件控制约定的），你可以在数小时内完成通常需要数天或者数个星期内完成的事情。大多数人没有停下来考虑一下，大量的时间消耗在非编码的任务。开发者趋向于忘记一些不愉快的时间都浪费在会议，不停地做计划和分析，还有一直在做的测试。在一个典型的工程中，一个开发者可能会在一天中花费2至3小时编程，剩余的时间花费在会议、调试、文档编写或者钻研一个棘手问题。如果她幸运的话！另一方面，有这种可能，通过使用正确的工具和方法，可以在短周期内开发一个有新功能的软件。它带来的结果是一个可以运行的软件、高兴的顾客，还有就是开发者有一种工作的满足感。那么怎样做的更好呢？

这就是敏捷方法为什么是一个好主意的答案吗？当然：当你在一个地方拥有一个小型团队、一群有经验的开发者、经常变换的工作环境，并且拥有一种不存在从上至下发号施令的机构的文化，那么敏捷方法就会工作的相当完美。换句话说，如果试图给军方开发一个巨型武器的软件平台，牵涉到分布在3个分离地理位置的1000位开发者，那么对于任何敏捷方法来说都找不到一个很好的解决方案。

 

 

也就是说，你的普通web程序将会很容易在遵守敏捷方法的前提下构建。他跟具体的程序形式无关：不管是博客、新闻列表工具、内容管理、购物车，还是门户内容。如果你可以保持队伍开发者在20人以下（或者12人，更好些）并且使他们勾通顺畅，那么你可以获得成功。

Post-Agilism

任何一个成功的活动都将会有一些成员最终转向其他的一些事情。对于敏捷开发来说，就是“发布敏捷”。什么叫发布敏捷呢？它是由一群松散的开发者组成的工作组和其他在敏捷方法上有经验但是现在却转向其他领域的IT专家组成的。

最贴切的发布敏捷的定义（如果他们允许给自己贴上这种标签，甚至这是可以争取的）在作为“敏捷”（agile，定义为社会上的或者经济圈上的自适应）和作为“敏捷”（Agile，依存于规矩、教条或者继承自一个具体的敏捷方法，像Scrum或者XP）做出了细致的区分。他当然可以成为“敏捷”，但并不需要成为任何一个具体敏捷方法的象征。

当然，我们这里使用“agile”和“Agile”的方式仅仅是为了区分概念。在敏捷方法团体和本书中，“Agile”仅仅是你看到的文字的形式。在“Agile”和“agile”之间并没有本质区别。

 

另外一个重大的错误观点由发布敏捷者提出（重复一下，请原谅广泛的使用标签），认为敏捷运动曾经将瀑布方法排挤出行业，每个人都对这种糟糕的预测熟悉不过。现在他们发现，每个人都试图遵守《敏捷宣言》（Agile Manifest，还有其他标准文档）把他们作为一种圣经，把起先讨论的问题变成了固守信条。

需要说清楚的是，任何时候本书提及的敏捷（“Agile”），他的精髓在那个小写的a，敏捷（“agile”）。对你和开发者来说，处事灵活并且成功的完成任务要比死扣某个方法要强得多。

资料/扩展阅读

Robert Wysocki有两本介绍敏捷开发信息和实例的书：

《高效项目管理》：传统的、灵活的、对适应性项目框架和极限项目管理（对传统项目管理方法的补充）的灵活处理。他的另一本书，《高效软件项目管理》，包含了大量的信息。第四章讲到了基于软件周期的项目管理的策略，包括瀑布方法、Scrum、Rational统一过程、动态系统开发等。第五部分讲到了适应性项目框架和其他适应性的开发策略。第六部分讲到了“激励”和灵活模型极限策略。如果你想了解关于敏捷开发的更多的信息，Wysocki的书提供了丰富的信息。应外一个了解信息的地方是登陆www.agilealliance.com 和www.agilemanifesto.org。

 

 

 

With our preliminary overview of MVC and CodeIgniter complete, let’s take a slight detour. Don’t

worry, you’re not being taken on a joyride; this detour lays some pretty important foundational

blocks. In other words, the goal of this chapter is for you to be able to marry what you’ve learned

about MVC with Agile methodologies. Knowing about MVC and Agile and combining that

knowledge with CodeIgniter allow you to build applications very quickly.

 

 

 What Is Agile?

 A lot of different definitions for Agile exist, ranging from the superficial to the authoritative and

pedantic. Not every definition is useful, nor is every definition really applicable to your job as a

software developer. Things only get more confusing once you realize that various Agile

methodologies exist, all of them competing for your attention.

 

 At the end of the day, the most important thing to remember is this: Agile software development is

a conceptual framework that seeks to minimize risk by developing software in short amounts of

time. A typical iteration can last 1 to 4 weeks, during which time a software team performs tasks

from a complete project life cycle (planning, design, coding, testing, documentation). Each iteration

usually starts with stories (what Agile calls  requirements ) and culminates in potentially shippable

software. Another important aspect of Agile is the team’s ability to self-organize as they

communicate face-to-face with stakeholders and other team members.

 

 If you’re not familiar with Agile, you probably have one of two reactions:

 

 “How is this different from cowboy coding? Agile sounds just like every chaotic code-and-

 fix project I’ve ever been part of.”

 “How does anyone get anything done in so short a time? Agile sounds like a perpetual

hamster wheel where everyone burns out.”

 

 

 First of all, if you have doubts when you first encounter Agile, welcome to the club. Rest assured that

everyone who takes a closer look and sees Agile in action usually crosses over.

 

 Second, many people out there made the initial mistake of distinguishing Agile methodologies as

somehow  “lightweight” (as opposed to the heavyweight models like waterfall) or  “unplanned” (which

inspires the mistaken belief that Agile developers are undisciplined).

 

 A better way to look at Agile is to say that the entire process is  adaptive  instead of predictive. For

example, if you were to start a project using waterfall methods, you would spend a lot of time trying to

nail down schedules, resources, requirements, deadlines, milestones, and the like. If anything changes,

you have to go back and reevaluate your initial inputs. It’s very much like planning a road trip to Las

Vegas down to the last detail (including where you would make rest stops, how much gas you would

buy at each gas station, what sandwiches to pack) but then encountering a sandstorm right at the edge of

the city and having to turn back home to try again later.

 

 An Agile road trip to Vegas would be different. The process would start with a focus on gambling in

Vegas, and then a minimal amount of work would be done to get the car ready and rolling. Everyone

would bring his or her own snacks and gas money. Once on the road, travelers are free to take advantage

of opportunities. Perhaps someone sees a casino just outside the town they left from, and the group

decides to gamble there. After all, the goal is to gamble, right? It’s this kind of adaptive thinking that

gives Agile its power and flexibility.

 

 Third, many outsiders have a bone to pick over the short iterations in Agile. They can’t conceive that

quality software can be developed in a week or two. Normally, this assertion would be true, but with the

right tools (i.e., CodeIgniter and other MVC frameworks, especially those that focus on delivering

convention-over -configuration benefits), you can achieve in hours what normally would take days or

weeks. Most people don’t stop to consider that an enormous amount of overhead time is devoted to non-

 programming tasks. Developers tend to forget the painful hours spent in meetings, all the hours devoted

to planning and analysis, and all the time spent debugging. On a typical project, a developer might

spend 2 to 3 hours a day programming and the rest in meetings, debugging, documenting, or

researching a tough problem. If she’s lucky! On the other hand, it is possible, with the right tools and the

right methodologies, to create shippable software in very short iterations. The result is working software,

happy customers, and developers with a sense of job satisfaction. What could be better?

 

 Are there places where Agile is not a good idea? Of course: Agile works best when you have smaller

teams in one location, more experienced developers, quickly changing environments, and a culture that

is not exclusively driven by top-down command and control structures. In other words, trying to build a

giant weapons software platform for the Army that involves 1,000 developers in three geographically

separate locations would probably not make a good case study for any Agile methodology.

 

 That being said, your average web application can easily be built following Agile. It doesn’t matter what

kind of application: blog, newsletter tool, content management, shopping cart, or content portal. If you

can keep the team under 20 developers (or better yet, a dozen) and keep them communicating well,

you can pull it off.

 

 Any successful movement will have some members who eventually move on to something else. In the

case of Agile methodologies, there is Post-Agilism. What is Post-Agilism? It’s a loose group of

developers and other IT professionals who have experience with Agile but have now moved on to other

approaches.

 

 The most thoughtful Post-Agilists (if they would allow themselves to be labeled as such, and even that is

up for grabs) make a fine distinction between being  “agile” (defined as being adaptive in a social or

commercial circumstance) and being  “Agile” (living by the rules, dogma, or inherited wisdom of a

particular Agile methodology, like Scrum or XP). It’s therefore possible to be  “agile” without necessarily

having to take on all the trappings of any particular Agile approach.

 

 Of course, the way I am using  “agile” and  “Agile” here is merely to differentiate the concepts. Within

the Agile community and throughout this book,  “Agile” is the way you see the word presented. There is

no formal distinction between  “Agile” and  “agile.”

 

 Another extremely valid concern brought up by Post-Agilists (again, please forgive the use of broad

labels) is that the Agile movement was once about shaking the industry out of the waterfall

methodology, the predictive mess to which everyone was so well accustomed. Now they feel that

everyone is trying to follow the  Agile Manifesto  (and other touchstone documents) as some kind of

canonical bible, replacing the earlier problem with a newer adherence-to-dogma problem.

 

 To be clear, any time that  “Agile” is mentioned in this book, it is in the spirit of little-“a”  “agile.” It is

more important for you, the developer, to be adaptive and successfully complete a project than to adhere

strictly to the rules of a certain methodology.

 

Resources/Further Reading

Robert Wysocki has two books that include information on and examples of Agile methodologies:

Effective Project Management: Traditional, Adaptive, Extreme deals with the Adaptive Project

 Framework and Extreme Project Management (in addition to traditional project management methods).

His other book, Effective Software Project Management, covers a lot of information. Part IV covers

the evolutionary development waterfall method, Scrum, Rational Unified Process, and Dynamic Sys-

tems Development as iterative software development project management strategies. Part V covers the

 Adaptive Project Framework and other adaptive software development strategies. Part VI covers

INSPIRE and flexible model extreme strategies. If you want more information on Agile methodologies,

Wysocki’s books offer a wealth of information. Other good places to find information are at

www.agilealliance.com and www.agilemanifesto.org.