Agile Doc.doc

• • • •

Agile methodology is an approach to project management Agile methods attempt to minimize risk and maximize productivity by developing software in short iterations Scrum is a simple approach to the management of complex problems, providing a framework to support innovation and allow development teams to deliver high quality product in short time-frames. Scrum is a way of thinking that unleashes the creative spirit

Empiricism refers to the continuous inspect/adapt process that allows both workers and managers to make decisions in real time, based on actual data, and as a result respond quickly to ever-changing conditions in the surrounding environment, most importantly the market place in which the software is sold or distributed. Emergence results from an empirical approach. It implies that all solutions to all problems will become clear as we work. They will not become clear if we simply talk about them. Big Up Front Design will only result in Big Wrong Design or at best Big Working But Totally Inflexible Design. When we allow solutions to emerge it is always the simplest and the most appropriate solution for the current context that rises to the surface. Emergence coupled with Empiricism will lead us to the most appropriate and the most flexible (i.e. changeable) solution. Self-organization refers to the structure of the teams creating the product of work. Small multidisciplinary teams are empowered to make the important decisions necessary to i) create high quality product and ii) manage their own processes. The thinking here is that those doing the work know best how to do the work. These teams work in a highly interactive and generative way, emerging the product through continuous dialog, exploration and iteration. Self-organization works when there are clear goals and clear boundaries. In addition to these principles Scrum relies on two core mechanisms: prioritization and timeboxing. Prioritization simply means that some things are more important than others. This is obvious, yet quickly forgotten when the “we need it all now” mindset is entered. Scrum helps put the focus back on selecting the most important things to do first — and then actually doing them! Making time to prioritize, and being rigorous about it are essential to the success of Scrum. Timeboxing is a simple mechanism for handling complexity. We can’t figure out the whole system at this time, so let’s take one small problem and in a short space of time, say one week or one month, figure out how to solve that problem. The results of that will then guide us towards a solution for the next, bigger problem and give us insight into the needs of the system as a whole. Agile methodologies Extreme Programming It is a programmer-centric methodology that emphasizes technical practices to promote skilful development through frequent delivery of

working software. XP is characterized as less rigorous then traditional techniques.XP got its name when its founders asked the question, "what would happen if we took each technique/practice and performed it to the extreme? How would that affect the software process?" An example of this is the practice of code reviews. If code reviews are good, then doing constant code reviews would be extreme; but would it be better? This led to practices such as pair programming and refactoring, which encourage the development of simple, effective designs, oriented in a way that optimizes business value. In truth, full adoption of all of XP's practices requires a high level of discipline, teamwork, and skill. One of the characteristic distinctions between XP and other methodologies is its cycle time and level of ceremony. XP recommends very short iterations between one and four weeks. XP is also a very low ceremony methodology. Minimal artifacts in an XP project include story cards, code, and unit tests.

But XP is most commonly known for its technical practices. At the heart of XP are four core values: communication, simplicity, feedback, and courage. From these values 13 practices are derived. Theses practices are: 1. Planning Game: Plan work incrementally. 2. Small Releases: Release as quickly as possible to increase time to market, and get feedback as soon as possible. 3. Metaphor: If possible, define a metaphor for the system being developed. For example, the shopping cart metaphor is widely used to describe an online ordering system. 4. Simple Design: Use the simplest design that will work for the functionality (user story) being implemented. Do not design for things that may never actually be used. 5. Testing: Test everything, and try to automate the testing if possible. 6. Refactoring: Instead of designing the entire system up front, design as you go, making improvements as needed. Change the implementation without changing the interface to the functionality, and use automated testing to determine the impact of the refactoring. 7. Pair Programming: Programming in teams of two (or three) allow for a discussion to occur in real-time that addresses requirement, design, testing, and programming concerns. 8. Collective Code Ownership: Anyone on the team can make a change to any code at any time. 9. Continuous Integration: The entire code base is constantly being rebuilt, and retested in an automated fashion. 10. Sustainable Pace: Ideally, team members do not need to work more than 40 hours per week to meet project deadlines. Burning the midnight oil is chunked by management in favor of consistent, predictable, repeatable delivery. 11. Whole Team: The team functions as a whole. Members are encouraged to be more generalized than specialized. Learning about all technologies and requirements is encouraged. 12. Coding Standards: In order to maximize communication, coding standards are defined by the team, and used to ensure consistent coding practices.

13. Onsite Customer: Having constant and direct access to the customer allows the team to work at the fastest possible speed. These practices support one another, as illustrated in Figure 1, and thus care should be taken when modifying any of them, or deciding not to include one or more of these practices in a project. Another distinction between XP and other Agile methodologies is its approach to requirements gathering. The primary requirement artifact in Figure 1. XP Practices. The practices in XP support one XP is the user story. Visibly, a user story is another and thus care should be nothing more than a note card with a short taken to understand these description on it. But user stories actually are relationships when modifying XP. comprised of the card (reminder of promised functionality), conversations between developers and requirements donors, and tests (all types: unit, integration, acceptance, etc.). There are two primary types of planning activities that are referred to in XP parlance as planning games: the release and iteration planning games. And each planning game is characterized by three phases: exploration, commitment, and steering. Release planning begins with the customer writing story cards and prioritizing them. Programmers then estimate the stories from which a velocity can be derived. Velocity describes how much work the team can accomplish in any given time frame. The customer then chooses a scope for the release based either on desired functionality or release date. The steering activities for release planning occur at iteration boundaries when progress towards the planned release date can be tracked and adjustments can be easily made. Iteration planning follows a similar pattern to release planning. Each iteration begins with developers taking stories and breaking them into tasks. Programmers accept responsibility for tasks and estimating the tasks that they are responsible for. Each programmer's load is compared to their historical performance to determine whether anyone is overcommitted and to allow the workload to be balanced across the team. Throughout the iteration programmers partner to complete tasks by writing unit tests and code. Periodically throughout the iteration a member of the team checks on the progress of the team and communicates this information to all team members so adjustments can be made. There are a small number of roles on an XP project. These include: •

•

Customer—The customer creates and prioritizes the stories that need to be implemented. Because the customer sets the priorities she controls what will be delivered in any given release and can control the release date by adding and removing stories. Programmer—Programmers collectively estimate stories, but individually accept responsibility for tasks which they estimate, write tests, and code.

•

•

Coach—The coach monitors the software development process, mentors team members on XP process and techniques, and focuses the team's attention on potential problems or optimizations. Tracker—The tracker monitors the progress of the team and alerts them when adjustments to the schedule or a re-balancing of tasks might be required.

Scrum: is a mechanism to restart the game after an accidental infraction - such as the ball going out of bounds. It's the general idea of a team huddling together to move the ball toward the goal.

Scrum is a project management framework for managing Agile projects. Its primary goal is to deliver software that, after each and every iteration, provides the highest business value. Scrum is based on a 30-day iteration called a "Sprint." Technically Sprints can be either two or four weeks, but the generally accepted default is usually four weeks. A fundamental Scrum principal is that project teams should be self organizing. This means that team members don't follow a prescriptive plan or set of tasks, but organize themselves initially based on the goals for the Sprint, and subsequently on a daily basis through daily scrum meetings. Recommended team size is from four to nine members. Every day at the same time, the project team meets to discuss the project. Members are expected to stand during the entire meeting to encourage short meetings. Meetings are targeted to complete in 10 to 15 minutes. Each member in turn answers three questions: 1. What did I do since the last Scrum meeting? 2. What do I plan on doing between now and the next Scrum meeting? 3. Do I have any roadblocks? Scrum also defines only a small numbers of roles on the team: Product Owner—The Product Owner is responsible for representing the customer or user of the product the team is building. Ideally this is the actual customer, but when the customer is not available for a project, this role is filled by someone representing the customer's interests; he or she is also responsible for being the liaison between the project team and the customer. Scrum Master—Scrum originated as a way to deal with troubled or emergency projects. The person brought in to refocus the project team is called a Scrum Master. This role is primarily to facilitate, report, and focus the team on the highest priority work and to remove any roadblocks that may impede team progress. Certification training for Scrum Masters exists, supporting three different levels of practice.

Team Member—All other members of the team are considered general team members. This includes developers, architects, project managers, testers, database administrators—everyone. The team concept is important to Scrum and only the key roles of Scrum Master and Product Owner are called out. Daily Scrum key point : An agile process to manage and control development work. Can be used to wrap existing software engineering practices. A team-based approach designed to iteratively and incrementally develop systems when requirements change rapidly Controls the chaos of conflicting interests and needs. Improves communication and maximizes cooperation. By design, Scrum helps the team detect and remove obstacles that get in the way of developing and delivering products. Is scalable from single projects to entire organizations. The Scrum lifecycle is organized by brief development iterations called Sprints.

Lean Software Development While most of us might joke that Lean Software Development (a.k.a.: Lean) is a new way to lose unwanted pounds and keep them off, that wouldn't be far from the truth. Lean is a methodology that aims to trim the fat from the software process, starting with requirements, and including how business looks at the systems they request. Lean Software Development promotes seven Lean principles. The methodology revolves around these principles, and all other aspects of Lean are designed to reinforce them. The seven principles are: 1. Eliminate Waste: Eliminate anything that does not add customer value. 2. Build Quality In: Validate and re-validate all assumptions throughout the process. If a metric or practice no longer has value, discard it. 3. Create Knowledge: Use short iterative cycles to provide quick, constant feedback to ensure the right things are being focused on. 4. Defer Commitment: Don't make decisions until enough is known to make the decision—a sound understanding of the problem and the tradeoffs of potential solutions is required. 5. Deliver Fast: Minimize the time it takes to identify a business problem and deliver a system (or feature) that addresses it. (a.k.a. time to market). 6. Respect People: Empower the team to succeed. 7. Optimize the Whole: Use cross-functional teams to keep from missing important, possibly critical aspects of the problem and of the system designed to solve it.

Feature Driven Development Feature Driven Development (FDD) is the domain model. Creating a model of the domain is the foundational step for FDD, which requires collecting domain knowledge from all domain experts (SMEs), and integrating this knowledge into a unified model representing the problem domain. Once this model and any other requirements have been evaluated, a rough plan is drawn up to determine what resources will be needed to build the masterpiece. A small set of features are identified for a team to work on for a period of time recommended to last no more than two weeks. Once the initial set of features is delivered, another set is tackled. Multiple teams can work in parallel on different sets of features, with all activity being tracked on a per feature basis. FDD specifies five specific processes that are to be followed, in this specific order: 1. 2. 3. 4. 5.

Develop an Overall Model Build a List of Features Plan by Feature Design by Feature Build by Feature

FDD relies on specific roles and responsibilities more than almost any other Agile methodology. FDD also tends to move away from shared ownership of code and artifacts that other Agile methods promote, and the team roles reflect this. The nine roles defined for FDD are: 1. Project Manager—Responsible for all administrative aspects of the project, including the financial and reporting ones. 2. Chief Architect—Responsible for the overall design of the system, including running all design sessions, code reviews, and technology decisions. 3. Development Manager—On the hook for the daily development activities. Coordinating the development team and their activities, and dealing with resource issues. 4. Chief Programmer—A senior developer involved in ongoing design and development activities, and is assigned to be responsible for one or more Feature Sets. 5. Class Owner—A developer who works under the direction of a Chief Programmer to design, code, test, and document features as they are implemented. 6. Domain Expert—Any business related stakeholder who can define required features that the system should provide. These would include clients, users, and various analysts; anyone who has knowledge of how the business works that could impact the system. 7. Tester—Responsible for verifying that each feature performs as defined. 8. Deployer—Deals with not only the actual deployment of code to various environments, but also the definition and/or conversion of data from one format to another. 9. Technical Writer—Responsible for creating and maintaining all the online and printed documentation that a user will need for the final system.

Capturing exactly where a feature is in its development cycle is done using a table that tracks six specific milestones: 1. 2. 3. 4. 5. 6.

Domain Walkthough Design Design Inspection Code Code Inspection Promote to Build

These milestones are tracked by the date each is completed and by the Chief Programmer responsible for that specific feature.

Why Agile? Agile development methodology attempts to provide many opportunities to assess the direction of a project throughout the development lifecycle. This is achieved through regular cadences of work, known as sprints or iterations, at the end of which teams must present a shippable increment of work. Thus by focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology could be described as “iterative” and “incremental.” In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development — requirements, design, etc. — is continually revisited throughout the lifecycle. When a team stops and re-evaluates the direction of a project every two weeks, there’s always time to steer it in another direction.

The results of this “inspect-and-adapt” approach to development greatly reduce both development costs and time to market. Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as “analysis paralysis” can’t really impede a team from making progress. And because a team’s work cycle is limited to two weeks, it gives stakeholders recurring opportunities to calibrate releases for success in the real world. In essence, it could be said that the agile development methodology helps companies build the right product. Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace. In the end, a development agile methodology that preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released, is an attractive option for stakeholders and developers alike.