Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Are Agile Projects Doomed To Halfbaked Design
Semelhante a Are Agile Projects Doomed To Halfbaked Design (20)
Mais de eraz
Mais de eraz (20)
Último
Último (20)
Are Agile Projects Doomed To Halfbaked Design
- 1. Are Agile Projects Doomed to HalfBaked Design? Alex Chaffee alex@PivotalLabs.com Leslie Chicoine leslie@GetSatisfaction.com
- 3. Web 2.0 = ?
- 7. Design Methods Graphics Information Architecture User Flow Concepts User Centered Strategy Design Front End Coding Research User Interface Interactive Interaction
- 9. Design Methods Thought Modeling Research I design. Play Communication Redesign
- 11. Coding Methods Scripting Databases CSS Ruby UML Diagrams Design JavaScript Patterns Coding Deploying IDEs Java Research Debugging Best ObjectOriented Practices Design Perl ModelView Version Control Controller
- 13. Coding Methods Thought Modeling Research I code. Play Communication Redesign
- 14. The Big Idea “Design is finding the problem, not the solution.” —Leslie Chicoine
- 15. The hard problems are… • people problems – (mis) communication – (not enough) feedback – (not fully) comprehending constraints • process problems – deadline and resource management – design flexibility in the face of frequent change Where can we find a peopleoriented process, and process oriented people?
- 16. XP Defined Extreme Programming is an Agile Process – Motto: Embrace Change – Other Agile Processes include Scrum, Crystal Clear, Adaptive Software Development, Feature Driven Development, DSDM, Agile Modeling
- 17. XP Defined Extreme Programming is an Agile Process • Values §Feedback §Communication §Simplicity §Courage
- 18. Collective XP Practices ”Ask the room” Ownership Continuous frequent Integration spontaneous working sessions retrospectives Pairing testing XP Continuous Practices simple design Improvement refactoring High code quality Weekly demos Suggest and agree to process changes Incremental design, Onsite Customer Sustainable Pace development, deployment design by discussion “Don’t be stupid.”
- 19. XP Cycles XP Cycles – Rapid Iteration, small releases – Frequent planning/design sessions • Iteration Planning, Release Planning • Break down requirements into stories into tasks • Daily Standup • Regular AllHands Retrospectives – Frequent (weekly) demos • of deployed, 100% functional software • real code, real db, real ui, but only some of the stories • coders, clients, designers, PMs are all in the room
- 20. XP Meets Waterfall Design Extreme Waterfall Programming Design
- 21. XP Meets Waterfall Design Extreme Programming Waterfall Design
- 23. XP Staples • The three things we do in XP that any team should do § Weekly demos § Daily standups § Pairing Caution: May provoke resistance and hostility
- 27. Agile Design
- 28. Agile Design
- 32. Scales of Design Large Scale Concept Business Goals User Tasks / Motivations Site Flow & Wayfinding Supporting Systems Navigation Widgets Global Styles Language Buttons Graphics Small Scale Fonts
- 38. Scales of Design Large Scale Concept Business Goals User Tasks / Motivations Site Flow & Wayfinding Supporting Systems Navigation Widgets Global Styles Language Buttons Graphics Small Scale Fonts
- 49. Scales of Open Design Large Scale Concept Business Goals User Tasks / Motivations Site Flow & Wayfinding Supporting Systems Navigation Widgets Global Styles Language Buttons Graphics Small Scale Fonts
- 50. Open Design
- 51. Open Design
- 52. Open Design
- 54. Designers should… • Design a week in advance of coding • Not make your mockups pixelperfect • Work literally sidebyside with coders when implementing mockups • Allow coders to participate in IA/UI design — Especially after the coding has already started
- 55. Coders should… • Coders should ask designers… or else – time is wasted reworking solved issues – solutions are implemented that don't work with other parts of the designed system – coders make assumptions based on mockups • Coders should give frequent live demos… or else – designers don't know what parts of the design are/aren't working – designers don't know what parts of the design aren't working together – coders don't know their code has bugs or needs tweaking
- 56. How to integrate with an outside design company? • Communication and feedback are naturally more stretched out • Some unnatural (or at least unAgile) barriers are imposed – Time and space – Signoff procedures – Documentation / specs – Perfectionism – Mistrust • Bring them in to your process as much as you can • Don’t force them to adapt too much or they’ll resent and demonize you • Iterate permonth at first, then perweek • Invite them to your demos (remotely if need be)