|
| PUMA Architect of a generation of powerful companies |
|
PUMA is a global framework of the Agile enterpriseThis communication follows up that which presented PUMA (Proposal for the Urbanization of Agile Methods) globally. PUMA is a dynamic framework for the evolution of business processes, information systems, and collaborative modes. By basing itself on the fundamentals of the Agile movement and the technical standards that it integrates and brings together, PUMA represents the first formalization of an Agile and global Enterprise method, coupled with a project motor, by the intermediary of a solutions model. This model was conceived with regards to the new order of current requirements classes and the imperatives of the incremental, iterative principle. The Agile Project Motor is one of 3 components of PUMA. More precisely, it is the component of operational implementation. By modeling the high-level generic structures applicable to all organizations, PUMA’s ambition is to reduce the complexity of their management. If a professional who faces the PUMA solution immediately thinks “it’s naturally obvious, I already had it in mind, but I never had the time to formalize it,” the challenge of Agility will be taken.
Figure 1. — PUMA Proposition for the Unification of Agile Methods
Today, approximately ten methods meet the requirements allowing them to call themselves Agile. As a common point, they put into place, from the beginning of a project, a reduced team, composed of a homogenous group of “creators-developers” in a solution space permanently validated by real users. Figure 2. — Adaptability or predictability of the methods Agile risk managementComparing a classical project management method with an Agile method from the point of view of project risk management (delays, quality, etc.), could be interesting for a logical thinker. ú The classical approach tries to reduce the risks using specific and deterministic steps for which the preventative costs (analysis, detection, follow-up and corrections) are non-negligible. ú The completely practical Agile methods are based on the competence of the development teams that they engage in permanent practices oriented to performance and validation in order to naturally avoid the occurrence of risks. All the methods find themselves concretely at different degrees on a scale that positions them from the most predictive to the most adaptive. If one wishes to have a vision of the application scope of the various current methods, it is necessary to sort them according to these criteria (figure 2). The differences emphasized this way therefore justify a detailed analysis of the project environment and of the type of application in order to determine which aspects of the method will allow for the limitation of the risks that were revealed, and which methodological service level and application quality will be put into place. The paradigm of classical methods is predictability. The paradigm of Agile methods is adaptability. Let’s be clear: no approach is reduced to just one of these visions. All try to deal with the contradiction of flexible rigidity, with greater or lesser finesse and with more or less success in function of the context: § Predictive methods try to reduce uncertainty from the beginning of the project using very detailed and precise planning. This elimination of risk implies that the requirements of the application be fixed. § Agile methods prefer, starting with an initial planning that is reevaluated regularly, to adapt themselves to the evolution of the context. The reevaluation will serve as a basis for making GO or NO GO decision (figure 3) at each major change applied to the initial project.
Figure 3. — Procedure allowing for evaluation / decision One of the significant points of the Agile concept requires the involvement of rationally-motivated resources focused on the service to provide and no longer on the product to create. Agility therefore creates a real team dynamic that appeals to both the client and the developers: the client finds himself in a central role in the development, and the developers participate in all aspects of the development and work as part of a real team. In terms of Agility and the Iterative-incremental cycle, the idea of planning is the most frequently misunderstood. All Agile methods are in fact semi-iterative and begin by an exploration of the problem and the planning of its solution. Whether this step is called Release Planning at the project level, Planning Game at the release level, or Standing Meeting at the daily or Zero-Default milestone level, this doesn’t change the principle that adaptability must remain under control. An Agile approach is by its very essence adaptive, it accepts change but measures the consequences. According to the context, the change and its acceptance present themselves with greater or lesser acuity and the negotiations are more or less important or formal. In all cases, questioning the initial plan (the Project contract) requires a new planning creating a win-win exchange. The tasks concerning the functionalities to introduce or modify are therefore planned according to their priority, pushing back (to the bottom of the pile or into a new project contract) the less important functions. This consensual negotiation implies a capacity of objective evaluation of the tasks to introduce or remove as well as an Agile toolkit for configuration management. Although similar based on their common principles and practices, Agile methods offer more or less complete coverage with regards to the generic concerns of a project manager: ú Respect for the environment (positioning of the project in the information system) ú Management (resource management, planning, follow-up, quality, reporting, visibility) ú Application engineering (Requirements management, creation and development, validation) ú Change management (organizational impacts and deployment) All of the difficulty in choosing the right method in function of the general context of the application or the project context can be found here. By selecting the Agile best practices as part of a variable methodological level in function of the project, PUMA offers a homogenous and progressive response to this concern that is as powerful as it is elegant. Common practices among Agile methodsThe heart of the practices common to Agile methods is the following 1 – Common practices linked to human resources § Participation of the end user in work groups. § Work groups with decision-making power. § Autonomy and centralized organization of the team (motivation). § Specification et permanent validation of the Requirements. 2 – Common practices linked to project management § Variable methodology level in function of the project goals. § Management by the goals and the risks. § Strategic global planning based on rapid iterations. § Creation in phases by active iterative and incremental. § Continuous search for the amelioration of practices. 3 - Common practices linked to production quality § Search for technical creation excellence. § Graphical view of a necessary and sufficient model. § View of the necessary and sufficient documentation. § Reasonable norms and techniques of code quality (metric). § Architecture based on components. § Automated change management. Differentiating practices of Agile methodsOnly a few techniques, complementary amongst themselves, or better adapted to specific typologies and project sizes, differentiate them. Lets now look at the most significant differences in practices among them. The particularity of the DSDM method is the specialization of the project participants into “roles.” This way, executive sponsors, ambassadors, visionary users, and advising users can all be found in DSDM meetings, without forgetting the animator – facilitator and the minutes recorders. ú The SCRUM method affirms its difference in the practice of short daily meetings. These common working sessions have as their objective to improve the motivation of the participants, to synchronize tasks, to unblock difficult situations, and to increase knowledge sharing. ú For FDD, the particularity named Mission focused resides in a strong orientation towards an immediate, measurable goal. It is, in fact, the global ambition of an iteration that finds itself thereby reinforced. This aspect is also found in RAD in the form of Focus objectives or in Scrum in the notion of Sprint. ú FDD requires Features Driven Development. This technique characterizes itself by the notion of the Feature and the Features set (functionalities and groups of functionalities). The priority is given to functionalities that add value. RAD proposes similar techniques: delivery with reduced functionality or delivery by theme. ú XP is very focused on the area of application construction. One of its originalities resides in the approach to planning which expresses itself in the form of a game called the planning game and that simultaneously involves users and developers. One will also note particular techniques linked to code production such as programming in teams of two, collective appropriation of code, re-factoring, and continuous integration. The RAD method requires, in this way, personal code reviews, then collective reviews, and integration before each Focus. On the other hand, RAD limits programming in teams of two to the most strategic sections. ú 2TUP requires a “Y” lifecycle that dissociates and parallels the resolution of functional and technical questions. The 2TUP lifecycle resembles a domino effect but introduces an internal iterative form to certain tasks. It is not certain that the cycle really belongs to an Agile approach. On the other hand, 2TUP requires interesting forms of seeking quality and performance such as reusable services and generic creation (Framework and Design pattern) close to the RUP architectural methods. ú RUP is characterized by a global approach named “View 4+1.” The 5 components of this view are: the Use Case view, the Logical view, the Implementation view, the Process view, and the Deployment view. RUP also offers, like RAD, a formal and adaptable Process guide as a guide to activities. In the case of RUP, it is unfortunately proprietary and tool-oriented. RAD and RAD2 Processus ú The most important thing that RAD brings to project communication and to the formalization of requirements is the Group Animation and Reporting (GAR). ú Like the other methods, RAD requires the formation of a specific development team, SWAT. This team is autonomous, specially trained, deeply motivated, and well-equipped. It is composed essentially of a unique profile of designers-developers trained in complementary technical specialties. ú The SWAT works with users in a particular room that is specially equipped to form a communications base (RAD room). ú RAD also recommends varying the size and the experience level of the work groups in function of the phases of the project in order to optimize the engagement of resources and to preserve their interest in work that is adapted to their concerns. ú The high-performance organization of meetings is based on an operating mode of interviews (sessions in 3 steps) and on techniques of permanent validation. All methods of project steering should include an operating mode for emergency stops. However, the study of old predictive methods seems to lead to an optimistic idea: the authors have never experienced failure and their disciples must follow this path. On this point, the force of RAD is found in the presence of the animator-facilitator. This resource, preferably external, must be neutral with regard to the other participants. He or she responds to a higher authority than all of the project participants. This way, when the strategic, economic, or technical context of a project evolves, or if the working conditions degrade, the animator reports the problem to the director who ordered it. The director can then make the necessary decisions in the best possible time frame and with objective information.
The PUMA project motorOnce the common practices are isolated from differentiation practices, it is simple to imagine what should be the optimal method in function of the particular project type : § The optimal Agile method is composed of the entirety or a selection of common practices to which it is convenient to add specific practice(s) judiciously in function of context. § The entirety of these aspects is obligatorily part of a variable, methodological service level. Here rests the base of the PUMA project motor. To optimize its use, the understanding of the project and its environment and constraints is indispensable.
The PUMA project motor is composed of 3 levels of Agile practices. The second and third levels respond to more and more important or specialized project requirements. ú The first level is composed of fundamental Agile principles described as usable practices and a low-level base responding to basic project needs. This base can simply be composed of the 12 practices of eXtreme Programming or be enriched with several complementary practices specific PUMA, such as, for example, the use of Facilitated communication techniques or the Agile solutions for requirements expression. ú The second level introduces two groups of light Project management practices. It generally corresponds to more important projects that demand increased control or visibility. ú The third level allows for “à la carte” choices among 15 complementary practices, which are sometimes complex in their classic versions but are specially “Agilized” for PUMA. |
|
|
These are operational explanations of the four fundamental Agile values and the four fundamental Agile principles: collaboration, interaction and negotiation with users, frequent deliveries, permanent validation, etc. As simple as they may appear, the operational implementation of these collaborative modes requires experience and tenacity on a daily basis.
|
|
|
All Agile methods are in fact semi-iterative and start by an exploration of the problem and the planning of the solution. After this, the adequate choice of the Agile methodology level can be made. This flexibility permits PUMA to offer an adaptive solution, regardless of the type or importance of the project. |
|
|
All Agile methods, including PUMA, are based on a cycle made up of 3 principle phases that are accentuated to a greater or lesser extent: Exploration of the problem and the possible solution, with regards to the constraints, Global conception of the solution, Obtaining of the solution. Keys to global planning are specific to each approach (Agile, RUP, …). |
|
|
The mastery of the temporal dimension of the iterations is capital. It is on this control point that the pertinence of Agile methods with regards to project management is played out. Many models proposing anchors linked to different types of project constraints are available and calibrated. |
|
|
The various deliverables are dependent on the type of project and the organizational culture. The important thing is to respect the Agile fundamentals: that which is useful and sufficient. |
|
|
Bringing programming to the rank of a collective discipline, eXtreme Programming proposes a coherent ensemble of the 12 techniques that bring solutions to a great majority of performance and quality problems in the area of application development. Separated into 3 groups (collaboration, project management, development quality), these practices are treated in an annex. |
|
|
All of the resources included in the communication plan intervene simultaneously from the real beginning of the project. The goal is to obtain a simultaneous understanding of the problem by all actors and to end up with the creation of a homogeneous knowledge space. This approach also allows for the avoidance of wasting energy linked to repetitions as well as risk of errors, redundancy, or divergence linked to multiple formulations. The understanding of the participants is global and unique. |
|
|
In order to optimize the engagement of resources, the communication plan applies to the work groups a principle of variability according to the phase or the depth of the iteration. This way, the presence of high-level executives, indispensable during goal definition or process reconfiguration, will no longer by solicited during the detailed specification phases.
|
|
|
A collective mode of working characterizes interviews, which require intensive participation from users. The operating mode of communications is structured into 3 steps: pre-session, session, post-session. These practices have as their goal to obtain a real-time formalization and an immediate validation of requirements expressed. They require, in addition to the imperative presence of the “for action” participants from the communication plan (real empowerment), the availability of an isolated and well-equipped work area. |
|
|
The structure of the requirements expression takes into account 4 classes of applicable requirements at 4 levels of concern: strategy and creation constraints, functional, technological, and organizational. According to the advancement of the project, the requirements are expressed more and more precisely. This iterative, incremental approach is performed in a unique document at four depth levels.
|
|
|
A minimal formalization is always necessary. It could be simply a sheet of paper (CRC card or user story) as required by XP, a more detailed document, a formal model, or a mix of these techniques. The important thing is to respect the fundamentals of Agility: that which is useful and sufficient. |
|
|
The operations of ranking requirements or prioritizing functionalities are the responsibility of the functional team but are the object of a planning game with the technical team, who has the knowledge to allow technical dependencies to be displayed. This practice appears in the development choice (by usable themes or temporal stability of components). |
|
|
It is no longer reasonable to rush into a completely specific development. The practice of Spike Solution covers an exploration step (often on the Internet) for available or emerging technologies (Professional software, Components, Open source, etc.). |
|
|
Agility obliges the project leader to keep in mind that the objective is an application and not multiple models. A simplified way of thinking, Agile Modeling, considers modeling in excess and not adaptive for projects under heavy time or monetary constraints. It proposes an optimization in the use of models in function of the context.
|
|
|
Advice for the identification of optimal granularity and normative development base. For example, SOA (an approach to design and construction of services in the form of independent applicative bricks). The advantage is to produce simple, modular, and weakly-coupled components that can therefore allow for quick re-composition of the application framework of the functionalities they assure.
|
|
|
Secured construction architecture and preparation of a Construction Show. An important point: defining, for each phase, the number of iterations and their precise content. The construction architecture orchestrates the entirety of the “best practices” of PUMA and/or of XP. The open and adaptive principle, however, formally assures the control of the iterations as well as the respect of practices for technical and functional quality. |
|
|
The GCL manages the state of the components, masters the traceability of changes, and guarantees restoration benchmarks. The GCL manages tasks and multiple workspaces, allows for coherent coordination of development activities, to share files, and to isolate elements specific to certain tasks. Even for small teams, the use of a GCL tool has become indispensable. |
|
|
Frequent deliveries that allow for feedback and permanent validation are one of the most important practices of Agile. The client expects, at a fixed time, an executable version with reduced functionality but containing a certain number of planned increments. The non-respect of the planning game is immediately made visible. Frequent deliveries allow for an accelerated ROI in certain cases. |
|
|
Working from a unique shared knowledge base obtained during common working sessions of comprehension and validation, the decisions to continue actions (GO & NoGo) are made collectively in a win-win model that protects the interests of the project as well as those of the solution. |
|
|
From the requirements, the estimate of the workload, the development method chosen and the timeframe, a planning is conceived. The details must reach a level of finesse sufficient to determine individual tasks. It is then possible to organize these tasks by group level in order to facilitate the creation of tasks in parallel or by lot, whether it is temporal or contractual. These logical and temporal constraints and the dependencies among activities are therefore introduced. |
|
|
The planning of an Agile project is fundamentally different from that of a classic project. A simulation and optimization practice allows, in the strategic choice of planning, for the evolution of scenarios in function of diverse project constraints (time frame, cost, perimeter, quality, visibility, risk). The principle interest in this practice resides in the immediate display of incidences of each negative option that is foreseen. |
|
|
A fixed period, which could be daily, of control operations allows you to fill in the engagement of resources based on the real advancement of the work. The objective is to obtain a vision of the project allowing for verification of the real advancement and production sufficiency with the quantitative planned objectives. This activity is an element of the CRM practice Follow-up and supervision of a project. |
|
|
For the follow-up of important or specific projects, indicators that show the evolution of risks can be added. Sometimes, elements of a quality metric can be added. They can concern the technical quality of the product (for example, the evolution of the number of corrected and uncorrected errors) or its functional quality (number of fixes coming from the client). |
|
|
A dashboard can be part of a larger group of indicators of the activities of an Information Services Department, produced to present the information that allows the project managers and steering committees to make appropriate decisions whether to continue, reframe, or stop. |
|
|
Agile methods are based on communication practices that bring together IT professionals and users. There are techniques that allow for animation of meetings and to facilitate decision-making. In case of a difficult context, experts can be brought in to accompany difficult actions. PUMA also proposes a model of Neuro Agile Facilitation of Collaborative modes. |
|
|
An Agile project team is composed of the ensemble of the parties involved: representatives of the functional and technical teams as well as Experts and real users (themselves considered experts in their activities). This engagement as well as its forms and conditions are formalized in a document entitled “Project Communication Plan.” |
|
|
In prototyping the Construction of the solution, the interviews can be founded on a weakly structured communication when: users are available on a regular basis, that they accept the planning game and the mode of specification-coding-test, iterations are rapid (up to 2 / day). The principle practice to respect consists of always letting the user manipulate the application in order to validate it. |
|
|
At each iteration or step (generally phases or benchmarks) and for each concern, a document with a unique structure (based on 4 classes of Requirements) is used for the formalization of information. In this unified formalism, the only distinctions can be seen by the taken by one or the other of the classes of concern or their level of depth. |
|
|
Project management consists of listing and analyzing the risks that could affect the outcome of the project and the events that could cause them to occur. The action plan then consists in putting into place preventive actions, to survey the evolution and the materialization of risk, and to engage, if necessary, corrective actions. The level of risk management is dependent on the type of project. |
|
|
The notion of formalized processes is at the base of all standardized approaches for project risk management (like CMM). Without introducing a heavy process into the Agile mode, a Check-list of actions or usual practices from which to determine those that seem pertinent in the context is generally a useful aide for the different participants in a project. |
|
|
Classical quality imposes an obligation and a formalization of means but does not specify the result expected. Agile quality proposes an obligation for the result but requires autonomy of means. The notion of quality norms is also a principle that agility is often confronted with. PUMA proposes a Quality Assurance Plan compatible in its structure with the recommendations of CMM and ISO. |
|
|
When the project group must justify its budget by a formalized return on investment, this very light investment plan model will guide the actors involved in its justification. Here are treated the minimum economic, budgetary, and accounting practices that a project manager must have. |
|
|
The BPM is based on business models to optimize and adapt the ensemble of activities. By remodeling the organization around processes that make up the heart of the organization, the BPM imposes itself as the principle driver of operational performance. BPM projects are one option for PUMA project management. |
|
|
Allows for the measurement of non-quantifiable information automatically such as, for example, the general level of user satisfaction with regard to communication, the impact of previous corrective measures (interface ergonomics, conformity to requirements, functional completeness, level of documentation, etc.). |
|
|
In a project, 7 layers may be externalized, making up the ensemble of the solution. The team opens itself up to all concurrent possibilities and sees them as means to complete the mission. The objective of this choice is to obtain the best quality at the best price, in the best time frame in function of the constraints imposed. |
|
|
A regular and transparent project communication characterizes the Agile management mode. This practice proposes means of communication adapted to the size of the projects. |
|
|
Standards are a key element of SOA and BPM projects. This practice includes the diverse protocols SOAP, WSDL, UDDI, WS-x, BPMN, BPEL, etc. and all those that are necessary to model and orchestrate processes or develop Web services. |
|
|
In the daily practice of project,, and more particularly when the teams are spread out, the participants need a formal means of communication to permit them to work as a group. The collaborative virtual work workspace is therefore seen as a privileged means of communication. |
|
|
Agility and normalization are ideas with identical objectives but philosophically opposites in the way they obtain them. This practice performs a mapping between Agile practices and the practices of CMM, TSP, and PSP.
|
|
|
The fundamental concept is the complete reorganization of working processes and the division of tasks in order to reduce the time and the effort. It consists in analyzing the logic of procedures in function of the reconsidered finality of the missions of the organization. Means: rationalization of the activities, reduction of delays, improvement of reactivity, reduction of costs, improvement of quality. The action takes into account the ensemble of the drivers of change management. |
|
|
Tool for the resolution of “complexity of details.” The detection and resolution of problems is applied to minor malfunctions that generally escape the attention of higher levels because of their low visibility. The Agile enterprise continuously masters the complexity of an evolving environment by treating, as soon as they are detected, emerging changes. |
|
|
Current organizational systems are complex. To master and simplify them, it is necessary to use the power of collective intelligence. The collaborative model draws its force from the practical knowledge of employees whose participation in a systematic search for improvement is rationally provoked.
|
|
|
Recommendation in the area of modeling tool usage and organization of processes. The level of criticality of the processes directly influences the management mode and the choice of tools. This also covers the monitoring aspect (BAM). |
|
|
Agility requires that the pilot project keep in mind that the objective is an application and not multiple models. A simplified way of thinking, Agile Modeling, considers modeling in excess and not adaptive for projects under heavy time or monetary constraints. It proposes an optimization in the use of models in function of the context.
|
|
|
Advice for the identification of optimal granularity and normative development base. For example, SOA (an approach to design and construction of services in the form of independent applicative bricks). The advantage is to produce simple, modular, and weakly-coupled components that can therefore allow for quick re-composition of the application framework of the functionalities they assure. |
|
|
The unification of an information system defines a development plan that is coherent and in phase with the strategy, the business departments, the processes, the technology, and the current system. The standard model is made up of four layers: processes, organization, application, and infrastructure. Unification is one of the elements of Enterprise Architecture. |
|
|
Standards are also key elements of SOA and of BPM. These practices bring together the different protocols of SOAP, WSDL, UDDI, WS-x, BPMN, BPEL, etc. and everything that you need to model and orchestrate processes or develop Web services. |
|
|
|
Figure 5. — A summary of XP principles (Design Up)
XP uses programming as a collective discipline. Here is a synthesis of the 12 fundamental principles of XP presented in order of their implementation:
ú 1 - Planning is a consensus between the client and the developer. As with Risk Driven Development, it proceeds by priorities (sometimes technical when linked to dependencies, but most frequently functional). The developer focuses uniquely on the principle goals and delegates the treatment of the secondary objectives. The principle of “courage” is applied to negotiations with the client in case of possible divergences.
|
|
Technique: Planning Game. The client produces use case scenarios and prioritizes them. These scenarios are then implemented by the development team. The project is considered finished when the client cannot find a new scenario. |
ú 2 – XP teams use metaphors. The metaphor is a high-level abstraction. The metaphor must not be an overly simple version of the initial concept, but must allow for the simplification of complexities such as, for example, clarification of functionalities. The merit of a metaphor is to by synthetic and explanatory. For example: using a metaphor as a “recipe” to explain a sophisticated process. In XP, the majority of the metaphors concern the functionality of the application or the architecture.
|
|
Technique: elementary metaphors and analogies are used to describe the system and its functionality before delivery of real functions, in order to make it understandable by non-IT workers and users involved in the development . |
ú 3 – The application is quickly available in a limited version. The construction phase it made up of iterations structured into steps (short specifications, development, tests, feedback from the client). The functional aspects are described in brief, scenarios that can be implemented and validated immediately by the client. The risk of misunderstanding is therefore reduced to a minimum. Modifications can be frequent but concentrated into a very short cycle. The objective is to quickly have an operational pilot application. The application sections delivered could even be used, with reduced functionality, if the dependencies with other non-delivered sections are not too strong.
|
|
Technique: Frequent releases. They allow for immediate feedback, while at the same time offering validated functionalities that can be used. Delivery frequency is weekly. |
ú 4 - The design is simple and focused on current requirements. Without speculating on possible further evolutions (not expressed), the developer codes the essential, based on immediate requirements in their order of priority.
|
|
Technique: Initial planning based on added value of the expected functionalities. Simple design and simple coding, in order to facilitate future evolutions, making the product easy to understand and modify. Minimal documentation adapted to real needs. |
ú 5 – Development in two-person teams. Two development resources work simultaneously on the implementation of the same code. Taking turns, they program and validate the quality in order to product clean, robust, and trustworthy code. In certain projects, the developers create teams of two only during re-factoring sessions (as with the RAD method), or when the problem is particularly difficult. This practice is associated with the rotation of these teams. The ensemble is considered the Agile form that is the most powerful for collective learning and integration of beginners.
|
|
Technique: XP programmers work in teams of two on the same machine. The first developer (called driver or pilot), has the control of the keyboard and works on the section of to be written. The second developer (called partner or copilot) assists by suggesting options or detecting possible problems. |
ú 6 – Collective appropriation of the code. The team is collectively responsible for the application, and is assumed to have knowledge of the entirety of the code. According to this theory, the quality of the ensemble of the code is the responsibility of the ensemble of the programmers. This practices increases the effective quality of the code, reuse, understanding, and removes the principle problems linked to turnover.
|
|
Technique: The developers frequently reorganize the two-person teams, which allows for the improvement of the collective knowledge of the application and the communication at the heart of the team. |
ú 7 – Sustainable rhythm Weeks have only 40 hours and tired resources commit errors that are always more costly to solve after the fact.
|
|
Technique: Individual planning does not include overtime for two weeks in a row. |
ú 8 – The client collaborates permanently and directly. In order to assure an improved reactivity and rapid feedback, a representative from the client must be present for the entire duration of the project. This resource, dedicated to the project, is responsible for determining the requirements, assigning the priorities, and validating the tests.
|
|
Technique: A permanent representative from the client is present at the site. This representative must master the practical knowledge of a final user, while at the same time possessing a global vision of the final result to obtain. This is, in general, an operational executive. |
ú 9 - Standards of coding. To facilitate the collective appropriation of the application, the reuse, and the communication, the programmers code in identical styles and with identical rules (naming norms for variables, methods, objects, classes, files, etc.).
|
|
Technique: Standards of coding, frameworks, design patterns, naming conventions, etc. |
ú 10 - An XP program is tested and validated continuously. XP requires, for the technical part, programming driven by tests (TDD): for each class of application, developers write a class that tests and verifies the results of these tests.
|
|
Technique: Zero-default benchmarks by Test-Driven Development based on tests coming from a low level translation of integration tests. |
Functionalities are for their part validated by tests (with and by the user).
|
|
Technique: Zero-Default Benchmarks by finalization of permanent validations obtained from the user during prototyping. |
ú 11 – Continuous Integration: The modules developed are assembled on a daily basis or at the end of coding of each benchmark. The starting version of a new code implementation is thereby performed on a stabilized application.
|
|
Technique: Zero-Default Benchmarks by permanent integration of tested configurations. Construction planned in small modules that are integrated and tested progressively. Several daily integrations can be performed daily if necessary. |
ú 12 – Re-factoring of code. During development, the code is reworked continuously and progressively. The software is clean and simple. Otherwise, corrections are much more costly, the design is corrupted, the code becomes fragile, and the application loses structure.
|
|
Technique: Re-factoring by continuous improvement of the code quality without changing its behavior (comments, respect for naming rules, simplification, etc.). The result of this “cleaning” is produced regularly and is validated during collective working sessions with the participation of the entire team. |
On the other hand, all Agile techniques are not necessarily implemented in an identical way in reality within organizations.
Figure 6. — Real use of practices
Agile practices concerning code quality (particularly Pair programming) generate a cost of realization approximately 20% higher than that of classic development. In return, they notably reduce the number of residual errors in an application when it is put into production, according to the study Strengthening the Case for Pair-Programming (Tableau below).
In numerous domains of IT management, the search for perfection and the complete reduction of risk are dangerous chimeras. Obtaining relative quality in a given context in function of precise constraints is in fact the only goal that can be reached. Abandoning the idea of perfection is the most difficult principle to accept intellectually for the logical spirit of a rational-minded person, such as an IT professional. It is, however, the search for absolute quality that leads projects to lose “body and soul.”
Refusing a user request is not an easy thing, it’s true. To avoid the trauma of refusing, it is preferable to obtain a renunciation from the client. To make this situation possible, it is necessary to put a price on each functionality. The budgeted amount is, in this case, transferred to the user. The user is then conscious of the link between budget and requirements and imposes the priorities.
The management of the budget in regard to the functionalities should be the problem of the functional team and not of the IT workers. Project management by operational departments, based on the budget and the time frame, keeping in mind the goals and risks, is the only form of project management that can stand up to the complexity of modern development.
It is frequently heard that “the urgency of problems makes having a vision impossible, but it is in fact the total absence of perspective that makes you a slave of urgency.”
Along the same lines, IT workers often complain about the methodology and its heavy requirements, and try sometimes to indiscriminately work around them. Complaining about the method is the same thing as complaining about the driving code. Driving without knowing it and without respecting it can naturally lead to an accident. And, when it comes to project management, the victims of the accidents are not only budgets and timeframes but accidents can even kill enterprises through operations, logistics, sales, and capability for expansion.
However the “all or nothing” principle does not apply to the method if it is understood well. An intelligent approach adapts the “level of service method” to the type of requirement. This economical sizing of effort allows for preservation of basic, indispensable rigor of management of projects that are “moving” or under constraints.
It is just as indispensable for the project manager to chose with discernment the method whose cycle will be best adapted to the requirements of the future application. This real development management must systematically evaluate the diverse forms of obtaining things (professional software, solutions, components, externalization) from the angle of constraints (budget, quality, time frames, or resources).
The same way, when it comes to design, the choice of a level and form of model takes up the challenge of a modeling that is adapted to the specifics of each problem. The competent designer-developer creates “in view of modifications” and searches for design techniques that can integrate change, because efficient modeling must evolve in synergy with the reality it describes.
The Agile movement found its initial inspiration in the resolution of problems with which teams assigned to IT system development found themselves confronted. Agility therefore emerged from project groups, where individualism was extreme, in the form of collective discipline, but at a human scale, of performance and quality.
The Agile enterprise lives at the rhythm of its projects and the energy of this dynamism assures its existence “Just do it”, such is its empirical and pragmatic slogan. Carrying this philosophy, the Agile movement consecrates itself to the essential and offers the possibility to attain simplified power. So lets try to be simple, and with the limits of or actions, adopt, as a slogan “be Agile.”
For the sake of the quality of which it is a more and more vital component, Agility is not decreed from the highest structures. Agility emerges from the base of the organizational pyramid and patiently conquers all the levels, because Agility is fractal. An operational response to constraints as important as those imposed by the globalization of exchanges, the principle of collective intelligence on which Agile rests will progressively end up spreading forms of flat hierarchies.
Agility, at this stage, is the dynamic revolution of organizational systems.
The dilemma of the IT worker is often found in relation to dysfunctions of the organization that he must code, the organizational aspects that are worrying are most often masked until the end of the project in the hopes that the application will reveal them after the fact. Very often, the realization is too late, and a maladaptive application is uselessly developed that makes the basic problem permanent. Sometimes, the movement for refusing changes imposed becomes a social problem, and the participants regret the lack of communication after the fact.
There is a long road to go down before arriving at an optimal system in the majority of organizations. By dissecting the details of techniques put into place by the Agile movement, some will be disappointed not to discover anything totally new or miraculous. In fact, good sense leads to the most theoretical concepts of Agility being seen as simple improvements in managerial practices.
But, beyond a progression in the state of the art, what is essential in these changes is the rhythm that they bring to our thought processes. A rhythm of engagement of human resources. A rhythm in the phasing and in the temporal dimension of projects.
In an environment of accelerated evolution, the dynamics issued from facilitated communication from a rethought organization, and from more fluid information systems enter in synergy and impose themselves in the energy of the rhythm. A rhythm of change, a winning, rhythm, an Agile rhythm.
Table of Contents
Table of Illustrations
Figure 1. — PUMA Proposition for the Unification of Agile Methods................................. 4
History of PUMA
|
|
In September 2001, Jean-Pierre Vickoff, one of the pioneers of the Agile way of thinking in the I.S. field and its French-speaking initiator, writes the first communication regarding PUMA. Its translation is then expedited to the American and English universities |
In December 2001, “Développeur Référence” (IDG) uses the PUMA graphic design (Proposition for Unifying Agile Methods) on the cover of an issue that devoted its main feature to the rough outlines of this novel Agile vision. The communication is then taken up in 2002 by numerous publications, including: ADELI, “Forum Logiciel”, LMI, etc.
At the time, PUMA already expressed its vision of Agility as follows “After having determined the major portion of the common practices and the differences in practices of each approach, the unified Agile method is composed of an optimal selection of common practices to which it is convenient to judiciously add specific practices in function of the context.”
It seems that the initial idea of PUMA was quite good, because Ivar Jacobson announced in 2006 in EssUp (Essential Unified Process) “a basic method which will be enriched with additional practices in function of the project needs.”
Since then, Jean-Pierre Vickoff has enlarged the scope of PUMA (now the Proposition for Unifying Agile Methods) by adding two outer layers to cover the entirety of the organizational adaptation aspects as well as the anticipation and optimization of processes. Because, without taking these points into account, there are no enterprises or organizations that are truly Agile.
Representing a significant advance and an enlargement of the scope of organizational agility, the principles of PUMA are the subject of several publications in French and in English on the site Agile Alliance.
Concerning the use of the PUMA method , its author Jean-Pierre Vickoff as well as TEAMLOG, the company with which he collaborates in creating TMF (Teamlog Methodology Framework), wish to render the theoretical principles accessible to the entirety of the profession by regularly publishing, via the media and the Web, on its structure and its practices by the intermediary of professional organizational principles www.Entreprise-Agile.com
© Jean-Pierre Vickoff. The text and graphics in this document have been registered and copyrighted by the author Jean-Pierre Vickoff, as well as by the medias who initially distributed them. You may copy and distribute, without alterations, all or part of this document in any format, commercially or non-commercially, on the condition that this licence and copyright notice are reproduced on each copy, and that you do not add any additional restrictions. You may also, while respecting the author's ownership, quote brief passages.
|
