• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Managing xp

Managing xp






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Managing xp Managing xp Presentation Transcript

    • Mythical XP- Dealing with XP Rules, Myths, Anti-Patterns and Controversies Ravi Tadwalkar and Max Spring 10-July-2012Abstract:How does one apply XP?This interactive workshop is about XP Rules, Myths, Anti-Patterns and Controversies agilists "deal" with.If we understand XP myths and bust them, we will learn how to apply XP at the core of your corporate process!
    • Agenda● Business Case for XP● Scope of XP Myths: Categories ○ Managing (the process): "Team Room" ○ Designing: "Model Driven Architecture" ○ Coding: "Ownership" ○ Testing: "Test Automation" ○ Planning (the product): "Small Releases"● Q&A
    • Business Case for XP● How to apply XP at the core of traditional waterfall, RUP, agile/scrum or lean/kanban processes? ○ XP best practices are like a color palette, once you learn what each color in the palette means to you, you can mix and match what works. ○ XP just appears heavyweight, so phase it in. It’s like weight training. XP is spectrum of practices.● XP is a continuum, in that we need to apply XP rules to todays context● XP from a newcomer’s perspective can involve myths that can come out of not having exposure to XP rules
    • Scope of XP Myths: Categories Managing: team room Coding: Ownership Testing: Automation Designing: MDAPlanning:small releases sources: http://www.extremeprogramming.org/rules.html http://xprogramming.com/what-is-extreme-programming
    • Managing (the process): "Team Room"● What is a team room? ○ A room for "Whole Team" for collaboration
    • Team RoomMyth: "Team room does not work for us, since I cannot be sure a) whether people are really working, or b) people are doing private work."This functional manager called for yet another all-hands.Team is fuming over too many and too long meetings. ● Micro-management ● Lack of mutual trust ● Not knowing team/project state causes anxiety
    • Team Room● A better visualization or materialization of this state would be helpful● Team room can be remedy for underlying trust factor● Team room enables transparent view of all agile artifacts to all team members and stakeholders● Human brain mapping capability ○ spatial ○ persistent ○ tactile
    • Team Room● Large companies create “model team-room" ○ Not just a small “lean startup” aspect anymore● Colored Sticky Notes● Geo-distribution ○ cameras (for TP sessions) ○ Wikis ○ Google Docs (shared editing)● Multi-purpose room ○ gamestorming supplements brainstorming ○ highlight impediments / blockers / obstacles
    • More "Managing" myths● XP is only for engineers● Scrum/Kanban can live without XP● Standup meetings do not work for us, we need MoM (minutes of meetings)● Moving people around cannot work, because we need IC (individual contributors)
    • Scope of XP Myths: Categories Designing: MDAsources: http://www.extremeprogramming.org/rules.html http://xprogramming.com/what-is-extreme-programming
    • Design (the product): "MDA"● MDA - Model-Driven Architecture ○ Single Point of Truth (SPOT)● Domain model● System metaphor ○ orthogonal to domain model
    • MDA (Model Driven Arch.)Myth: "MDA takes too much time." ○ Domain knowledge hardcoded all over the place ○ Often in scripting environments ○ Lack of consistent domain terminology i.e. (lack of glossary) ○ Inadequate architecture ■ Pieces of architectural "views" exist ○ MDA is BDUF? (big design upfront)
    • MDA - Done Right● More emphasis on tool chain● The earlier, the better: start introducing an explicit domain model early on● Even if late: start introducing a small abstract model with concrete mappings into your existing system ○ model should be an ever-growing SPOT!
    • MDA - Done Right● Have a true Architecture Driven by Model(s)● Ideal scenario: Product roadmapping is a starting point● Avoid (yet another) worst case scenario of being "late"● Just another layer of an "inside-out" approach
    • More "Designing" myths● We refactor our codebase at the end, after code reviews● “Simplicity rule for us works this way”: ○ We implement specialized optimizations early on- knowing that this may end up optimizing “algo” despite usage pattern● Spike solutions need to be managed just like any other engineering work or contract, a spike is used for more than just doing “feasibility study”!
    • Scope of XP Myths: Categories Testing: Automationsources: http://www.extremeprogramming.org/rules.html http://xprogramming.com/what-is-extreme-programming
    • Test AutomationMyth: "Automated tests are impossible for our domain."● Domain can be difficult to virtualizeLarge legacy codebase with little or no test automation● Very few regressions may have happened thus far, so there might be over-confidence in code quality
    • Test Automation● Invest in simplifying domain virtualization ○ simulators/emulators ○ automated runtime materialization (e.g. Puppet)● Put test CI & reporting site in place to increase motivation for putting tests in place ○ e.g. Sonar● Start small, but start putting test automation in place● Have a software engineer in test & test architect; dont just resort to getting build-monkeys!
    • More "Testing" myths● We have never found this working: All code must have unit tests. Ideally, when you find a bug, you create tests.● CI does not need TDD, just CI is enough.● Documentation should be in place before automation● Prior to “first customer ship”, we cannot dictate that “All code must pass all tests before it can be released.”● Ideally, acceptance tests are run often and the score should be published. We keep little conservative outlook on this one. We never make our scores public.
    • Scope of XP Myths: CategoriesCoding:Ownership sources: http://www.extremeprogramming.org/rules.html http://xprogramming.com/what-is-extreme-programming
    • "Coding" Myth: OwnershipMyth (fact or crap?): Few XP practices may need face-lift. Specifically: ○ Collective code ownership have an unintended consequence: "tragedy of the commons". ○ Pair programming works best with developers who love community service.● Team ownership creates expertise impedance mismatch: ○ One engineer has contradictory view & conflicting style than others. This mature developer has passion for longer term view of big picture.● Pair programming has perceived interchangeability: ○ management "myth" of cross-training team. ○ no respect for specialization
    • Ownership- Done Right● Ideal: "team structure matches with component graph" ○ each component has an owner (and a backup)● Distributed teams use proactive pre-commit code review (e.g. Gerrit) and collaboration tools (e.g. WebEx or vnc), fulfilling similar purpose as collective code ownership and pair programming● Tighter collaboration during design (of interface contract) between producer & consumer (backed with TDD)
    • More "Coding" myths● Customer is always there for you● Coding standard & style are a must and better be automated● we always write unit test last, usually as “int main(argc[], argv[])” wrapper● We never do pair programming, since we have standards for code reviews, walkthroughs and inspections● I do scripting, I don’t need CI● Complex (fancy) “Branch & Merge“ strategy needed for better CI
    • "Planning" mythsHere are possible "Planning" myths:● “Small releases” is a misnomer for large-scale product development teams● User stories are written upfront, all of them.● Release planning creates the release schedule that we can stick to● The project is divided into iterations, and we change iteration length at will
    • Scope of XP Myths: Categories Managing: team room Coding: Ownership Testing: Automation Designing: MDAPlanning:small releases sources: http://www.extremeprogramming.org/rules.html http://xprogramming.com/what-is-extreme-programming
    • Q&A