Movatterモバイル変換

Computerscience is a young science. Computer programmers my age were trained byengineers. That training dictated how we approached softwaredevelopment for an entire generation. But now after decades of buildingsoftware to be expensive, unwanted, and unreliable we have come torealize software is different. Building software is more like creatinga work of art, it requires creativity in design and ample craftsmanshipto complete. Software remains malleable, often illogical, andincomplete forever.Agilesoftware developmentis basedon fundamental changes to what we considered essential to softwaredevelopment ten years ago.
Themost important thing to know about Agile methods or processes is thatthere is no such thing. There are only Agile teams. The processes wedescribe as Agile are environments for a team to learn how to be Agile.
Werealize the way a team works together is far moreimportant than any process. While a new process can easily improve teamproductivity by afraction, enabling your team to work effectively as a cohesive unit canimproveproductivity by several times. Of course to be eligible for such a bigimprovement you must be working at a fraction of your potential now.Unfortunately, it isn't that uncommon.
Themost brilliant programmers alive working competitively in an ego-richenvironment can’t get as much done as ordinary programmers workingcooperatively as a self disciplined and self-organizing team. You needa process whereteam empowerment and collaboration thrive to reach your full potential.
Thesecond change is making the

customer, theone who fundsthesoftware development,a valuable and essential team member. When thedead line getsclose a traditional approach to reducing scope is to let the developersdecide what will work properly and what won't. Instead let the customermake scope decisionsa little at a time throughout the project.
Whenyour customer, or domain expert worksdirectly with the development team everyone learns something new aboutthe problem.True domain expertise and experience is essential to finding a simple,elegant, correctsolution. A document can have plenty of information, but real knowledgeis hard to put on paper. Left alone programmers must assume they knoweverything they need. When asking questionsis difficultor slow the knowledge gap grows. The system will getbuilt, but it won't solve the problem like one guided by an expert on adailybasis.
Perhapsthebiggest problem with software development is changing requirements.Agile processes accept the reality of change versus the hunt forcomplete, rigid specifications. There are domains where requirementscan't change, but most projects have changing requirements. Formost projects readily accepting changes can actually cost less thanensuringrequirements will never change.
Wecanproduce working software startingwith the first week of development sowhy not show it to the customer? We can learn so much more about theproject requirements in the context of a working system. The changes weget this way are usually the most important to implement.

Agilealso means a fundamental change in how we manage ourprojects. Ifworking software is what you will deliver then measure yourprogressby how much you have right now. Wewill change our management style tobebased on getting working software done a little at a time.Thedocuments we used to create as project milestones may still beuseful, just not as a measure of progress.
Insteadof managing our activities and waiting till the project endsforsoftware, we willmanageour requirementsand demonstrate each newversion to the customer. It is a hard change to make but it opens upnew ways todevelop software.
Takea guided tour of Agile Development by following thebuttons starting here. Or continue your guided tour ofExtreme Programmingby following the buttons. Let's look at how wemanageby features next.