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 ClientsDesigning a Kickoff Meeting
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.1 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.2 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 withtest_
- Using
pytest
, we can run a set of tests usingpython -m pytest
followed by a specific file containing a set of tests, or a directory containing many test files with filenames beginning withtest_
- We can use
-v
when runningpytest
to produce more verbose output that explicitly lists each test that is run
2.3 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.4 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.3 The Agile Development ProcessScrum PhilosophyScrum 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.4 Anatomy of an Agile SprintEvents of a SprintSprint 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.
Day 3: Undertaking our First Sprint
- FIXME
3.1 Sprint 1 Work Block
- FIXME
3.2 Sprint 1 Review Meeting
- FIXME
3.3 Sprint 1 Retrospective
- FIXME
3.4 Mentoring Session
- FIXME
Day 4: Our Second Sprint: Preparing to Deliver
- FIXME
4.1 Prepare Code for Release
- FIXME
4.2 Sprint 2 Planning Meeting
- FIXME
4.3 Sprint 2 Work Block
- FIXME
4.4 Sprint 2 Review Meeting
- FIXME
4.5 Sprint 2 Retrospective
- FIXME
4.6 Reflection
- FIXME
Day 5: Deliver to Clients
- FIXME
5.1 Prepare to Delivery
- FIXME
5.2 Delivery Meeting
- FIXME
5.3 Reflection
- FIXME