1. Unleashed

2. Contents Rationale Existing categories Why About Agile Agile Mothodologies The chosen one Whats next 3. Categories of Dev. methods Code and Fix No process at all Development is chaotic and unplanned Serial Software processes are well defined and detailed Developers are expected to follow in serial manner Waterfall Process / Big design up front (BDUF) Quarter length releases Iterative Software processes are well defined and detailed Developers are expected to follow in an iterative manner Short release cycles weeks / months Agile Software processes are defined at high-level People oriented approach Enables people to respond effectively to change Short release cycles weeks / moths 4. Why Who are we Small team of programmers without Designers, Tester or full time project manager In most cases the requirements are general and not fully defined Why not Serial or Iterative methods Often development of small IT software for which full scale design is too time consuming Usually short TTM (Time to market) needed Why and when yes Code and Fix For the really small project when first and in short period of time a prototype needed as a POC (Proof of Concept) When only one developer involved Why and when yes Agile High-level design is needed to begin developing When several team-members involved in development First prototype release version can be quickly presented to the client Adaptive to changes in clients requirements as the projects developes 5. About Agile WTF? "Agile Development" is an umbrella term for several iterative and incremental software development methodologies. The most popular agile methodologies include Extreme Programming (XP) Scrum Crystal Clear Dynamic Systems Development Method (DSDM) Lean Development Feature-Driven Development (FDD) While each of the agile methods is unique in its specific approach, they all share a common vision and core value (Agile Manifesto) They all fundamentally incorporate Iteration and continuous feedback Lightweight Rapid and flexible respond to change All focus on empowering people to collaborate and make decisions together quickly and effectively 6. About Agile WTF? 7. About Agile - Characteristics Agile methods break tasks into small increments with minimal planning Iterations are short time frames that typically last from one to four weeks Each iteration involves a team working through a full software development cycle Multiple iterations might be required to release a product or new features. Team members decide individually how to meet an iteration's requirements Agile methods emphasize face-to-face communication over written documents Each agile team will contain a customer representative which available for developers to answer mid-iteration questions Most agile implementations use a routine and formal daily face-to-face communication among team members (Stand-ups) TDD - Test Driven Development 8. Agile Methodologies - XP Intended to improve software quality and responsiveness to changing customer requirements Frequent "releases" in short development cycles Improve productivity and introduce checkpoints where new customer requirements can be adopted Elements of XP: Programming in pairs Extensive code review Unit testing Avoiding programming of features until they are needed Flat management structure Simplicity and clarity in code Expecting changes in customer requirements Frequent communication with the customer and among programmers 9. Extreme Programming Model 10. Agile Methodologies - Scrum A product owner creates a prioritized wish list called a product backlog. During sprint planning, the team pulls a small chunk from the top of that wishlist, a sprint backlog, and decides how to implement those pieces. The team has a certain amount of time, a sprint, to complete its work - usually two to four weeks - but meets each day to assess its progress (daily scrum). Along the way, the ScrumMaster keeps the team focused on its goal. At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder. The sprint ends with a sprint review and retrospective. As the next sprint begins, the team chooses another chunk of the product backlog and begins working again. 11. Scrum cycle 12. Agile Methodologies Crystal Clear One of the most lightweight, adaptable approaches to software development Actually a family of methodologies (Crystal Clear, Crystal Yellow, Crystal Orange, etc.) whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the projects unique characteristics. Several of the key tenets of Crystal include teamwork, communication, and simplicity, as well as reflection to frequently adjust and improve the process Alistair Cockburn 13. Agile Methodologies - DSDM Dynamic Systems Development Method Iterative and incremental approach that embraces principles of Agile development Fixes cost, quality and time Uses MoSCoW prioritisation (musts, shoulds, coulds and won't haves) to meet the stated time constraint 14. DSDM - Model 15. Agile Methodologies Lean Development (Kanban) The term "kanban" is Japanese (), derived from roots which literally translate as "visual board". Borrowed from the Toyota Production System, where it designates a system to control the inventory levels of various parts. It is analogous to (and in fact inspired by) cards placed behind products on supermarket shelves to signal "out of stock" items and trigger a resupply "just in time". The Toyota system affords a precise accounting of inventory or "work in process", and strives for a reduction of inventory levels, considered wasteful and harmful to performance. Approach to continuous improvement which relies on visualizing the current system of work scheduling, managing "flow" as the primary measure of performance, and whole-system optimization - as a process improvement approach, it does not prescribe any particular practices. can be considered first for efforts involving maintenance or ongoing evolution (In particular of more than one products. The boards must have WIP (Work in Progress) limits 16. Kanban Board Example 17. Agile Methodologies - FDD Develop overall model High-level walkthrough of the scope of the system and its context Then detailed domain walkthroughs for each modeling area Then merge into an overall model Build feature list Feature list derived from the model above Plan by feature Produce development plan by deviding feature sets to chief programmers Design by feature Design package for each feature (Description, referenced reqs., sequence diagrams, design alternatives, object model, task list) Hold design inspections Build by feature Code for the designs above After unit-tests and code inspections the completed feature is to be promoted to the main build 18. Whats next? 19. Comparing Methodologies 20. Comparing Methodologies 21. Comparing Methodologies StrengthsWeaknesses XP Strong technical practices. Customer ownership of feature priority, developer ownership of estimates. Frequent feedback opportunities. Most widely known and adopted approach, at least in the U.S. Requires onsite customer. Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation. Difficult for new adopters to determine how to accommodate architectural and design concerns. Scrum Complements existing practices. Self organizing teams and feedback. Customer participation and steering. Priorities based on business value. Only approach here that has a certification process. Only provides project management support, other disciplines are out of scope. Does not specify technical practices. Can take some time to get the business to provide unique priorities for each requirement. Lean Complements existing practices. Focuses on project ROI. Eliminates all project waste. Cross-functional teams. Does not specify technical practices. Requires constant gathering of metrics which may be difficult for some environments to accommodate. Theory of Constraints can be a complex and difficult aspect to adopt. FDD Supports multiple teams working in parallel. All aspects of a project tracked by feature. Design by feature and build by feature aspects are easy to understand and adopt. Scales to large teams or projects well. Promotes individual code ownership as opposed to shared/team ownership. Iterations are not as well defined by the process as other Agile methodologies. The model-centric aspects can have huge impacts when working on existing systems that have no models. 22. Comparing Methodologies StrengthsWeaknesses AUP Robust methodology with many artifacts and disciplines to choose from. Scales up very well. Documentation helps communicate in distributed environments. Priorities set based on highest risk. Risk can be a business or technical risk. Higher levels of ceremony may be a hindrance in smaller projects. Minimal attention to team dynamics. Documentation is much more formal than most approaches mentioned here. Crystal Family of methodologies designed to scale by project size and criticality. Only methodology that specifically accounts for life critical projects. As project size grows, cross-functional teams are utilized to ensure consistency. The "human" component has been considered for every aspect of the project support structure. An emphasis on testing is so strong that at least one tester is expected to be on each project team. Expects all team members to be co-located. May not work well for distributed teams. Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality. Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible. DSDM An emphasis on testing is so strong that at least one tester is expected to be on each project team. Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable. Has specific approach to determining how important each requirement is to an iteration. Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable. Probably the most heavyweight project compared in this survey. Expects continuous user involvement. Defines several artifacts and work products for each phase of the project; heavier documentation. Access to material is controlled by a Consortium, and fees may be charged just to access the reference material. 23. Scrum vs XP Scrum and Extreme Programming (XP) are definitely very aligned: Short iterations Customer involvement Daily stand-up meetings The main conceptual differences scrum emphasizes the management side of a project and does not define a detail engineering practice. XP specify the software engineering practices such as test-driven development, refactoring, pair programming, simple design, etc. Scrum does not allow requirements changes during the sprint whilst XP supports any change at any stage. Most recommendations are to start with Scrum and as the teem advances and gains agile experience adopt practices from XP So. 24. Scrum - Defined Roles Product owner: responsible for the business value of the project Scrum Master: ensures that the team is functional and productive Team: self-organizes to get the work done Artifacts Product backlog: prioritized list of desired project outcomes/features Sprint backlog: set of work from the product backlog that the team agrees to complete in a sprint, broken into tasks Burndown chart: at-a-glance look at the work remaining (can have two charts: one for the sprint and one for the overall project) Ceremonies Sprint planning: the team meets with the product owner to choose a set of work to deliver during a sprint Daily scrum: the team meets each day to share struggles and progress (15 minutes) Sprint reviews: the team demonstrates to the product owner what it has completed during the sprint Sprint retrospectives: the team looks for ways to improve the product and the process. 25. Scrum Order of things Plan the project Build the project backlog Technical and learning tasks are also part of the backlog (i.e explore .net 4 cababilities, create the development environment ) Determine team velocity How many story points can be completed in one iteration (sprint) Establish the release plan Group user stories in groups that provide a releasable version Determine in which sprints those user stories will be completed Prepare for the first sprint prepare the product backlog Break the user stories down into smaller stories Provide details about the user stories that the team will need to break the stories down into tasks. Backlog Example2 26. Scrum Order of things Plan a Sprint Sprint planning meeting - Team commits to completing the chosen items from the backlog Choose user stories to be implemented in the sprint Tasks Identify the tasks Evaluate each task (hours) 27. Scrum Order of things Run a Sprint Complete selected user stories The sprint is of constant length 2 to 4 weeks, the length of the sprint cannot be changed Track sprint progress burndown report Finish the sprint Make sure user stories completed After the customer review, the team will hold a retrospective meeting to improve the process 28. Scrum Order of things Track the project As sprints are advancing, customers develop a better understanding of their remaining needs, and changes in the backlog will happen. Prepare for the next sprint Update the user stories and their priorities as customers' needs change. Break down user stories that are likely to be implemented in the next sprint. 29. Scrum Order of things Track the project Track Release Progress As the project proceeds from sprint to sprint, your team will track the overall progress toward the next release Finish the Release Hold review retrospective meetings with the customer to examine the process 30. So whats in our case Mercury Rod User stories exist Build the backlog Project planning meeting scheduled next week (Backlog review, understand priorities, Estimate cost) Sprint planning meeting the on the next 2 days (Build sprint backlog including tasks) Will use visual studio ALM to manage the project DOCUMENT YOUT CODE 31. The END.. 32. Ponders Architectural aspects in the backlog? Backlog examples Prepare the working environment Continuous integration Acceptance tests Gute Multiple tasks management Code Reviews