Home » Articole » Articles » Computers » Web development » Values and principles of agile web development

Values and principles of agile web development

blogging-336375

Values

Agile methods advocate four core values (in parentheses, quotes Manifest):

  1. Team (“Individuals and their interactions over processes and tools”): In agile view, the team is more important than the tools (structural or control) or operating procedures. It is better to have a solid team and communicating, consisting of developers (possibly varying levels), rather than a team of experts each operating in isolation. Communication is a fundamental concept.

  2. Application (“Operational software, plus a comprehensive documentation”): It is vital that the application works. The rest, including the technical documentation is invaluable but not an end in itself. Accurate documentation is useful as a means of communication. Documentation represents a significant workload, but can nevertheless be harmful if it is outdated. It is better to comment on the code itself extensively, especially to transfer skills within the team (it goes back to the importance of communication).

  3. Collaboration (“Collaboration with customers, more than the contractual negotiation”): The client should be involved in development. One can not simply negotiate a contract at the beginning of the project, and then neglect the customer requirements. The client needs to work with the team and provide a continuous account made on the suitability of the software with expectations.

  4. Acceptance of change (“Adapting to change, rather than tracking a plan”): Initial planning and structure of the software must be flexible to allow changes in customer demand throughout the project. The first deliveries of the software will often result in change requests.

Principles

These four values are divided into 12 general principles common to all agiles methods:

  1. The highest priority is to satisfy the customer quickly and consistently delivering value-added features.

  2. The change is accepted, even late in development, because agile processes harness the change as a competitive advantage for the customer.

  3. Delivery applies to a functional, every two weeks to two months, with a preference for the shorter period.

  4. The business and developers must work together regularly, preferably daily, to the project.

  5. The project must involve motivated people. Give them the environment and support they need, and trust them in meeting the objectives.

  6. The most effective method of conveying information is a conversation face to face.

  7. The unit of measurement of the progress of the project is a functional software (which excludes accounting functions not formally completed).

  8. Agile processes promote sustainable pace of development (to avoid non-quality resulting from fatigue).

  9. Agile processes recommend continued commitment to technical excellence and good design attention.

  10. The simplicity and the art of minimizing unwanted spots are applied as essential principles.

  11. Teams self-organize in order to bring out the best architectures, requirements and designs.

  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its work processes accordingly.

A qualified agile method must consist of a set of practices instrumenting the framework described by the 12 general principles agile and therefore register in compliance with the four core values that inspired the Agile Manifesto.

Operational structure and practices of agile development

The first Agile method, the RAD, since its inception in 1991, advocated the formation of a special development team. This team is independent, specially trained, motivated and equipped specifically. It basically consists of a unique profile of designers-developers trained in additional technical specialties. The team works with users and usually a presenter in a special room, secluded, specially equipped in the style war room, where the walls are used to display an “information radiator” (a form of cockpit project management) . This organization and these techniques have become common to all agile methods.

Among the technical features of the conduct of agile project appeared more recently, we find the expression of formal requirements preferably with “user stories” and consensual assessment by the team as part of a serious game called planning poker that estimates the load to produce a unit of value that can be either “ideal days” or “points of story.”

All agile methods use a procedure similar or identical:

  • A functional manager defines and directs the production of components of the application.
  • The project is structured in increments of 1 to 6 weeks according to need (size, responsiveness, visibility …).
  • An initial meeting organized each increment defining the tasks to be performed.
  • The team controls the quality and performance of the proposed consensus.
  • Each day, a short progress meeting gives the team an overview of the project, highlighting potential problems and allows to factor solutions.
  • A ‘reporting’ wall (Kanban, progress graphs, etc.) is updated in real time by team members.
  • A completed increment contains a complete delivery, developed, tested and approved.
  • A final meeting presents this application and is followed by a technical retrospective of the development process.
  • The functional manager validates the work of the team and fits the needs between each increment.

Main criticisms

In the reality of their implementation, all methods do not meet the same basic agile principles.

Scrum requires high specification prior to the start of production (product backlog), which would classify it as part of predictive methods side. Some believe that this would not be a problem if Scrum had a formal change management metric. But the goal of Scrum is primarily focused on mastering a delivery of increments (sprint). The process therefore refutes the possibility of changing the features in progress (except a simple refinement since the 2011 version). For this reason, some argue that Scrum can then be considered truly iterative and adaptive.

Moreover, as Scrum provides no software engineering technique, it is necessary to use another method to ensure the quality and reliability of IT developments.

Some explain, especially in complex projects, it would be necessary to add to Scrum as eXtreme Programming practices structuring requirements that they need.

This text is licensed under the Creative Commons Attribution-Sharealike 3.0 Unported License (CC-BY-SA)

Leave a Reply

Your email address will not be published. Required fields are marked *