Presentation on theme: "1 incremental application development Ian Graham Enterprise IT Strategy & BMO Connect T: 416.513.5656 E: W:"— Presentation transcript:
1 incremental application development Ian Graham Enterprise IT Strategy & BMO Connect T: 416.513.5656 E: email@example.com W: http://www.utoronto.ca/ian/talks/ “Racing the laps”
2 what this talk is about About incremental development – an approach (or ‘methodology’) for developing applications. Things we’ll cover include: What is it, and how does it differ from (or how is it similar to) …? –Waterfall approach –BMO standard practices –Things like RUP (Rational Unified Process), Agile, …. Why is it something we are doing? –What are the benefits? –Where is it relevant? –What are the potential gotchas (things to worry about / manage) How does it impact standard roles in a project? –(e.g. PMs, BAs, business leads, etc.) This should be more discussion than talk – so ask lots of questions!!
3 “Waterfall” waterfall development time basic waterfall flow Do all requirements up-front (1, 2) Do all design / development next (3) Do rigorous testing of final product (4) history in BMO Standard approach for Optimizer, MECH, OCIF, etc. development (most common approach at BMO). [ Note, however, that teams often used implementation ‘phases’ to break this up into digestible pieces. ] 3-4. Design, Development (Dev, usability, QA) 3. Dev 4. Formal QA & UAT 2. Detailed Requirements : Produce FSs 1. High Level Requirements : Produce High Level Requirements Document (HLRD) “waterfall” from stage to stage 3-4. Design, Development (Dev, usability, QA) 3. Dev 4. Formal QA & UAT 2. Detailed Requirements : Produce FSs 1. High Level Requirements : Produce High Level Requirements Document (HLRD)
4 where waterfall does/doesn’t work The waterfall approach works well when: –Projects are not too big –Functional requirements are easy to define, and don’t require much customer feedback during design. –Doesn’t involve a lot of new UI development The waterfall approach has problems when: –Projects are big (lots of new code, or lots of requirements) –Functional requirements are hard to define, and require lots of customer feedback for clarification, refinement –Involves significant UI design or redesign Symptoms of problems include: –Difficulty in getting (detailed) requirements complete and signed off –Long period of development without clear measure of how well you’re doing
5 why waterfall has problems Many different potential reasons for this: Lots of new code that takes a long time to develop –Can’t tell if things are ‘good’ until near the end Inflexible to changing customer needs, demands –Customer requirements often change in long/large projects. –Particularly an issue when new UI / business processes are involved, as the customer will see better ways of doing things as they become familiar with what is possible. Requirements / specification documents can be unclear –Documents get so big they are hard to properly validate / sign off Problems detected at end are hard/expensive to fix –Once all the code is written, it can be hard/expensive to go back and fix fundamental problems (better to find them earlier, rather than later). Can be hard to plan / manage –There are few ‘checkpoints’ along the way to verify you’re on track or not.
6 incremental overview basic incremental flow Do HLRD up front (1) Do detailed requirements in pieces, alongside and ahead of development (2) Do development and QA in short ‘increments’ (e.g. ~1 month) formal QA at end of each increment (3, 4) Still do rigorous testing of final product (UAT) time “Incremental” a b c d e Final QA & UAT HLRD 1. High Level Requirements: Produce High Level Requirements Document (HLRD) 3, 4. Design, Development Increments (Dev, usability, QA) 2. Detailed Requirements: Produce FSs New batch of specs for each increment
7 incremental rationale Incremental attempts to solve waterfall problems as follows: Lots of new code that takes a long time to develop –Develop small bursts of code in increments, and validate accuracy with QA Inflexible to changing customer needs, demands –Later functional specs can take customer feedback into account. –Change requests can come in early on, can be factored into future work. Requirements / specification documents can be unclear –DRSs are built in small pieces, so they are smaller / easier to verify Problems detected at end are hard/expensive to fix –Problems are detected at end of each increment -- fixes can be done earlier, and formally included into work plan. Can be hard to plan / manage –End of each increment gives a measurable checkpoint of progress (work done, # defects found, etc.).
8 where incremental comes from The incremental approach is built on a development best practice foundation: Rational Unified Process (RUP) –Iterative design and development (modify design as you learn) Test-driven development –Better to test early and often (reduces cost, time, to fix). Agile development philosophy –Release early and often (to get feedback, validate design) –Get customers involved early, and throughout the project (a ‘partnership’)
9 incremental vs. waterfall Incremental just divides up work differently – still need to do the same stuff… Incremental is no magic bullet – need rigorous management to make it work! time Development Increments (Dev, usability, QA) a b c d Requirements : Produce FSs Incremental d time Development (Dev, usability, QA) Dev Formal QA & UAT Requirements : Produce FSs Waterfall History in BMO Relatively new and executed within two programs: NCCS-FE BMO Connect Core (upcoming) CSA-R (‘phases’), Internet Channel (releases) are/were ‘sort-of’ incremental. History in BMO Standard approach for Optimizer, MECH, OCIF, etc. development (most common approach at BMO). Note, however, that teams often used implementation ‘phases’ – which are very similar to incremental (just less formalized) Size of bars approx. related to team size HL
10 strengths and weaknesses incremental Strengths Can start development earlier Better risk management -- provides regular, measurable checkpoints (end of an increment).. More flexible for redesign, change, based on feedback from users (revise future increments, based on feedback) (but see notes below) Better monitoring of quality (catches problems early: early testing is an industry best practice) Weaknesses Relatively new to BMO, unfamiliar to many Requires longer-term commitment /engagement by business during development activity Requires real-time signoff authority delegated to business team doing requirements / design Will be issues integrating with other teams that use the waterfall approach. Needs firm change control so change requests don’t swamp management, or reqs/dev work (… more ) waterfall. Strengths Familiar to most at BMO. Activities, processes integrate cleanly across different BMO technology areas. Weaknesses Known to not be industry best practice, and known to have problems when projects are large. Risk that problems all pile up in QA (where cost of fixing, risk, is higher than if caught early) Difficult to quantify progress while developing (no good measures – mostly by gut feel).
11 organizational differences Waterfall Notes Requires big business / BA team up-front (for requirements) Needs lockdown of requirements before development begins. Has ‘big bang’ QA activity (large team, high intensity) at end of development. Incremental Notes Potentially smaller business / BA team, but they are engaged through lifetime of project. Co-location is very important. Requirements delivered ongoing during development means that you need good up front and ongoing planning for sequencing of requirements work QA as ongoing activity (end of each increment) – still needs big bang at end. Rework needs to be factored into ongoing work plan. Business produces change requests after each increment (‘cause they can see it, and see how to make it better): means you need rigorous ongoing change management to control impact on timeline, deliverable. Incremental requires more rigorous, yet flexible, ongoing management.
12 learnings from nccs-fe Did well Delivered high-quality product Were responsive to changes to design that arose as the application was being built Very few post-production defects – virtually a problem-free delivery. What we learned Need good high level, big picture “how the application should behave” design / requirements up front to guide the detailed requirements/ design, and to plan out requirements / development work Ongoing requirements work takes longer (with a smaller team) – business involvement is protracted, so we need to plan for it Need to allow / plan for usability in detailed requirements preparation Need to include rework in plan (it always happens –with incremental you can plan it) Maybe devote an increment to rework / fixes (I.e. no new features). Don’t leave all the hard stuff (biz and/or tech) to the end Plan increments so ‘pieces’ can be dropped if necessary, still leaving a quality delivery NCCS-FE is the best example of incremental development at BMO. There were many successes & challenges in that project, and much learning to use in BMO Connect.
13 critical success factors Critical Success Factors Long term engagement / involvement of business partner in requirements work Co-location and real-time collaboration between business representatives, BAs, developers, and QA Need careful management of work and rework – and clean, efficient communication between teams – to avoid unnecessary rework. Strong governance structure for decision making and change control Don’t lead hard stuff (business requirements and technical) to the end – Team needs to understand how incremental works, so roles and accountabilities are clear Education to team (if not before) at kickoff, and ongoing Need to provide coaching to help From experience inside and outside the bank, we can identify some structural factors critical to success in an incremental development project:.
14 organizational impacts CMMI Is this compatible? (yes). How does incremental impact Project Managers Business Leads / Business Team Business Analysts (and lead) QA Team (and lead) Developers (and lead) Project Support (supporting all of above) All of the above are key partners – they all have to be engaged ongoing throughout the project. Key Issue overall Good communication within and between each group (thus the importance in co- location)
15 impact on: CMM-I Yes, incremental is compatible with our drive to be a CMM-I certified shop CMM-I doesn’t say how you need to do things, just that you have to do them and properly document the activities / processes. Incremental is about the ‘how’ of doing things. Same management processes need to be applied to a project, regardless of how you do things. One issue: Since the DRS is not finished before you start development, you can’t easily create a “Level 2” cost estimates before the project starts. Working to see how we can ‘incrementally’ deliver more refined estimates as functional specifications are written and increments are completed, and still be consistent with CMM-I.
16 impact on: project manager Approach requires continuous planning / replanning (like today, but more structured due to increments) Regular checkpoints (end of increment) imply need for regular, measurable and reportable metrics Need to design and track these … In collaboration with leads (QA, dev, BA, etc.) Need good continuous information coming from teams (to monitor progress, replan increments, etc.) Need a firm mechanism for change control (new features and bugs / work orders)
17 impact on: business leads / team Engagement is a long term committed partnership with T&S Need to get the business team on board for the duration of the project (can’t swap people in and out – need continuity) Need strong control over signoff for detailed requirements specs (otherwise process grinds to halt, and benefits are lost) Need to support a firm mechanism for change control (new features and bugs / work orders) Incremental encourages this type of feedback – but this can swamp/collapse the project unless it’s carefully managed
18 impact on: business analysts Longer-term engagement with business & project (work is not all up-front), and a smaller team Need to plan for long-term involvement Different form / structure for work, and for signoff HLRD – is used as a tool for planning increments – may mean rethinking how the HLRD is best written (scenarios / use cases can be helpful) BAs must be involved ongoing to revise requirements, help with impact analysis BA lead involved in ongoing planning to prioritize work in increments, work orders, etc.
19 impact on: QA lead / team Ongoing engagement with development in each increment means tests have to be written early and managed carefully (to account for changes in requirements) Automated testing critical to good success Want to do regression tests as often as possible Need outstanding communication with entire team (so work orders are identified and managed efficiently within the short time frame of an increment)
20 impact on: development lead / team Lead is critical to planning of increments – must work closely with PM, business lead, and other leads, to prioritize and schedule work Developers must focus on quality code – few bugs, and immediately testable Focus on writing and passing unit tests Should run QA-defined tests to verify correctness, and that they haven’t broken existing functionality (regression testing) Quality is testable at each increment – so pass the test!
21 impact on: project support In Incremental, things happen fast – so the support team, tools, and processes have to make sure communication happens quickly, and people get the information they need as soon as possible! Good communication needed between teams Can’t let people (as they often want to do) hide off on their own, and not communicate Need to effectively and quickly manage workflow of work using work orders E.g. May require manual help triaging /assigning work orders in WoW Regular testing (by developers, QA team, etc.) means automation tools / environments are critical
22 incremental application development Ian Graham Enterprise IT Strategy & BMO Connect, T&S T: 416.513.5656 E: firstname.lastname@example.org W: http://www.utoronto.ca/ian/talks/ the end “Racing the laps”