sdlc and agile recap
TRANSCRIPT
Hope you enjoyed this learning journey.
SDLC AND AGILE RECAP
• Fire exits• Toilets • Breaks
HOUSEKEEPING
“The process of taking a set of business requirements through a series of structured stages and translating them into an operational IT system.”
‘Developing Information Systems’
What is Systems Development?
4
Elements of a framework method
Philosophy
Principles
Pro
cess
Peo
ple
Pro
du
cts
Pra
ctic
es
5
Elements of the System Development Lifecycle
Context
S/W Lifecycle
Techniques
Process Roles Deliverables
Context
Must be considered before startingRelease plan – Single or multipleLevel of skills and expertise – Preferred delivery styleLocation of teams and stakeholders – Single site or dispersedRequirements – Audit, quality, regulatory, complexity and stabilityTechnology to be used – Tried and tested or new?
6
Context
S/W Lifecycle
Techniques
Process Roles Deliverables
Lifecycle
Describes stages to follow: Plan, design, build, test, and deliverBasic approachesLinear – Sequential, or step-by-stepEvolutionary – Iterative evolving through prototypes and progressive versions
7
Context
S/W Lifecycle
Techniques
Process Roles Deliverables
Process
Set of steps and actions followed to deliver outcomes within stagesMethods and standards support the framework within SDLCInclude defined roles, deliverables, techniques, modelsPrescriptive – Specific SDLCsAgnostic – Various SDLCsDependent on context and lifecycle chosen
8
Context
S/W Lifecycle
Techniques
Process Roles Deliverables
Roles
People that carry out tasks within various SDLCsSpecific to particular SDLC or generic – Various titlesInclude Business, Project, Technical and Support roles
9
Context
S/W Lifecycle
Techniques
Process Roles Deliverables
Deliverables
People that carry out tasks within various SDLCsSpecific to particular SDLC or generic – Various titlesInclude Business, Project, Technical and Support roles
10
Context
S/W Lifecycle
Techniques
Process Roles Deliverables
Deliverables
Numerous – Choice dependent on team, organisation, SDLCExamplesMilitary – Ministry of Defence Architecture Framework (MoDAF)Commercial payment milestones and reviews – Waterfall Rapid prototypes – AgileMany SDLCs – Strengths / weaknesses, suit particular projects
11
Context
S/W Lifecycle
Techniques
Process Roles Deliverables
Initiation
Systems Concept
and Developme
nt
Planning Requirements Analysis
Design
Development
Integration and Test
Implementation
Operations and
Maintenance
Disposition
Main Stages of System Development – More Detailed
Not to be confused with a Software Development Lifecycle – end to end perspective
Alternative view of a System Development Life Cycle - Detail
A System Development Life Cycle (SDLC) is a framework describing a process to…
• Understand• Plan• Build• Test• Deploy
…an information system
Can apply to• Hardware• Software• Both
13
Feasibility Study
Requirements Analysis
Design
Testing
Code Development
Deployment / Implementation
Maintenance
Requirement Analysis
Gain understanding of what the business needs the proposed system to doBusiness Analysts elicit, analyse, document, and validate requirementsDecide how to store, manage, access, and update requirementsKey input to design; requirements traced through SDLCLevel of detail influenced by SDLCAlso known as Requirements EngineeringMake use of tools such as UML
14
Feasibility Study
Requirements Analysis
Design
Testing
Code Development
Deployment / Implementation
Maintenance
Design
Evaluate possible solutions that meet requirements
Chosen design elaborated on to sufficient detail To allow the start of development
Make use of tools such as UML
15
Feasibility Study
Requirements Analysis
Design
Testing
Code Development
Deployment / Implementation
Maintenance
Code Development
Hardware and software technical components created, procured or configured
Follow design to ensure system does what is required
Also known as Programming or Build
Make use of tools such as automated build tools and code coverage and testing frameworks
16
Feasibility Study
Requirements Analysis
Design
Testing
Code Development
Deployment / Implementation
Maintenance
Testing
Components produced tested to ensure working properly and does what supposed to do]
Different levels of testing• Unit• Integration• System• User Acceptance
Make use of tools such as automated build tools and code coverage and testing frameworks
17
Feasibility Study
Requirements Analysis
Design
Testing
Code Development
Deployment / Implementation
Maintenance
Deployment / Implementation
Completed system needs to be commissioned in ‘live’ environment
• Also known as operation or production environment
• Developed in ‘test’ environment to protect ‘live’ systems
Needs to be carefully planned, understood and managed
Make use of tools such as automated build tools and code coverage and testing frameworks
18
Feasibility Study
Requirements Analysis
Design
Testing
Code Development
Deployment / Implementation
Maintenance
Maintenance
More than just correcting faults or keeping the system in good running order
• 20% Corrective• 80% Enhancements
Depends on• Development strategy• Lifetime of operation
Maintenance Types• Corrective• Adaptive• Perfective• Preventative
19
Feasibility Study
Requirements Analysis
Design
Testing
Code Development
Deployment / Implementation
Maintenance
Agile Approach
Each slice an increment of the product
Analysis
Design
Code
Code
Time
Makes heavy use of tools such as automated build tools and code coverage and testing frameworks
What is Important in Agile?
Values Principles Practices Rules
Agile PrinciplesHighest priority is to satisfy customer through early and continuous delivery of working software
Welcome requirement changes during development which enhance competitive advantage
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
Business people and developers must work together daily throughout the project
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
Agile PrinciplesWorking software 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
Continuous attention to technical excellence and good design enhances agility
Simplicity – the art of maximising the amount of work not done – is essential
The best architectures, requirements, and designs emerge from self-organising teams
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly
Traditional vs Agile
Traditional Agile
Expects that low-level requirements evolve through understanding
Low-Level requirements are defined up front
Delivers increments of system in an iterative manner
Delivers fully developed system
Contingency in prioritised requirements
Contingency in resource
Planned active user involvement throughout the lifecycle
Typical user involvement at start and end of project
Traditional vs Agile
Traditional Agile
Testing Integrated throughout lifecycle
Discreet testing phase at end of project
Prefers co-located teamsDispersed teams
Skills and roles used across lifecycle - no hand-offsSkills and roles related to stages
Product based planningActivity based planning
Turning Convention Upside Down
Requirements(Functionality & Quality)
Time Resources
Agile
ResourcesTime
variable
fixed
Requirements(Functionality & Quality)
Waterfall
“The aim of Kanban is to make troubles come to the surface and to link them
to a Kaizen Activity.”
– Talichi Ohno
LEAN AND KANBAN
Regular communication
New information, changing priorities, progress updates are communicated daily between the business owner and the implementation team
The team meets every day in the same time and place –the daily stand-up meeting
28
USE AGILE AND LEAN TO DEMONSTRATE PROGRESS
Behaviour Checklist
Behaviour To Encourage Behaviour to Discourage
Allow freedom of expression Closed and secretive environments
Encourage everyone to have their say Ignore what you are being told
Be patient with quiet folks Using feedback in a negative or nefarious way
Ensure management and HR understand why change is needed Being impatient
Refine surveys or create new ones Do as I say, not as I do!
Get management to contribute
30
A measurement system helps make the software product more visible
Reference
VISUALISE WHAT YOU DO
31
A lightweight agile project management method formalised by Ken Schwaber in 1996
Key characteristics include:
• Small, cross functional teams• Close working• 30 day sprints deliver incremental releases• Self-directed, empowered teams• Scrum Master facilitates work and reinforces principles• Product backlog prioritises sprint activities
SCRUM
Scrum Process Overview
SprintBacklog
ProductBacklog Potentially
ShippableProduct
Increment
2-4 Weeks
Scrum board
Task A
Story #1
Task B Task D
Task C Task B
Task C
Task A Task B
Task A
Task C
Story #1
Story #1
StoriesNot
started In progress Done
Kanban Boards
----------------
-----
----------------
-----
----------------
-----
----------------
-----
----------------
-----
----------------
-----
----------------
-----
----------------
-----
Backlog Research Implement Validate Release
In progress done In progress done In progress done
“If you focus on driving utilisation up,
things will slow down.”
– Mary and Tom Poppenbeck
LIMIT WORK IN PROGRESS
“When we emphasise flow, we focus on queues rather than timelines.”
– Taiicho Ohno
MANAGE THE FLOW
“Ignoring feedback merely means that the system will eventually experience a
massive unpleasant surprise rather than a small unpleasant surprise.”
John Gall
IMPLEMENT FEEDBACK LOOPS
38
Agile Roles Product owner – custodian of the vision for the product, represents the customer
Scrum Master – helps the team best use Scrum to build the product, shields the team from outside influence
Development team – build the product
39
Product Owner The voice of the customer, acting as an expert to the development teamDefines the work to be done, and prioritises that workUnderstands what’s important to the customer
The real customer
The Product Owner
Customers can be a very varied group of people
Scrum MasterHelps the team best use Scrum to build the productHelps them to focus on the project• Protects them from organisational disruptions and internal distractions like an area where
the teach cannot focusEnsure that the team execute the Scrum process in spirit• They control the process, not to be confused with the role of the project manager who is
responsible for the workload
40
Development TeamScrum Master
41
Development Team
Self-organisedWork with Scrum master to develop the productPrioritise the product backlogDefine the number of sprintsDefine the stories to be tackled in each sprintDefine DONE
Requirements to StoriesRequirements come in varied formsScrum team translate those requirements in StoriesStory is structured as:• As a <role>• I want <capability>• So that <value>• Optional: <acceptance criteria>
42
As a Trader I want to be able to view the streamed data at a later point in time so that to provide evidence to audit / regulators when being audited
Acceptance criteria: Historic data is displayed in a tabular and graphical manner
Story Points NOT TimeTraditionally when prioritising and scheduling tasks, analysts would use Complexity and Time as key factors
This has proven to be a unsatisfactory way of prioritising and scheduling workloads
Recommended approach – story points• A notional value assigned to a task that represents its complexity and perceived time to deliver
Techniques for assigning story points• Estimation Poker - https://www.planningpoker.com/
43
Hope you enjoyed this learning journey.
THANK YOU