Looking at Agile as opposed to Plan-Driven.
It emphasises:
- Rapid software development
- Keeping the client involved constantly
- Rapid feedback, rapid development
Why Agile?
- Software Engineering is evolving rapidly, and businesses expected to keep up
- Plan-driven approaches are too slow and effortful
- Focus on code, not design
- Rapid prototyping
Drawbacks of Agile
- Requires heavy customer involvement
- Is your customer dumb?
- Works best with small & experienced teams
- Is your team massive, perhaps global?
- Is your team inexperienced?
Scope Creep
Be wary of scope creep! Don’t let the client make your project drag on.
The Agile Manifesto
Agile Principles
- Customer Involvement:
- Incremental Delivery: Incremental development with each iteration with requirements from client
- People-Oriented: Skills and unique methods of working of each team member should be recognised; let someone work in their own way
- Embrace Change: System should be flexible
- v:
Software Maintenance
As Agile focuses on rapid development rather than documentation; how good is it for maintaining a project?
Bus Factor
If there’s no documentation, then an expert leaving might mean no-one in the company knows how features work.
Bus Factor: How many team members would have to be hit by a bus before the project can’t continue?
Extreme Programming (XP)
- Incredibly frequent iterations
- Versions built many times a day
- Delivered to customers every 2 weeks
- Automated tests for builds
- Continual refactoring
- Customer Involvement
Feedback Loops
- Pair Programming: Feels like you’re wasting half the development time but:
- increases your bus factor (now at least 2 programmers understand that code!)
- can spot flaws in each other’s approach
Using Pair Programming in the Coursework
Pretty effective in a real company where everyone is working 40 hours a week at the same time but…
Due to student lifestyle, it’s quite hard to carve out time to do proper pair programming for the coursework! Be careful about using Pair Programming for this project.
Refactoring
Refactoring can be dangerous, because you might accidentally break your colleague’s work or conflicts in style will lead to inconsistent code.
Solution: Have a style-guide. Useful for the coursework.
Scrum
- Sprints
- Tend to be between 2-4 weeks (Scrum Guide says >1 month → no-go)
AAAAAAAAAA
- Scrum Master: Maintaining a distance from client
- Helps prevent Scope Creep
- f
Using Scrum in Coursework
Who is your Scrum Master?
How long are your sprints?
What items on the backlog?
How do you know the client is available?Using pure scrum methodology is quite difficult in the coursework; it’s best to adopt some parts of agile methodology, and to use a hybrid methodology.
When Scrum bad?
- Programmers in different locations
- Regular meetings might be quite difficult…
- Inexperienced developers
- Client project creeps a lot
- Scrum (and Agile) is a methodology with frequent customer client consultation; do you want that?
- Clear scope, deliverables, and timescale
- Better suited for plan-driven
- hint: such as in the coursework
Prototype vs MVP
Prototyping may have dummy features and not fully work.
MVP is the least feature rich version of the product; it can be deployed and used.
Coursework
Focus on prototyping in the coursework!
You probably don’t have the time to do an MVP.
Assumption
The assumption list can be viewed as a bunch of extension ideas!