Industry Skills Training in Agile: Key Points

Day 1: Landscape of approaches and undertaking an example project

FIXME

1.1 Welcome to the Course

FIXME

1.2 Software Development Process and the Landscape of Approaches

The typical stages of a software development process are: requirements gathering, design, implementation, testing, deployment and maintenance
These stages are arranged differently in different models of software development
The Waterfall model follows the stages in a set, sequential order
The V-Model emphasises the importance of testing and validation at each stage
In iterative development, a large application is built in smaller, manageable parts called iterations.
Boehm’s Spiral is an iterative, risk-driven approach to software development
Agile software development is any iterative method that follows a set of Agile principles: Individuals and interactions over processes and tools; Working software over comprehensive documentation; Customer collaboration over contract negotiation; Responding to change over following a plan.
Any model can be used for any software development project but some may suit particular types of projects better than others
Scrum is one of the most popular Agile frameworks. Later in this course we will talk more about Scrum so that you are able to use it to run your own Sprints on a project.
Software development is concerned with delivering a project whereas project management will also cover the wider project aspects.

1.3 User Stories and Capturing Project Requirements

User Stories help to understand project needs from the perspective of the client
User Stories follow the format As a [type of user], I want [an action] so that [benefit]
Clear and well understood requirements are fundamental to a successful project
Evidence that most project errors are introduced during the handling of requirements
Requirements will change over time, and we need to allow and manage for that
Requirements are more than just features: non-functional requirements capture the environment and how and in what way the software should operate and be provided
A product backlog is a prioritised list of desired product functionality owned by the product owner (typically the client)

1.4 Estimation, Prioritisation, and Stakeholder Management

GitHub Projects provide project boards to organise issues and visualise the status of a project in terms of its requirements
Kanban boards consists of columns (which represent statuses) and cards (which represent tasks), which are moveable between columns
GitHub Project Boards are owned by the creating user or organisation, and not any particular repository
GitHub Boards can contain either board-specific cards, or issues imported from GitHub repositories
Estimation is a foundation for prioritisation
T-shirt estimation is a technique employed early in a project that assigns a t-shirt size to each task in order to estimate their size relative to each other
MoSCoW prioritisation classifies requirements either as Must Have (MH), Should Have (SH), Could Have (CH) or Won’t Have (WH)
Using a 60%/20%/20% effort ratio of MH/SH/CH ensures a 40% safety margin of effort for a project

1.5 Working with ClientsCommunicating with Clients Designing a Kickoff Meeting

Avoid jargon by translating technical concepts into plain, client-friendly language.
Clarify vague requests by asking follow-up questions and confirming understanding.
Use the concept of a Minimum Viable Product to help clients focus on the core of their product.
Set expectations realistically by under-promising and including contingency time.
Be transparent about limitations and clearly explain the impact of technical decisions.
Manage scope creep by showing how new requests affect cost, time, or quality.
Take the lead in client meetings to ensure key information is gathered.
Use a clear agenda to guide productive and structured client discussions.
Record and share meeting notes to capture decisions, questions, and action points.

Day 2: Technical Skills and Best Practices within an Agile Way of Working

FIXME

2.1 Collaborative Workflow: Branches and Merging Strategies

Infrastructure and tooling used by a team must support agreed healthy development processes and practices but not unnecessarily dictate them
Once you’ve set up personal SSH access to GitHub from a machine, you do no need to use passwords
Separate features or bug fixes should be developed on separate repository branches and merged to the main branch when ready
Developing code on feature branches enables the main branch to remain working and clear of unfinished features or bug fixes, and prevents confusion across separate development activities
If feature branches end up being unproductive “dead ends”, they can simply be deleted
A fast-forward merge simply adds commits to the end of a destination branch
A 3-way merge with merge commit creates a new commit on the destination branch comprised of the commits on the feature branch
A rebase and merge rewrites the history

2.2 Collaborative Workflow: Pull Requests and Code Reviews

Working collaboratively is a cornerstone of successful software development
Code reviews can be short and informal, contribution-oriented, or formal
The first hour of code review matters most
Code review helps to increase code quality, ensure practices and conventions are met consistently, and increase codebase knowledge across the team
GitHub supports code review as part of pull requests
Aim to close pull requests as soon as is convenient, to avoid increased divergence from the main codebase

2.3 Introduction to Automated Testing

Testing code is the process of verifying that your code behaves as expected and continues to do so as it evolves
Code complexity often increases beyond our ability to fully understand it
Code testing allows us to discover the existence of issues before they become a potentially much larger issue when using the code in its intended environment
Unit tests verify in isolation that a small code component, such as a function or class, behaves correctly with known inputs
Integration tests verify correct behaviour of multiple components or modules working together, at a higher level
System tests evaluate software as a complete, integrated system, focuses on validating the entire application’s functionality from end to end, typically from a user’s perspective
Test mocking involves replacing a code component, such as a function or class, with a simplified, controllable version - known as a mock - to make testing easier by mimicing how the real component works
Tests written in pytest are defined as functions that return either true or false, and have a function name beginning with test_
Using pytest, we can run a set of tests using python -m pytest followed by a specific file containing a set of tests, or a directory containing many test files with filenames beginning with test_
We can use -v when running pytest to produce more verbose output that explicitly lists each test that is run

2.4 Writing Unit Tests

Running automated tests is generally a rapid process that takes far less time than testing code manually
When we change our code, re-run existing tests to ensure we haven’t broken anything or otherwise compromised the desired behaviour of our code
When we change our code, consider if a new test should be added to verify it works correctly
If we fix an error in our code, consider adding a regression test to identify if it returns

2.5 Using Continuous Integration

Automation saves time and improves reproducibility by capturing repeatable processes like testing, linting, and building code into scripts or pipelines
Continuous Integration (CI) is the practice of automatically running tasks and checks each time code is updated, helping catch issues early and improving collaboration
Integrating smaller, frequent code updates is more manageable and less error-prone than merging large changes all at once
CI pipelines can run on many platforms and environments using cloud-based services (e.g. GitHub Actions, Travis CI) or self-hosted solutions (e.g. Jenkins, GitLab CI)
GitHub Actions workflows are defined using YAML
A GitHub Actions workflow defines a sequence of jobs, and each job contains a sequence of steps, which each represent a specific “action” or task to perform
GitHub Actions log the progress of a build which can be viewed in GitHub

2.6 The Agile Development ProcessScrum Philosophy Scrum ValuesScrum PillarsScrum Artifacts and CommitmentsScrum Team

Scrum is an iterative, incremental, minimalist, and deliberately incomplete framework emphasizing empiricism and lean thinking.
Scrum is built upon five core values: commitment, focus, openness, respect, and courage.
Scrum relies on the three interconnected pillars of transparency, inspection, adaptation.
A Scrum Team consists of Developers, a Product Owner, and a Scrum Master.
Scrum makes use of three main artifacts which are the Product Backlog, Sprint Backlog, and Increment.
The Sprint Backlog includes a sprint goal, a subset of items from the Product Backlog selected for the current sprint, and an actionable plan for completing them.
The Increment is the usable output from a sprint that must meet the Definition of Done, which is a checklist of quality standards for the Increment.
Scrum roles and structures are defined but adaptable and teams should adjust them to fit their context.

2.7 Anatomy of an Agile SprintEvents of a Sprint Sprint Planning for the Coffee Beans Analysis Project

A Sprint is a fixed-length event in Scrum, usually between one week and one month in length.
The four Scrum Events are Sprint Planning Meeting, Daily Scrum Meeting, Sprint Review, and Sprint Retrospective.
Sprint Planning answers: Why is this Sprint valuable? What can be done? How will the work get done?
The outcome from the Sprint Planning Meeting is the Sprint Backlog containing the Sprint Goal, subset of Product Backlog items, and a plan for delivering the Increment.
The Daily Scrum Meeting is a 15-minute meeting for the Scrum Master and Developers to inspect progress, adjust plans, and resolve blockers.
The Sprint Review allows the Scrum Team and stakeholders to inspect the Increment and adapt the Product Backlog.
The Sprint Retrospective is a time for the Scrum Team to reflect on the Sprint and identify improvements.
All Scrum Events promote transparency, inspection, and adaptation to improve product and team effectiveness.