Presenter – Tim Peek
- History of lifecycle development (mid-70s)
- Waterfall methodology
- BDUF – Big Design Up Front
- Iterative methodology
- Phase based development
- Analysis Paralysis is a risk – mitigated by timebox or
other constraints
- Agile Philosophy
- Attempts to look at the root causes of software project
failures
- Good people handicapped by bad processes
- If value is in the working system, then too much time is
spent on non-value-added work
- Iterative development is valid model but still
overburdened by processes
- “Let programmers be programmers”, not project
managers
- Counterculture swinging against heavily process-based
methodologies
- PMI and PMBOK (Project Management Body of
Knowledge)
- Capability Maturity Model (CMMI)
- Early proponents appeared in the 1980s
- Rapid Application Development
- New ideas, visibility and momentum in the 90s
- “Agile Manifesto” in 2001 started to bring Agile into
the mainstream
- Manifesto
- Individuals and interactions over
processes and tools
- Working software over comprehensive
documentation
- Customer collaboration over contract
negotiation
- Responding to change over following a
plan
- Early and continuous delivery of
valuable software
- Welcome changing requirements EVEN LATE
IN DEVELOPMENT
- Deliver working software
frequently
- Business people and developers work
together daily throughout the project
- Build projects around motivated
individuals
- Environment
- Support
- Trust
- Communication face-to-face
conversation
- Working software is the primary measure
of progress
- Agile processes promote sustainable
development
- Continuous attention to technical excellence and
good design
- Continually developing AND
- Continually testing – testing is key
- Simplicity (maximizing the work NOT
done) is essential
- The best architectures, requirements and designs emerge
from self-organizing teams
- At regular intervals, the time reflects on how to become
more effective, then tunes and adjusts its behavior
accordingly
- Initial Agile Mindset
- Focus on execution
- Planning is important by not as important as
execution
- Writing plans and documents for development is wasting
time from actually developing software
- The Current Agile Mindset
- Focus on leaner versions
- Agile project management
- Agile quality assurance
- Agile CMM
- The More Mature Agile Mindset
- The software development world has moved too far toward
process-focus
- Too many processes result in bureaucracy and
overhead
- Most technical people work fine if you allow them
- Things are rarely black and white
- Make things as simple as possible, but not
chaotic
- Compromise when necessary
- The Nature of Projects
- Traditional PM assumes projects are predictable and most
are not
- The nature of the project should be uncovered through
exploration
- The Nature of Agile Projects
- Generally software development
- Smaller teams (3-5 people)
- Larger projects
- Split into smaller Agile projects
- Use common processes and techniques
- Might need longer sprints to manage coordination
- Requires more structure and coordination
- The “Planning Game”
- Customer, management, users and team meet to determine
functionality for next Sprint
- The team explores requirement details with the
customer
- Detailed specs
- Detailed test rules
- Tech team meets afterwards to determine how to meet
expectations
- Ultimately, customer and project team agree what to work
on
- Customer Requirements
- Create test cases along with the requirements
- Test cases validate completeness and correctness
- Try to identify means for automated testing
- Project End Date
- Customer prioritizes
- High value requirements delivered first
- Ultimately customer decides if the value is more than
the cost of the next sprint
- If not, the project will end
- Fixed Budget/Deadline
- Budget delivers sprints with most valuable features
until the money runs out
- Deadline delivers sprints with most valuable features
until the time runs out
- Unlike traditional development, customer will ALWAYS
have something delivered (fully tested production code)
- Construct
- Refactor
- Look for opportunties to enhance code
- Make code more adaptable
- Maintainability is key
- Need to have solid regression testing process to ensure
nothing breaks
- Don’t try to make it perfect, just look for
opportunities to make it better
- TDD
- Test are defined along with detailed requirement
- Write the test first, then code to meet the test
- New tests get added to the repository
- Programmer tests for 100% of the code
- Tests must ALL run correctly with each sprint
- Be sure that tests don’t all become too discrete. Keep
eye on overall design and create tests for
integration and end-to-end logic
- Implementation
- Continuous Integration
- Daily builds ensure full integration
- Uncovers integration bugs early, eliminates code
freezes
- Customer decides when the first iteration is usable and
then grow features from there
- Scrum
- “Scrum” metaphor used in 1986 to describe new approach
to product development
- Rugby corollary – adaptive, quick, self-organizing, few
rests
- Scrum approach developed and refined in 1996
- Looks at software development in “new product” versus
“manufactured product” model
- Scrum Master
- Scrum teams
- Daily Scrum – standup meeting every day
- Extreme Programming (XP)
- Communication
- Feedback
- Whole Team
- Planning Game
- Customer Acceptance Tests
- Small releases
- Pair Programming
- TDD
- Design Improvement/Refactoring
- Continuous Integration
- Collective Code Ownership
22001007-beb3-4099-98bc-ee07f92ab335|5|3.0