Extreme Programming (XP)

XP, is one of the most popular agile methodologies. XP is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks.The original XP recipe is based on four simple values simplicity, communication, feedback, and courage and twelve supporting practices:1. Planning Game2. Small Releases3. Customer Acceptance Tests4. Simple Design5. Pair Programming6. Test-Driven Development7. Refactoring8. Continuous Integration9. Collective Code Ownership10. Coding Standards11. Metaphor12. Sustainable PaceIn XP, the Customer works very closely with the development team to define and prioritize granular units of functionality referred to as "User Stories". The development team estimates, plans, and delivers the highest priority user stories in the form of working, tested software on an iteration by iteration basis. In order to maximize productivity, the practices provide a supportive, lightweight framework to guide a team and ensure high-quality software.Extreme Programming aims at bringing about efficiency in the coding process and providing customers with maximum value. The advantages of Extreme Programming include robustness, resilience, cost savings, lesser risks, and better overall satisfaction. Extreme Programming (XP) marks a departure from the conventionalprogramming approach. It stresses importance to individuals and interactions over processes and tools, working software over documentation, customer collaboration over contract negotiation, and responding to change over following a plan.Advantages of XP methodology RobustnessExtreme Programmingleverages the power of simplicity. The design resembles a jigsaw puzzle with developers working on many small pieces or iterations. The combination of such iterations at the end gives the end product. This approach creates working software faster with very few defects. Regular testing at the development stage ensures detection of all bugs, and the use of customer approved validation tests to determine the successful completion of a coding block ensures implementation of only what the customer wants and nothing more.One advantage of this approach is allowing for cost estimates-based software features instead of developer activity. This allows customers to make intelligent decisions on what needs inclusion and what needs exclusion depending on the budget. By selecting the important requirement first, the customer obtains maximum value with the least amount spent, and this can affect a trade-off on the marginal increase in product utility with the cost to incorporate additional features. This approach also allows both the user and the customer to "pull the plug" on development at almost any time and still have highly valuable functional codes, even if incomplete.

ResilienceThe traditional approach of programming works best when requirements remain static. In actual life, requirements keep changing either because of emergence of new business opportunities or simply because the initial requirement-gathering phase was incomplete. Extreme Programming in-builds accommodation of such changed requirements through getting user stories at the start of iterations, and through feedback during the course of iterations. Cost SavingsExtreme Programming trims unproductive activities to reduce costs and frustration of everyone involved. It allows developers to focus on coding instead of wasting time on needless paperwork and meetings and does away with the need for separate testers.The cost of making changes increases as the software advances in its life cycle, with the cost of making changes after delivery anywhere between 5 and 100 times more than the costs of making a change at the design stage. Conventional programming methods make changes based on customer feedback at the end of the product lifecycle, whereas Extreme Programming allows changes at the development stage. Lesser RisksOne of the major advantages of Extreme Programming is that it reduces the risks related to programming. Conventional programming depends a lot on individual superstars or critical members in the team. Extreme Programming, by breaking the tasks into modules, spreads the risk and reduces the dependence on any one architect, project manager, or individual coder. Employee SatisfactionExtreme Programming, while reducing the importance of individuals in the development process, also helps increase employee satisfaction and retention. Extreme Programming is a value-driven approach that sets fixed work time, with little scope for overtime. The breakdown of project scope into subcomponents and the constant customer feedback prevents accumulation of much work to be completed before a tight deadline.

Disadvantages The biggest disadvantage of Extreme Programming is that it assumes the constant involvement of the customer. Its success depends on data collection at many stages of the development process. Many customers might not be available, and many others might dislike such constant involvement. Extreme Programming code is a centered approach rather than a design-centered approach, and the lack of proper documentation creates problems in large products when project members leave and new members come in later. Extreme Programming is hard to do. The difficulties to get many developers accept this practice, and it takes a lot of discipline to keep doing them all. Your customers may not like the idea of so much involvement. Management may also find problems to get used with the practice that changes dynamically during the project life cycle. XP team does not believe the idea of fixed price, fixed scope kind of terms with the customer. Other processes are more likely to encourage the creation of detailed planning from the beginning. XP encourages pair programming. There may be a huge amount of duplication of codes that clubs with unit test. As a result, it is going to take long time to run and leave the database with lot of duplicate data. XP is code centric rather than design centric development. The lack of XP design concept may not be serious for small programs. But, it can be problematic when programs are larger than a few thousand lines of code or when many people are associated with the project. XP does not measure or plan Quality aspect of development. Managers for the big project believe that quality planning helps properly trained teams produce high-quality products. Another basic problem is that software today are very large and complex by nature. XP emphasizes on refactoring during software development process. Since, XP programming is not structured, it may be difficult to find significant number of defects for testers by just mere looking at the screen. On the contrary, traditional programming enables testers to find improved number of defects because it is well documented.

Dynamic Systems Development Method (DSDM)

DSDM is based on nine key principles that primarily revolve around business needs/value, active user involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration. DSDM specifically calls out fitness for business purpose as the primary criteria for delivery and acceptance of a system, focusing on the useful 80% of the system that can be deployed in 20% of the time.Requirements are baselined at a high level early in the project. Rework is built into the process, and all development changes must be reversible. Requirements are planned and delivered in short, fixed-length time-boxes, also referred to as iterations, and requirements for DSDM projects are prioritized using MoSCoW Rules.All critical work must be completed in a DSDM project. It is also important that not every requirement in a project or time-box is considered critical. Within each time-box, less critical items are included so that if necessary, they can be removed to keep from impacting higher priority requirements on the schedule.The DSDM project framework is independent of, and can be implemented in conjunction with, other iterative methodologies such as Extreme Programming.

There are 9 principles which are essential to any DSDM implementation, ignoring one of them will break with the frameworks philosophy and significantly increase project risks.1) Active user involvement Imperative.2) Teams must be empowered to make decisions.3) Focus on frequent delivery.4) Criterion for accepted deliverable (Fitness for Business).5) Iterative and incremental development Mandatory.6) All changes during development must be reversible.7) Requirements are base lined at high level.8) Testing is integrated throughout the life cycle.9) Collaborative and co-operative approach.Project structureThe DSDM project consists of 7 phased steps which are organized and embedded in a rich set of roles and responsibilities and are supported by several core techniques. Roles and Responsibilities Team Organization and Size 7 Phases to Rule Them-Pre-Project -Feasibility Study- Business Study -Functional Model Iteration- Design & Build Iteration -Implementation-Post-Project

Core Techniques Used in DSDMTimeboxingTraditional Project Management uses milestones whereas DSDM uses Timeboxing technique. Is an interval, usually no longer than 2,4 or 6 weeks, where a given set of tasks should be achieved.Timebox Can contain several tasks. At the end needs to deliver a product. Are subject to change since tasks are defined, not what to be delivered. Can change the tasks during time box iteration which allows for rapid response to business needs.DSDM drops functionality in favor of delivering in time.MoSCoW RulesDSDM projects are concerned to be in time and on budget and users are heavily involved in the development process. So it is mandatory to keep on watch on what users need the most.User requirements may change ( during the process) ; Aware of new technical possibilities User work environment changesThe DSDM techniques to weight the importance of requirements are the MosCow rules. And the rules are as follows,1. Must have: All features classified in this group must be implemented and if they are not delivered, the system would simply not work2. Should have: Features of this priority is important to the system but can be omitted if time constraints endanger.3. Could have: These features enhance the system with functional items which can easily be reassigned to a later timebox.4 .Want to have: These features only serve a limited group of users and are of little value.

PrototypingEvolutionary prototyping in DSDM projects satisfy 2 principles, Frequent Delivery Incremental developmentImplements critical functionality first so can discover difficulties early in the development process and allow having early deliverable to get user feedback.The necessary feedback-loop is provided by a workshop which is the last important technique in a DSDM project.DSDM differentiates on the following for types of prototypes,1. Business Prototype : Allow assessment of the evolving system2. Usability Prototype : Check the user interface3. Performance Prototype : Ensure solution will deliver performance or handle volume4. Capability Prototype : Evaluate possible optionsAdvantages Acceptance of DSDM philosophy before starting work. The decision making powers of users and developers inside the development team. The commitment of senior user management to provide significant end-user involvement. Incremental delivery. Easy access by developers to end-users. The stability of the team. The development team skills. The size of the development team. A supportive commercial relationship. The development technology.

Disadvantages of DSDM: High cost Relatively high barrier to entry Cultural shift in organization

Feature-Driven Development (FDD)

Basic processes of FDD.1. Develop Overall ModelThe modeling team comprises development members, domain experts and the chief programmers. Development members are guided by an experienced Chief Architect. Initially a high-level walkthrough is done followed by a detailed walk-through which gives an overview of the domain.Small groups should be formed which each group is responsible in composing a model. The Chief Architect can propose a "strawman" model to make possible the progress of the teams. A member from each small group presents that groups proposed model for the domain area. The Chief Architect may also propose further model alternatives. The modeling team selects a proposed model or composes a model by merging ideas from the proposed models.OutcomeClass diagrams with Methods and attributes identifiedSequence Diagrams2. Build Feature ListThe team needs to identify the features. Features are rough functions expressedin client-valued terms using this naming template: For example, calculate the total quantity sold by a retail outletA feature will not take more than two weeks to complete. When a business activity step looks larger than two weeks, the step is broken into smaller steps that then become features.OutcomeFeatures ListA list of subject areas and list the corresponding business activities3. Plan By FeatureThe project manager, development manager and the chief programmers plan the order that the features to be implemented. It is decided considering the feature dependencies; load across the development team and also on the complexity of the features to be implemented.Chief programmers are the owners of business activities. They are assigned considering the development sequence , dependencies between features in terms of classes involved , balancing load across class owners , complexity of the features to be implemented.The planning team can assign developers as class owners. Developers may own multiple classes.OutcomeBusiness activities with completion datesChief programmers assigned to business activitiesSubject areas with completion datesThe list of classes and the developers that own them4. Design By FeatureThe features that need to be developed can be assigned to the Chief Programmer. The Chief Programmer selects features for development from the assigned features. He can choose multiple features which use the same classes.The Chief Programmer forms a Feature Team by identifying the owners of the classes likely to be involved in the development of the features which was selected for development. Then the team produces the Sequence Diagrams for the features. The Chief Programmer refines theObject Model based on the sequence diagrams.Outcome Successfully inspected Design Package.( The design package includes a covering memo, or paper, that integrates and describes the design package)5. Build By FeatureThe development class owners implement the items necessary for their class to support the design for the feature. Once the code is developed, carry on unit testing and code inspection. After a successful code inspection, the code can be build.OutcomeSuccessfully code inspected classes and/or methodsClasses that have been promoted to the build.Usage of FDD Ideal for systems where their business changes so rapidly and for long time projects For web design and development projects To build and design software For Enterprise using ALM (application lifecycle management) solutionsAdvantages of FDD1. Lads to move to large projects and obtain repeatable success.2. Practicing the five processes helps to bring new staff in with a shorter ramp-up time.3. Feature-Driven Development is built around a core set of industry-recognized best practicesRegular Builds- Regular builds ensure there is always an up to date system that can be demonstrated to the client and helps highlighting integration errors of source code for the features early.Visbility of progress and results- By frequent, appropriate, and accurate progress reporting at all levels inside and outside the project, based on completed work, managers are helped at steering a project correctly.4. Risk Reduction via iteration of design & build in small chunks.FDD helps in reducing risks using shorter iterations of designing, understanding of the requirements and the system- in a clear and distinct way, thereby leading to a state where there are no ambiguities, as the needs and expectations are already understood very well.5. Clarity of requirements and better understanding of system to be built is gained through the Develop Overall Model process. This process includes high-level walkthrough of the scope of the system and its context. Next, detailed domain walkthroughs are held for each modeling area.6. Costing the project by feature leads to greater accuracy.Disadvantages of FDD1. Not as powerful on smaller projects (ie, one developer, only one person modeling)2. High reliance on chief programmer. He act as coordinator, lead designer, and mentor.3. No written documentation.

RecommendationIn comparing all the possible methodology, we believe Extreme Programming is the most suitable. The nature of project and product that is undertaken by the organization can manage by using this method. Based on the product and project, customers involvement is considered as priority. Apart from that the products also require constant update and new feature to stay relevant in market. Constant engaging the customers could reduce errors during project as well. A better team work and coordination within the organization can be achieved using this methodology. Cost management is better, as this methodology do not work on fix price. Price are determined based on the work completed and amount of effort that is being used.This methodology could help the organization to have a better relationship with client, managing project and product better, improve team performance as well as managing the cost of the project in a better way.