Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile Software Development at UPT DEGI | 5th of Dec 2016


Published on

Seminar Talk at UPT DEGI | 5th of Dec 2016 about Agile Software Development (Framework, Systems and Evolution)

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Agile Software Development at UPT DEGI | 5th of Dec 2016

  1. 1. Agile So)ware Development (Framework, Systems and Evolu<on) by Eduardo Ribeiro V 2.0
  2. 2. Yes, these are ugly slides!
  3. 3. Everything starts with an Idea
  4. 4. What is Agile “Agile is an “itera<ve” and “incremental” so)ware development methodology were its main focus is on client sa<sfac<on through con<nuous delivery.”
  5. 5. Agile Manifesto
  6. 6. 12 Principles behind the Agile Manifesto •  Our highest priority is to sa#sfy the customer through early and con#nuous delivery of valuable so)ware. •  Welcome changing requirements, even late in development. Agile processes harness change for the customer's compe<<ve advantage. •  Deliver working so)ware frequently, from a couple of weeks to a couple of months, with a preference to the shorter #mescale. •  Business people and developers must work together daily throughout the project. •  Build projects around mo#vated individuals. Give them the environment and support they need, and trust them to get the job done. •  The most efficient and effec<ve method of conveying informa<on to and within a development team is face-to-face conversa#on. •  Working so:ware is the primary measure of progress. •  Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. •  Con<nuous aZen<on to technical excellence and good design enhances agility. •  Simplicity the art of maximizing the amount of work not done is essen<al. •  The best architectures, requirements, and designs emerge from self-organizing teams. •  At regular intervals, the team reflects on how to become more effec#ve, then tunes and adjusts its behavior accordingly.
  7. 7. Tradi<onal vs. Agile
  8. 8. Agile Umbrella Crystal Clear Feature Driven Development (FDD) Dynamic System Development Method (DSDM) Lean So:ware Development Kanban Scrum Extreme Programming (XP) Adap#ve So:ware Development (ASD) Behavior Driven Development (BDD)
  9. 9. Why we use (or should use) it? •  Reduced risk •  Earlier ROI/ value •  Increased visibility of progress •  Increased predictability •  Increased produc<vity •  Reduced waste •  More produc<ve & happy teams
  10. 10. What is Scrum?
  11. 11. Incremental != Itera<ve
  13. 13. Empirical Process Control Transparency: •  Transparency allows all facets of any Scrum process to be observed by anyone. Inspec#on: •  Use of a common Scrum Board and other informa<on radiators. Adapta#on: •  Adapta<on happens as the Scrum Core Team and Stakeholders learn through transparency and inspec<on and then adapt by making improvements in the work they are doing.
  14. 14. Self-Organiza<on
  15. 15. Collabora<on
  16. 16. Value Base-Priori<za<on
  17. 17. Time-Boxing
  18. 18. Itera<ve Development
  19. 19. Values •  Focus - Because we focus on only a few things at a <me, we work well together and produce excellent work. We deliver valuable items sooner. •  Courage - Because we work as a team, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges. •  Openness - As we work together, we express how we're doing, what's in our way, and our concerns so they can be addressed. •  Commitment - Because we have great control over our own des<ny, we are more commiZed to success. •  Respect - As we work together, sharing successes and failures, we come to respect each other and to help each other become worthy of respect.
  20. 20. TEAM & ROLES Scrum
  21. 21. Scrum Team
  22. 22. Scrum Master
  23. 23. Product Owner
  24. 24. CEREMONIES Scrum
  25. 25. Grooming the Product Backlog
  26. 26. Sprint Planning
  27. 27. Daily Stand Up
  28. 28. Sprint Review or Demo & Retrospec<ve
  29. 29. PROCESS Scrum
  30. 30. Scrum Framework
  31. 31. ARTIFACTS Scrum
  32. 32. User Stories Context As a … (user of the system) I want … (feature or problem to be solved) So that … (benefit of story being completed) The “so that” part is incredibly valuable as it focuses people on the real reason behind this story.
  33. 33. INVEST Acronym
  34. 34. Why we Es<mate?
  35. 35. Poker Planning
  36. 36. DOD AND DOR Scrum
  37. 37. Defini<on of Done aka DoD •  The team agrees on, and displays prominently somewhere in the team room, a list of criteria which must be met before a product increment "o)en a user story" is considered "done". •  On a feature level, the acceptance criteria should be agreed up front BEFORE the User Story is submiZed to acceptance.
  38. 38. Defini<on of Ready aka DoR •  By analogy with the "Defini<on of Done", the team makes explicit and visible the criteria (generally based on the INVEST matrix) that a user story must meet prior to being accepted into the upcoming itera<on. •  On a feature level, the acceptance criteria should be agreed up front BEFORE code is wriZen.
  39. 39. Visibility of Progress •  Team has a duty to radiate informa<on outwards! •  It also helps reduce interrup<ons! –  Scrum and Kanban Physical Boards –  Big visible charts (Ex: CFS’s, Burn Down, Etc) –  On-line Tools (Ex: Rally Dev) –  Daily repor<ng
  40. 40. Examples
  41. 41. Kanban
  42. 42. Why should we have a WIP?
  43. 43. Evolu<on - Scrumban
  44. 44. Thank you! Any ques<on?