Mais conteúdo relacionado

Apresentações para você(20)


Agile Development unleashed

  1. Unleashed
  2. Contents  Rationale  Existing categories  Why  About Agile  Agile Mothodologies  The chosen one  What’s 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 project’s 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. What’s 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 what’s 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