Please enable JavaScript.
Coggle requires JavaScript to display documents.
Agile Process Management (Software Focus) (Examples of Agile methodology,…
Agile Process Management
(Software Focus)
Process
A process organises product development into distinct phases or stages
Phases
can be broken down into activities
Activities
are a group of a related tasks and can be broken down into tasks
Tasks
produce work products and can also use work products as input
Tasks completion consumes resources
Resources
= anything that improves, advances, or funds work to be done
Time
Money
Technology
Knowledge
Staff
Task are low-level, specific actions
Life Cycle processes and its subprocesses
Software life cycle process model stages
Specification
Design and implementation
Verification and validation
Practices
are tactics that software mngrs use to make processes execute smoothly
Provide
guidelines and rules
for aspects of development
often gathered into a
methodology
(= defined set of practices)
Role = a duty that a person takes on or plays
= a role performs a task
Parallel Development, Iterative Development, Incremental Development, Synchronised Development
Test driven development = write test before you write the actual code itself
Process Model types
Parallel Models
= allow for overlap between process phases
Iterative Models
= allow for looping within or between process phases
'+ ability to loop back on previous steps (iteration)
-'+ repeats elements of the process throughout
Extension of linear models and forerunner to truly agile processes
Example of
iterative models
Spiral Process Model
Consists of 4 quadrants, each quadrant is an iteration phase, each iteration is the duration of one full spiral or all four quadrant phases being completed one time
Invariants of a spiral model (= 6 conditions that always stay the same)
All work products should be created at the same time
All the quadrants must be addressed, no skipping steps
Decide how much effort is enough for each activity to minimise overall risk
Decide which level of detail is enough for each activity to minimise overall risk
Use Anchor Point Milestones = each iteration should result in a tangible work product (Life Cycle Objectives and Architecture are clearly defined, initial operation capability is in place)
Focus on improving the process as a whole
In Spiral (the four quadrants):
come up with objectives and needs, generate solutions for the current iteration.
identify and assess risks and evaluate solutions.
move on to developing and testing the product in the current iteration.
Once you have a product that satisfies the objective of the current iteration you move on to planning the next iteration.
Unified Process Model
(Unified Process)
Emphasised gradual development
general structure is iterative while allowing work to be done in parallel
most compatible with agile principles
Phases (cycles are repeated until product is ready for release):
Inception phase (goal: identify if business case is viable; no iterative development, define project scope & risks)
Elaboration phase (goal: prototype; define system architecture and documentation)
Construction phase (product comes to life until product is ready to be released, development of very robust use cases)
Transition phase (major roll-out of product and gathering user feedback)
Linear Models
= never loop or repeat process phases
3 examples of
linear models
Waterfall Process Model
Called Waterfall because each phase of the process is fed into by an approved product of the previous phase
V -Model
Difference: focus on
verification activities
to ensure implementation matches design behaviour and requirements
Like Waterfall model, things happen in sequential order.
Same advantages and disadvantages.
Divided into two branches (V-shape):
left: focus on requirements, specification etc.
right: once coding is done the focus shifts to verification of each of the respective phases on the left (right side verifies the left side)
Sawtooth Model
Same advantages and disadvantages as Waterfall- and V- Model
Distinguishes between client and development team
= tasks requiring client's presence are made distinct from tasks only requiring the development team
'+ determine and stick to scope early
'+ start building a product quickly
'+ easy to apply
emphasis on documentation to capture common understanding of the software
'- not agile (cannot adopt to change = no feedback)
'- client doesn't see product until the very end
Follow a pattern of phases completed one after another without repeating prior phases
Emphasis is on getting the requirements right upfront and not changing them afterwards
Examples of Agile methodology
EXTREME PROGRAMMING
(XP)
Additional practices:
open work spaces with white boards etc. to allow collaboration
move people around product parts so success is not dependent on one person
fix XP when it breaks = when sth doesn't work change it
It's all about client satisfaction
Values constantly delivering software, constantly delivering software, effective teamwork and self-organisation
Focuses on improving communication, simplicity, feedback, respect and courage (= everybody is considered equal: "We don't document excuses for failure because we plan to succeed. We don't fear anything because no one ever works alone. We will adapt to changes whenever they happen." )
12 Principles:
Planing game (prioritised user stories to describe features with effort estimates)
Small releases (develop important features early so there is time to refine them)
System metaphor (explains the product to a non-technical person)
Simple design (design what you need to make your daily requirements)
Continuous testing (acceptance test (= asses large portions of user functionality) and unit test (=automated test for lower level functionality)
Refactoring (restructuring the design of the code without changing the functionality of the code)
Pair Programming (code is consistently reviewed within the pair)
Collective Code ownership (anybody can add code to any part of the product, team owns success and failure)
Continuous Integration (developers combine their code often)
40 hour work week (1 week overtime is allowed in crunch time, more is a red flag)
On-Site Customer (customer is part of the development team)
Coding Standards (common coding conventions and formatting standards)
Weaknesses
'-all or nothing approach
'-for small development teams
'-lack of upfront planning might lead to reprogramming in the future
'-pair programming
'- onsite client requirement
SCRUM
iterative and incremental approach
3 Pillars:
1. Transparency
= everyone can see every part of the project, agreement on common standards
2. Inspection
= frequent inspection to detect undesirable deviation from expectations
3. Adaptation
= adapt if team deviates from the vision. Tools are Sprint Planning, Daily SCRUM, Sprint Review, Sprint Retrospective
Definition of Done is crucial = development defines the qualities that mean a feature is done
Team roles
Product Owner
= decides about product features and prioritises backlog
Development Team
= self-organizing, cross-functional, no dedicated tasks or titles, no sub-teams, size >3 <9
Scrum Master
= makes sure the SCRUM team follows the SCRUM theory, practices and rules; helps Product Owner with techniques to manage and prioritize backlog, helps team to understand need for clear and precise backlog,coaches team to self-organise, removes development roadblocks and facilitates the 4 scrum events (
Sprint Planning, Daily SCRUM, Sprint Review, Sprint Retrospective
)
Sprint = development phase of a specific amount of time in which a working prototype is delivered to the client; lasts 1 month or less; duration cannot be changed during the project; each sprint contains the 4 SCRUM elements; suggestions that would change the sprint goal are added to the backlog
LEAN Software Development
Additional principles:
use the scientific method when building a system (base decisions on real data)
encouraging leadership (bring out the best of each team member)
7 Principles:
1. Eliminating waste
= anything that doesn't add value is waste and removed from the development process
2. Amplifying learning
= explore ideas thoroughly by thinking through alternatives before proceeding with actions; test in short iterations; present different versions of the product to the client to gain better and continuous feedback
3. Deciding as late as possible
= making decisions when data and information you need is available
4. Delivering as fast as possible
= short rapid iterations to ensure you work on parts of the product that will actually be part of final product
5. Empowering the team
= Mngr. removes development roadblocks and gets out of the way
6. Building quality in
= avoid errors by e.g. test driven development, pair programming, well commented code, good documentation, refactoring code, automated testing
7. Seeing the whole
= see the cohesive product not individual parts before releasing it
Kanban
work in progress -> bottle necks -> create work-in-progress-limits
Kanban Board = task board with each software development activity visualised in its current phase with a prioritised back-log
Pull method
Kanban helps lean processes to quantify the state of their system and achieve the ideals of
Just-In-Time Manufacturing
(= building components only when they are need)
Cycle Time = total time that it takes for one piece of work to go to the complete cycle once
Agile Unified Process (Agile UP)
combines agile philosophies (e.g. test-driven development, small incremental releases) with parallel development phases
Focus on following process over specific tools:
simplicity, empowering people, customisation of methodology to suit each project's needs
Dynamic Systems Development
Feature Driven Development
Scrumban
Behaviour Driven Development
Prototypes
core idea of prototyping = gain feedback on versions of your product
5 types of
Prototypes
Throwaway
First version is build and thrown away as second version is build from scratch
allows you to learn from past mistakes = second product version is more solid
Illustrative
most basic prototype
share an idea using a low fidelity, disposable image
get system's look & feel right without investing much time/money
can provide guidance to the development team
very common
Incremental
initial prototype is used for final product
you build and release your product in increments one at a time
works in stages based on triage system = assign each component a priority and develop the product from the ground up based on these priorities (must be done- should be done - could be done)
Evolutionary
initial prototype is used for final product
start with all features in basic form and refine them over time
Exploratory
focus on product's look & feel
build working code to see what's actually possible
find out how feasible and useful a product idea really is (determine effort of building the product
Continuous Delivery
= each code change is built, tested, integrated and released
Fits well with iterative process models
Aims at having a releasable prototype at the end of every iteration (= even if you abandon the project you'd still have a releasable product)
Example of Continuous Delivery
=
Daily Build and Continuous Integration
= each piece of written code is put through automatic testing before being shared remotely with the team
=> error checking is made really easy
used to release Incremental or Evolutionary Prototypes
"minimum viable product"
Its purpose is not to wow anyone with exquisite design or top-notch performance, but rather to test a hypothesis.
Spotify organisational structure
Squats
Self organising team with a long-term mission
(kind of SCRUM Teams)
No formally appointed leader
has a
product owner
, who is responsible for prioritizing the work to be done by the team; product owners of different squads collaborate with each other to maintain a high-level roadmap document that shows where company as a whole is heading, and each product owner is responsible for maintaining a matching product backlog for their squad.
A squad also has access to an agile coach, who helps them evolve and improve their way of working.
Each squad is fully autonomous with direct contact with their stakeholder
minimize interdependencies between squats
Tribes
= a tribe is a collection of squads that work in related areas
Each tribe has a tribe lead who is responsible for providing the best possible habitat for thesquads within that tribe.
-The squads in a tribe are all physically in the same office, normally right next toeach other
smaller than 100 people
Chapter
The chapter is your small family of people having similar skills and working within the same generalcompetency area, within the same tribe.
Each chapter meets regularly to discuss their area of expertise and their specific challenges.
The chapter lead is line manager for his chapter members, with all the traditional responsibilities such asdeveloping people, setting salaries, etc. However, the chapter lead is also part of a squad and is involved in the day-to-day work, which helps him stay in touch with reality.
Guild
A Guild is a more organic and wide-reaching “community of interest”, a group of people that want to shareknowledge, tools, code, and practices.
Chapters are always local to a Tribe, while a guild usually cutsacross the whole organization
Each guild has a “guild coordinator”
"System Owner”
All systems have a system owner, or a pair of system owners (we encourage pairing).
For operationally critical systems, the System Owner is a Dev-Ops pair.
The system owner is the “go to” person(s) for any technical or architectural issues related to that system.He is a coordinator and guides people who code in that system to ensure that they don’t stumble over each other.
He is typically a squad member or chapter lead who has other day-to-day responsibilities in addition to the system ownership.
"Chief architect role"
coordinates work on high-level architectural issues thatcut across multiple systems.
He reviews development of new systems to make sure they avoid commonmistakes, and that they are aligned with our architectural vision.
The feedback is always just suggestionsand input - the decision for the final design of the system still lies with the squad building it