1 / 29

Mark Dickinson

Rational Unified Process and how Software Configuration Management (SCM) solutions can improve project management and governance. . Mark Dickinson. How using RUP and Collaborative techniques facilitated geographically distributed development. . Mark Dickson.

alijah
Download Presentation

Mark Dickinson

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Rational Unified Process and how Software Configuration Management (SCM) solutions can improve project management and governance  Mark Dickinson

  2. How using RUP and Collaborative techniques facilitated geographically distributed development.  Mark Dickson

  3. Agile RUP: balancing agility and discipline in public sector development  Mark Dickson

  4. Or…“Take your RUP and shove it” Mark Dickson

  5. What we do Vital statistics Worldwide strength: c7,300 2005 turnover: £376.4m largest UK provider of offshore services into the UK • Offshore strength: c3,400 Market leader UK applications management A leading UK player in back office processing Outsourcing • IT • Business Process Technology • Full lifecycle from concept to decommissioning • Cross-technology from legacy to enterprise • Integration services across all applications • Standalone services from upgrades to training Consultancy – embedded throughout our services

  6. Typical Project Profiles for using RUP in Xansa • 2-4 year programmes • Iterative projects, 6 to 18 months duration • Team sizes vary from 20-120 • Mixed Teams, geographically dispersed • Range of technologies, combining • Bespoke development • Package implementation • Legacy integration

  7. Typical Challenges • People • Initiative • Motivation • Skills • Organisation • Command & Control management • Extremely large number of “stakeholders” • Process • Multiple management & development process • Bureaucratic (by definition) • Predictive planning in extremis • Instinctively waterfall • Information • Broad range & large volumes • Complex business rules governing access • Technology • Extremely diverse • Largely ageing

  8. Opportunities MODERNISING GOVERNMENT Joined Up Government Adoption of new technologies Agile Government Innovation & Creativity e-Government by 2008 Removal of unnecessary regulations Information Age Government

  9. How Agile are we? • Individuals & Interactions over Processes & Tools? • Not yet – requires experience & judgement • Customer Collaboration over Contract Negotiation? • Yes – but could do better • Responding to Change over following a plan? • Yes in principle – in practice it depends on things other than RUP • Working Software over Comprehensive Documentation? • Sometimes? Depends what the documentation is The Agile Manifesto Note: “over” not “instead of”

  10. Individuals & Interactions over Processes & Tools • Good tooling in place to support distributed teams • Process defines individuals & interactions Technology Summary: Systems integration & development using J2EE, Bespoke build, CRM, HR, Legacy integration & various specialist packaged applications Xansa Site Dev team CCM, RP, CQ, Plus web clients, Lotus Notes Client Site 1 Dev team + Business so what’s our process? Client Site 2 Client Site 3 Business Dev team

  11. Individuals & Interactions over Processes & Tools THE AGILITY TIGHTROPE MSP DSDM SCRUM PRINCE2 MSF XP ITIL RUP

  12. Individuals & Interactions over Processes & Tools • Adapt the Process • Combination of… • Method abc (for Xansa Corporate governance) • PRINCE2, ITIL (for OGC compliance) • DSDM (for “Agile” and collaborative practices) • RUP (for software engineering best practices) • Plenty of work by others to re-use:- • DSDM/Rational (1999) • FMI Solutions RUP plug-in • OAK IT (RUG, Drury 2001)

  13. Manage Stage Boundaries Close Down a Project Starting up a Project Initiating a Project Framing in PRINCE2 Programme Management Directing a Project Controlling a Stage Managing Product Delivery iteration Inception Elaboration Construction Transition iteration Planning

  14. ITIL / RUP • ITIL defines an iterative development life cycle • “The main reason for the introduction of increments and iterations in the development process is management of the risks associated with uncertainty and changing requirements.” • Our clients had dabbled with iterative development – through DSDM

  15. DSDM / RUP Inception Pre-Project Post Project Transition Elaboration Construction

  16. Software Development Activities Combines: Method abc DSDM RUP The substance of the work in RUP terms is unchanged

  17. Customer Collaboration over Contract Negotiation • DSDM “Business” roles • Executive Sponsor • Visionary • Ambassador User • Defines active responsibilities • Plus DSDM “business-centred development” practices, including • Facilitated workshops • Evolutionary prototyping Empowered JOINT teams Problem solving in groups “Customer” representation WITHIN the team

  18. UI Prototype Use Case Specification BAD Use Case Model Systems Analyst Architect UI Developer Detail a Use Case Customer Collaboration over Contract Negotiation:Example: Use Case Workshops Visionary Ambassador User

  19. Customer Collaboration over Contract Negotiation:Example: Use Case Workshops • Workshops held to detail the Functional and Non–Functional Requirements • Joint group (3-8 business & technical people) • Based around USE CASES & System Qualities • Write use case specifications • Prototype UI

  20. Working Software over Comprehensive Documentation:Coding is continuous • Software development is an early activity • Software developed from the outside in

  21. Working Software over Comprehensive Documentation Architecture: BDUF? • NO! • The Big Picture - defining STRUCTURE and externally discernable properties of the system • Teams of people need to work to a shared vision or plan of construction • Architecture is a technical plan • Can start INFORMAL and grow in formality as decisions are made • Do just enough architecture to get the team working • Architecture must be developed collaboratively

  22. Working Software over Comprehensive Documentation Analysis & Design JAD Sessions Design is discovered through use case realisations developed during collaborative workshops

  23. Subsystem Interfaces UI Prototype Design Guidelines SAD Working Software over Comprehensive Documentation:Coding is iterative Software is developed iteratively *within* a time box Subsystem development Assigned to distributed teams Developed during Use case workshops & refined thereafter Produced by Architect/designer During use case design

  24. Working Software over Comprehensive Documentation: How much documentation? Written Materials make a project / process LOOK heavyweight Written (and USED!) processes make the TEAM more Agile! The more we write down, the more information we able to share!

  25. Responding to Change over Following a Plan • Each project in a programme was is run against a strict time-box • Predictive planning within that overall context is limited • Feasibility Study • High Level Design activity (produce a SAD, BAD & PRL) • “n” iterations of “development” (tacit elaboration/construction) to complete the build • “n” iterations of Transition to deliver the product

  26. Responding to Change over Following a Plan • The Prioritised Requirements List acts as a work list for the project and iteration • MoSCoW techniques are used to plan what work from the PRL is delivered in each iteration • Only 60% is guaranteed • Ultimately, requirements are cut to fit the available time • Additional, unexpected time-boxes are allowed!

  27. DO make sure the Team Manager walks the floor DO make sure that planning is a joint activity DO sit people together whenever possible DO use joint workshops – they really work! DO manage time-box scope DO Track progress diligently DO remember to re-estimate each iteration! DON’T confuse iterative development and phased delivery DON’T do “Gantt chart management” DON’T let Plans solidify DON’T let plans get too detailed DON’T allow Iterations to overlap DON’T let Joint teams fragment Basic Do’s & Don’ts

  28. Responding to Change over Following a Plan project management is the key to agility

  29. Thanks for listening…Any Questions? • Or… • Email me at mark.dickson@xansa.com

More Related