Agile Software Development
I. Agile Software Development
Agile software developmentis a group ofsoftware development methodsbased oniterative and incremental development, where requirements and solutions evolve through collaboration betweenself-organizing,cross-functional teams.It promotes adaptive planning, evolutionary development and delivery, atime-boxediterative approach, and encourages rapid and flexible response to change.It is a conceptual framework that promotes foreseen interactions throughout the development cycle.TheAgile Manifesto[introduced the term in 2001.(Wiki, 21 Aug 12)Let’s take this definition apart.
a. Software Development Method
Asoftware development methodologyorsystem development methodologyinsoftware engineeringis a framework that is used to structure, plan, and control the process of developing aninformationsystem.
b. Software Engineering / Software Development
Software Engineering(WIKI) (SE) is the application of a systematic, disciplined, quantifiable approach to the design, development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.Software Development,a much used and more generic term, does not necessarily subsume the engineering paradigm.The field's future looks bright according to Money Magazine and Salary.com, which rated "software engineer" as the best job in the United States in 2006.In 2012, software engineering was again ranked as the best job in the United States, this time by CareerCast.com.
c. Information System
Aninformation system(IS) - is any combination of information technology and people's activities that support operations, management and decision making.In a very broad sense, the term information system is frequently used to refer to theinteractionbetween people, processes, data and technology.In this sense, the term is used to refernot onlyto the information and communication technology (ICT) that an organization uses,but alsoto the way in which people interact with this technology in support of business processes. (Wiki)
d. Iterative and Incremental Development
Iterative and Incremental development is at the heart of a cyclic software development process developed in response to the weaknesses of the waterfall model.It starts with an initial planning and ends with deployment with the cyclic interactions in between.Iterative and incremental development are essential parts of the Rational Unified Process, Extreme Programming and generally the various agile software development frameworks.It follows a similar process to the “plan-do-check-act” cycle ofbusiness process improvement.
e. Time-Boxed Approach
Intime management, atime boxallots a fixed period oftimefor an activity.Timeboxingplansactivity byallocatingtime boxes.
Fears regarding software development led to a number of pioneers / industry experts to develop theAgileManifestobased up some firm values and principles.Practitioners had become afraid that repeated software failures could not be stopped without some kind ofguiding processto guide development activities.
Practitioners were afraid thatThe project will produce the wrong productThe project will produce a product of inferior qualityThe project will be lateWe’ll have to work 80 hour weeksWe’ll have to break commitmentsWe won’t be having fun.
These individuals, calledThe Agile Alliance, were thus motivated to constrain activities such that certain outputs and artifacts are predictably produced.Based on their experiences around 2000, these notables got together to address common development problems.It was their goal to outline the values and principles that would allow software teams to develop quickly and respond to change.These activities arose in large part to runaway processes.Failure to achieve certain goals was met with ‘more process.’ Schedules slipped; budgets bloated, and processes became even larger.The Alliance (17) created a statement ofvalues, which has been termed themanifestoof the Agile Alliance.They then developed the 12Principles of Agility.
Manifesto for Agile Software Development
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to the value:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.”Let’s look at these values to discern exactly what is meant.
Value 1: Individuals and Interactions over Processes and Tools
Strong players are a must, but strong players can fail if they don’t work together.Strong player: not necessarily an ‘ace;’ working well with others! Communication and interacting is more important than raw talent.The ‘right’ tools are vital to smooth functioning of a team.Start small. Find a free tool and use until you can demo you’ve outgrown it. Don’t assume bigger is better. Start with white board; flat files before going to a huge database.Building a team is more important than building the environment.Some managers build the environment and expect the team to fall together. Doesn’t work. Let the team build the environment on the basis of need.
Value 2: Working Software over Comprehensive Documentation
Code – not ideal medium for communicating rationale and system structure. Team needs to produce human readable documents describing system and design decision rationale.Too much documentation is worse than too little.Take time; more to keep in sync with code; Not kept in sync? it is a lie and misleading.Short rationale and structure document.Keep this in sync; Only highest level structure in the system kept.How to train newbees if short & sweet?Work closely with them.Transfer knowledge by sitting with them; make part of team via close training and interactionTwo essential docs for transferring info to new team members: code and team.Code is the only unambiguous source of information.Team holds every-changing roadmap of systems in their heads; cannot put on paper.Best way to transfer info- interact with them.Fatal flaw: Pursue documentation instead of software:Rule: Produce no document unless its need is immediate and significant.
Value 3: Customer Collaboration over Contract Negotiation(1 of 2)
Not possible to describe software requirements up front and leave someone else to develop it within cost and on time.Customers cannot just cite needs and go awaySuccesfulprojects require customer feedback on a regular and frequent basis – and not dependent upon a contract or SOW.Customer must work closely with development team for feedback on team’s efforts.
Value 3: Customer Collaboration over ContractNegotiation(2 of 2)
Best contracts are NOT those specifying requirements, schedule and cost.Become meaningless shortly.Far better are contracts that govern the way the development team and customer will work together.Details ideally not specified in contract. Rather contracts could pay when a block passed customer’s acceptance tests.Details of the acceptance tests were not specified in the contract.With frequent deliverables and feedback, acceptance tests never an issue.Typically major changes common; whole blocks of functionality removed; others inserted.Key was intense collaboration with the customer and a contract that governed that collaboration rather than specifying the details of scope and schedule for a fixed cost.
Value4: Responding to Change over Following a Plan
Our plans and the ability to respond to changes is critical!Course of a project cannot be predicted far into the future.Too many variables; not many good ways at estimating cost.Tempting to create a PERT orGhantchart for whole project.This does Not give novice managers control.Can track individual tasks, compare to actual dates w/planned dates and react to discrepancies.But the structure of the chart will downgradeAs developers gain knowledge of the system and as customer gains knowledge about their needs, some tasks will become unnecessary; others will be discovered and will be added to ‘the list.’In short, the plan will undergo changes inshape, not just dates.
Value 4: Responding to Change over Following a Plan
Better planning strategy – make detailedlansfor the next few weeks, very rough plans for the next few months, and extremely crude plans beyond that.Need to know what we will be working on the next few weeks; roughly for the next few months; a vague idea what system will do after a year.So, we are only investing in a detailed plan for immediate tasks; once plan is made, difficult to change due to momentum and commitment.But rest of plan remains flexible. The lower resolution parts of the plan can be changed with relative ease.
Agile Principles (12)
The following principles are those that differentiate agile processes from others.
Principle 1:Our Highest Priority is to Satisfy the Customer through early and Continuous Delivery of Valuable Software
Research has indicated that a number of practices have significant impact upon quality of final system:A strong correlation between quality and early delivery of a partially functioning system.The less functional the initial delivery, the higher the quality of the final delivery.Another strong correlation exists between final quality and frequently deliveries of increasing functionality.The more frequent the deliveries, the higher the final quality.Agile processes deliver early and often. Rudimentary system first followed by systems of increasing functionality every few weeks.Customers my use these systems in production, orMay choose to review existing functionality and report on changes to be made.
Principle2:Welcome changing Requirements, even late in Development. Agile Processes harness change for the Customer’s CompetitiveAvantage.
This is a statement of attitude. The participants in an agile process are not afraidof change.Viewchanges to the requirements as good things, because they mean that the team haslearnedmore about what it will take to satisfy the market.An agile team works very hard to keep the structure of their software flexible, so that whenrequirementschange, the impact to thesystem is minimal.Moreso, the principlesof object oriented designhelpus to maintain this kind of flexibility.
Principle 3:Deliverworking software frequently, from a couple of weeks to a couple of months, witha preference to the shorter time scale.
Wedeliver working software.Deliver earlyand often.Be not content withdelivering bundles of documents, or plans.Don’tcount those as truedeliverables.Thegoal of delivering software that satisfies the customer’s needs.
Principle 4:Business People and Developers Must Work Together Daily throughout the Project.
In order for a project to be agile, there must be significant and frequentinteraction betweenthe customers, developers, and stakeholders.Anagile project is not like a fire-and-forgetweapon.Anagile project must be continuously guided.
Principle 5:Build Projects around Motivated Individuals. Give them the environment and support they need, and trust them to get the job done.
An agile project is one in which people are considered the most important factorof success.Allother factors, process, environment, management, etc., are consideredtobe secondordereffects, and are subject to change if they are having an adverseeffectupon the people.For example, if the office environment is an obstacle to the team, the officeenvironmentchanges.If certain process steps are an obstacle to the team, the process steps change.
Principle 6: The Most Efficient and Effective Method of Conveying Information to and within a Development Team is face-to-face Communications.
In an agile project, pleasetalkto each other.The primary mode of communication is conversation.Documentsmay be created, but there is no attempt to capture all project informationinwriting.Anagile project teamdoes not demandwritten specs, written plans, or written designs.They may create them if they perceive an immediate and significant need, but they are not thedefault.Thedefault is conversation.
Principle 7: Working Software is the Primary Measure of Progress
Agile projects measure their progress by measuring the amount of software thatis working.Theydon’t measure their progress in terms of the phase that they are in,or bythe volume of documentation that has been produced, or by the amount ofinfrastructure codethey have created.Theyare 30% done when 30% of thenecessary functionalityis working.
Principle 8:Agile Processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
An agile project is not run like a 50 yard dash; it is run like a marathon.Theteamdoes nottake off at full speed and try to maintain that speed for the duration.Rather they runat a fast, butsustainable, pace.Running too fast leads to burnout, shortcuts, and debacle.Agileteams pace themselves.Theydon’t allow themselves to get too tired.Theydon’t borrowtomorrow’s energyto get a bit more done today.Theywork at a rate that allows them tomaintain thehighest quality standards for the duration of the project.
Principle 9:Continuous attention to technical excellence and good design enhances agility.
High quality is the key to high speed.Theway to go fast is to keep the softwareas cleanand robust as possible.Thus, all agile team-members are committed toproducing onlythe highest quality code they can.Theydo not make messes and thentell themselvesthey’ll clean it up when they have more time.Ifthey make a mess,they cleanit up before they finish for the day.
Principle 10: Simplicity – the art of maximizing the amount of work not done – is essential.
Agile teams do not try to build the grand system in the sky.Ratherthey alwaystake thesimplest path that is consistent with their goals.Theydon’t anticipatetomorrow’s problemsand try to defend against them today.Ratherthey do the simplest andhighest qualitywork today, confident that it will be easy to change if and whentomorrows problemsarise.
Principle 11:the Best Architectures, Requirements, and Designs emerge from Self-Organizing Teams
An agile team is a self organizing team.Responsibilitiesare not handed toindividual teammembers from the outside.Responsibilitiesare communicated tothe teamas a whole, and the team determines the best way to fulfill them.Agileteam members work together on all aspects of the project.Eachis allowedinput intothe whole.Nosingle team member is responsible for the architecture, orthe requirements, or the tests, etc.Theteam shares those responsibilities and eachteam memberhas influence over them.
Principle 12:At regular Intervals, the Team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
An agile team continually adjusts its organization, rules, conventions, relationships, etc.Anagile team knows that its environment is continuously changing, andknows thatthey must change with that environment to remain agile.
The professional goal of every software engineer, and every development team, isto deliverthe highest possible value to our employers and customers.Andyet, ourprojects fail, or fail to deliver value, at a dismaying rate.Thoughwell intentioned, the upwardspiral ofprocess inflation is culpable for at least some of this failure.Theprinciples andvalues ofagile software development were formed as a way to help teams break the cycleof processinflation, and to focus on simple techniques for reaching their goals.Atthe time of this writing there were many agile processes to choose from.These includeSCRUM,Crystal,FeatureDrivenDevelopment,AdaptiveSoftwareDevelopment (ADP),and most significantly,Extreme Programming.