Todo
Catch up on week 1 slides. Beyond here is starting in week 2 (but using week 1 slides)
Agile Project Management
Traditional
- Plan driven
- Cost structure known ahead of time (usually)
- Time known ahead of time (approximately)
Scrum
| Scrum Term | Definition |
|---|---|
| Development team | A self-organizing group of software developers, which should hbe no more than seven people (ideally 4 people). They are responsible for developing the software and other essential project documents. |
| Potentially shippable product increment | The software increment that is delivered from a sprint. The idea is that this should be “potentially shippable” (not always achieveable). |
| Product backlog | A to-do list that the scrum team must tackle. E.g. github issues, JIRA board |
| Product owner | An individual or small group of people whos job is to identify necessary product features or requirements and ensure the project is on track. |
| Scrum | Standup meeting. What have you done, what are you currently doing, what are you going to do. |
| Scrum Master | Essentially the manager. The person that is responsible for ensuring that the Scrum process is followed and guides the team in the effective use of Scrum. They are responsible for interfacing with the rest of the company and ensuring the Scrum team is not diverted by outside interference. |
| Sprint | A development iteration. Usually 2 or 4 weeks. |
| Velocity | An estimate of how much product backlog effort a team can cover in a single sprint. Used to better understand what amount of work can be covered in a sprint. A team performance metric. |
Requirements document
- Decided and developed during the start of each sprint
- Things that are unstable at the end of a sprint are placed in the backlog
- Every member of the team has a good idea of what everyone else is working on (team visibility)
- Trust between customers & developers
Sprint review
Determines:
- backlog
- release product
Distributed Scrum
- Scrum master should be located with the development team so that they are aware of everyday problems
- Product owner should visit the developers and try to establish a good relationship with them
- Videoconferencing between the product owner and the development team
- A common development environment for all teams
- Continuous integration, so that all team members can be aware of the state of the product at any time
- Real-time communications between team members for informal communication, particularly instant messaging and video calls
Agile principles and organizational practice
| Principle | Practice (simplified) |
|---|---|
| Customer involvement | Customers need to work closely with the team, but they’re often too busy or limited. |
| Embrace change | It’s hard to handle changes when many people want different priorities. |
| Incremental delivery | Short development cycles don’t always match with long-term business or marketing plans. |
| Maintain simplicity | Teams may skip simplifying the system because of tight deadlines. |
| People, not process | Agile works best if team members have the right personalities and can collaborate well. |
graph TD A[System] --> B[Type] A --> C[Lifetime] B --> D[Scale] C --> E[Regulation]
graph TD A[Team] --> B[Technology] A --> C[Distribution] A --> D[Competence]
graph TD A[Organization] --> B[Contracts] A --> C[Delivery] A --> D[Culture]
System issues
- How large is the system being developed?
- Agile methods are most effective with a relatively small co-located team who can communicate informally
- E.g. large scale plane software/train management software
- What type of system is being developed?
- Systems that require a lot of analysis before implementation need a fairly detailed design to carry out this analysis
- What is the expected system lifetime?
- Long-lifetime systems require documentation to communicate the intentions of the system developers to the support team
- E.g. Brock still has services using COBOL
- Is the system subject to external regulation?
- If a system is regulated you will probably be required to produce detailed documentation as a part of the system safety case
- E.g. financial software has to abide by regulations
- How good are the designers and programmers in the development team?
- It is sometimes argued that agile methods require higher skill levels than plan-based approaches in which programmers simply translate a detailed design into code
- How is the development team organized?
- Design documents may be required if the team is distributed
- What support technologies are available?
- IDE support for visualization and program analysis is essential if design documentation is not available
- git
Organizational issues
- Traditional engineering = plan-based development → norm in engineering
- Organizations expect detailed system specifications
- Customer reps needed for feedback on increments
- Agile challenge: fitting informal, flexible style into culture of heavy documentation
Agile methods for large systems
- Large systems = collections of smaller systems → each built by separate teams (often in different locations/time zones)
- Many are brownfield systems → must integrate with existing systems, making flexibility/incremental dev harder
- Brownfield development/systems = middleware
- Integration work = mostly system configuration, not new code development
Large system development
- Large systems face rules/regulations that limit how they can be developed
- E.g. flight control system
- They have long procurement & dev cycles → hard to keep the same knowledgeable team (people leave/move)
- Large systems involve a diverse set of stakeholders → impossible to include everyone in the process
IBM’s Agility at Scale model
Scaling up to large systems
- A completely incremental approach to requirements engineering is impossible
- There cannot be a single product owner or customer representative
- For large systems development, it is not possible to focus only on the code of the system
- Cross-team communication mechanisms have to be designed and used
- Continuous integration is practically impossible. However, it is essential to maintain frequent system builds and regular releases of the system
Agile methods across organizations
- Project managers without agile experience may resist adopting it.
- Large orgs = strict quality procedures & bureaucracy → clash with agile.
- Agile works best with skilled teams, but large orgs = wide variation in skills.
- Cultural resistance common in orgs with strong traditional engineering history.
- Engineers are trained to be thorough, not necessarily agile/flexible.
Info
End of week 1 slides, start of week 2 slides
Requirement Engineering
Purpose
- Define a description of the needs for the required system
Functional
- What will the system provide to the end user?
- Statements of service
- Users will use the system to achieve their goals
- How does the system fulfil this goal?
- What types of data are we dealing with?
- Organization will receive a benefit
Non-functional
What are the constraints of the system?
- What hardware is available?
- What other systems will interface with this system?
- Response time
- External regulatory constraints
- Security of data
- Regulatory certification
Readers of different types of requirements specification
- End users will have to be explained using different terminology (less technical, etc.)
- Focus on features, “selling the product”
- Users are people & are more interested in task completion
- Technical users or developers will be explained using more in depth info etc.
- Programmers need more detail, require unambiguous descriptions
Need for requirements
We need to determine what the system will ultimately look like.
- Required to define a contract (not just a financial doc, also is a list of requirements)
- Must be specific (cannot say ”… until I am satisfied” → owner can never be satisfied → contract is never completed)