Extreme Programming: What is it and basic principles?
Extreme programming is an agile development methodology that is primarily aimed at increasing productivity when developing a software project. Priority to jobs that give a direct result and in which the bureaucracy that may exist in the work environment is reduced.
We have 12 basic principles that are grouped into 4 different categories:
• Continuous process rather than blocks.
• Shared intellectual property.
• Shared understanding.
Test principle: the first thing you should do is set a period of acceptance testing program, in which the inputs and outputs of the system will be defined. Basically it defines what should the software developed. As if it was a black box.
Planning: The clients (or his representative) write needs to define precisely the activities that the system must perform. At this stage a document containing user stories that form the release plan, which defines the delivery time of the application in order to receive feedback from the client will be created.
In-situ client: the client (or his representative) should be part of the development team. You will be given the power to determine the requirements of the application define the functionality and prioritize certain things. Thanks to this, there will be a strong interaction with programmers, thus reducing communication time and the amount of documentation to write. The customer will be with the team throughout the project development process.
Pair-programming: These points with the above are the most radical of this methodology. It is to write code in pairs sharing a single machine. According to the experiments already carried out on this method, better and more consistent applications at equal or lower cost occur.
ONGOING PROCESS IN LIEU OF BLOCK
Continuous integration: is gradually implementing new software features. Instead of creating stable versions according to a schedule previously performed, programmers meet your code and rebuild the project several times a day if necessary.
Refactoring: by constantly removing duplicate code and / or inefficient programming teams improve the system design. The code is continuously evaluated to provide the highest possible quality.
Small deliveries: the product is tested in a real environment by placing a simple production system which will be updated quickly, ie, every 2 weeks (maximum 3) the software will be put into production.
Simple design: the best program is one that meets the requirements and simpler. It is important to provide software that meets the needs of a client. No more no less.
Metaphor: expresses the evolutionary view of the project and defines the objectives of the system through a story.
Collective ownership of code: the code has shared ownership. Nobody owns anything, even what he has developed. All programmers are “owners” of all the code. According to this methodology, the more programmers is working on a piece of code, fewer errors will.
Programming standard defines the rules for writing and documenting code, and how the different pieces of code developed by different teams communicate. The aim of this is that it seems that the code has been written by a single person.
SAFe presents a single, unified view of the work to executives, allowing them to drill down for details or up for trends and analysis
A team in SAFe might be 8 to ten people, with everything they need to deliver software, end-to-end: requirements, coding, testing and deployment. Several teams create what SAFe calls a release train, which organizes around a program (more on that below). That’s a single project, or at least, one program-of-projects. It has a single line item in a budget – the company is buying one specific thing. This is the “small project” the executive talks about.
A portfolio is a collection of these programs, the total amount of budget dollars within IT going into software development. SAFe calls this “Program Portfolio Management,” and suggests that one office have the responsibility for strategy and investment funding, program management and funding.
In SAFe terms, the “Release Train” is the team-of-teams, typically 50–125 individuals. Like a real train, the release train runs on a schedule, though that schedule can be as flexible as your organization needs it to be. This Program Increment (PI) is described in more detail below. SAFe suggests that people involved in a release train be dedicated full-time to that release train, regardless of reporting structure.
The Scaled Agile Framework, or SAFe, provides a recipe for adopting Agile at enterprise scale. It is illustrated in the big picture.
As Scrum is to the Agile team, SAFe is to the Agile enterprise.
SAFe tackles the tough issues – architecture, integration, funding, governance and roles at scale. It is field-tested and enterprise-friendly.
SAFe is the brainchild of Dean Leffingwell.
SAFe is based on Lean and Agile principles.
There are three levels in SAFe:
SAFe defines an Agile Release Train (ART). As iteration is to team, train is to program.
The ART (or train) is the primary vehicle for value delivery at the program level. It delivers a value stream for the organization.
SAFe is three letter acronym (TLA) heaven – DBT, ART, RTE, PSI, NFR, RMT and I&A!
Between 5 and 10 teams work together on a train. They synchronize their release boundaries and their iteration boundaries.
Every 10 weeks (5 iterations) a train delivers a Potentially Shippable Increment (PSI). A demo and inspect and adapt sessions are held. Planning begins for the next PSI.
PSIs provide a steady cadence for the development cycle. They are separate from the concept of market releases, which can happen more or less frequently and on a different schedule.
New program level roles are defined
* System Team
* Product Manager
* System Architect
* Release Train Engineer (RTE)
* UX and Shared Resources (e.g., security, DBA)
* Release Management Team
In IT/PMI environments the Program Manager or Senior Project Manager might fill one of two roles. If they have deep domain expertise, they are likely to fill the Product Manager role. If they have strong people management skills and understand the logistics of release they often become the Release Train Engineer.
SAFe defines a Scaled Agilist (SA) certification program for executives, managers, architects and change agents responsible for leading SAFe implementations.
Agile software development is a set of principles that portrays certain requirements for software development. It comprises of solutions that evolve better through self-organizing and cross functional teams. The principles are aimed at promoting adaptive planning, early delivery, and constant improvement, and it also encourages flexible and speedy response to change. Agile was first introduced in the 1980s when the idea of technology and technological advances took off in the Western world and has since then undergone a number of significant changes. It doesn’t consist out of any specific methods, but rather a range to choose from.
Before these methods are discussed, it is important to note that in 2001 the official Agile Manifesto had been drawn up which exemplifies the certain goals and requirements of agile software development. It consists out of the 12 principles of agile software development that keeps its developers on the right track. These also influence the different methods which will now be discussed in short.
The waterfall model is more of a philosophy than it is an actual method in which the mind-set is aimed at the project. It is usually in direct contrast of the iterative approach due to their complexities and differences when opposed to each other. The main differences between these two are the ways in which the software is built and tested. The waterfall method comprises of a separate building and testing phase, whereas in iterative methods the development testing is done concurrently as it usually is done in programming. Both these methods deliver desirable results. As soon as the developer has more knowledge about the software’s functions and values, they can make more informed choices. This is especially important when it comes to scrum as this kind of software development only has an iteration of 2 weeks.
Another method that can be used is the dynamic systems development method (DSDM) which acts as a project delivery framework. This forms part of an iterative approach and embraces user involvement. This type of development has the ability to fix costs, quality, and time at the outset. It categorizes the do’s and don’ts so carefully that it has become the number 1 method of agile software development. The DSDM method also underpins 8 important principles that developers should and can follow when they are busy with such a method in order to produce effective results.
This method is more focussed at the development team than it is on the actual product and process it is working on. It is very beneficial when it comes to agile software development, because it boosts team productivity. In this approach, team members are placed within a full view of the project and each person has an assigned task to complete. Participants work in a queue where delivery time is shortened and the product is completed more effectively. In terms of agile software development it is effective in working as a visual process-management system in the sense that it shows the team what to do.
The purpose of DSDM is to provide systems faster than is achievable in the waterfall approach without compromising on quality and development. The main control means is the time box: a short period of time (days or weeks) within the project, in which a product is delivered according to agreed quality.
Since the early 90s, there are new types of system development methodologies which is as a result of the fact that the old methods is often referred to collectively as waterfall methods, which has failed in yielding what was expected of it.
Dynamic Systems Development Method. DSDM was developed by the British DSDM Consortium.
The objective of the DSDM Consortium is making it a publicly accessible and generally accepted method, regardless of technical tools. It focuses on the information needs of a company and the solutions to be delivered, and as quickly and cheap as possible. DSDM is trying to fill that approach to building and maintaining systems that meet a tight schedule at a manageable project.
Based on a large number of projects the below advantages can be cited:
• The system is built faster;
• The users are more willing to take the system in-house;
• The risk of building an unusable system is reduced;
• The final system meets usually better to the business requirements of users;
• The users are better educated;
• The introduction of the system is usually smoother.