Agile Software Development
As I began my journey into software development, I came across Agile manifesto. The manifesto sets out a set of guidelines for developing a sustainable application.
The four key components are as follow:
Individuals and interactions over processes and tools
Valuing people above the processes or tools is easy to understand because it is the people who respond to business needs and drive the development process. If the process or the tools drive development, the team is less responsive to change and less likely to meet customer needs. Communication is an example of the difference between valuing individuals versus process. In the case of individuals, communication is fluid and happens when a need arises. In the case of process, communication is scheduled and requires specific content.
Working Software Over Comprehensive Documentation
Traditionally, enormous amounts of time were spent on documenting the product for development and ultimate delivery. Technical specifications, technical requirements, interface design documents, test plans, documentation plans, and approvals required for each. The list was extensive and was a cause for the long delays in development. gile documents requirements as user stories, which are sufficient for a software developer to begin the task of building a new function.
Customer collaboration over contract negotiation
Negotiation is the period when the customer and the product manager work out the details of a delivery. With development models such as Waterfall, customers negotiate the requirements for the product, often in great detail, prior to any work starting. The Agile Manifesto describes a customer who is engaged and collaborates throughout the development process, making. This makes it far easier for development to meet their needs of the customer. Agile methods may include the customer at intervals for periodic demos, but a project could just as easily have an end-user as a daily part of the team and attending all meetings, ensuring the product meets the business needs of the customer.
Responding to change over following a plan
Change, traditionally, is viewed as an expense that needed to be avoided at all cost. With Agile, the shortness of an iteration means priorities can be shifted from iteration to iteration and new features can be added into the next iteration. Agile’s view is that changes always improve a project; changes provide additional value.
On top of these four key components, there are the twelve principle that dive deeper into Agile programing:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity — the art of maximizing the amount of work not done — is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
I think the Agile method can be summed up with a quote from the poem “To a Mouse”:
The best laid schemes o’ Mice an’ Men
Gang aft agley,
Simply put, one must be willing to adapt to change and not be rigid in the design of their project.
