Collaboration and project workflow
Real software is built by teams. Shared workflows for planning, reviewing, and integrating work keep everyone productive and the code healthy.
Development methodologies
The traditional waterfall model runs requirements, design, implementation, testing, and maintenance in sequence, which suits stable, well-understood projects. Agile approaches, inspired by the 2001 Agile Manifesto, deliver working software in short iterations, gather feedback often, and adapt plans as needs change. Most teams today use some agile variant.
Scrum and Kanban
Scrum organises work into fixed sprints, often two weeks, with a prioritised backlog, sprint planning, daily stand-up meetings, a sprint review, and a retrospective to improve the process. Roles include the product owner, who prioritises, and the scrum master, who facilitates. Kanban instead visualises work on a board with columns such as To do, In progress, and Done, limiting work in progress.
User stories and issues
Requirements are often written as user stories: 'As a shopper, I want to save items for later so that I can buy them next week.' Each has acceptance criteria defining done. Teams track stories, bugs, and tasks as issues in tools such as GitHub Issues or Jira, with labels, assignees, and links to code changes.
Pull requests and code review
On platforms such as GitHub, developers propose changes through pull requests (merge requests on GitLab). Teammates review the diff, comment, and request changes before approval. Review catches bugs, spreads knowledge, and keeps style consistent. Good reviews are timely, specific, and kind, focusing on the code rather than the person, and small pull requests get better reviews.
Branching workflows
In trunk-based development, developers merge small changes into main frequently, often daily, protected by tests and feature flags that hide unfinished work. GitHub flow uses short-lived feature branches merged through pull requests. Long-lived branches that drift for weeks lead to painful merges and are generally avoided.
Documentation
A good project has a README explaining what it does, how to install and run it, and how to contribute. Code comments and docstrings document details; architecture decision records explain significant design choices and why they were made. Documentation that lives in the repository is versioned and reviewed alongside the code.
Open-source collaboration
Open-source projects accept contributions from anyone: fork the repository, make changes on a branch, and open a pull request. Projects publish contribution guidelines, codes of conduct, and licences. Contributing, even by fixing documentation or reporting clear bugs, is an excellent way to learn and build a public portfolio.
Worked example
A team using two-week sprints selects eight user stories from the backlog. One story, 'As a user, I want to reset my password by email', has acceptance criteria: the link expires after 30 minutes and works once. A developer creates a branch, writes code and tests, and opens a pull request; a reviewer spots that the expiry check uses local time instead of UTC; it is fixed, CI passes, and the story moves to Done.
Key takeaways
Waterfall runs phases in sequence; agile (2001 Manifesto) iterates with frequent feedback. Scrum uses sprints, backlogs, stand-ups, reviews, and retrospectives, with product owner and scrum master roles; Kanban uses boards and work-in-progress limits. User stories with acceptance criteria capture requirements; issue trackers organise work. Pull requests and kind, specific code reviews protect quality. Trunk-based development and short-lived branches avoid painful merges. READMEs and decision records document projects. Open source welcomes contributions through forks and pull requests.
Flashcard
Sequential development phases
Check your understanding
Why do teams prefer small pull requests?