Software Development Life Cycle for Small Teams

1. The seven phases and where their output goes

Tasks in a small team often overlap, and one person may work on several phases. The table shows what each phase produces, what form the final output takes and which AboutTheApp category its link belongs in.

2. Requirements: link the brief documents in AboutTheApp

Requirements analysis answers the question of what the app should do and for whom. The output is usually a brief, a list of requirements or a PRD, which is shared with the team and the client. Once the document exists, create the app and add the first link to it. An app in AboutTheApp is the project you work on, so keep an index of all the materials there from the start. For a structure you can reuse, see the PRD template.

1. 1

   Add a link to the brief

   In the AboutTheApp dashboard, open the app's editor, go to the **Links & Resources** tab and click **Add resource**. Pick the **Analysis & Planning** category and label the link something like "Brief in Confluence".

2. 2

   Mark sensitive documents as private

   Mark briefs with contract terms or internal information as private. A private link is visible only to signed-in team members and to people who enter the unlock code.

3. Architecture design: diagrams and schemas

Architecture describes what the app is built from and how its parts communicate. Diagrams you can version with the code are written in a format such as Mermaid. A diagram in the repository is kept up to date together with the source code, which is its main advantage.

Write technology decisions as short records in the repository, with the date and the reason for each choice, including why you rejected the other options. When problems come up later, you can see why the team decided the way it did.

1. 1

   Add a link to the diagrams

   In the **Source Code & Architecture** category, add a link to the folder with the diagrams or to the architecture file. Label the link with what it contains, for example "Architecture (Mermaid, docs/architecture)".

4. Planning: link the board and the backlog

The architecture and the brief turn into a backlog of tasks, which the team plans in sprints or continuously. The Kanban vs. Scrum guide explains how to choose an approach, and the story points guide covers estimating how big each task is. The board changes every day, so store a link to the board in AboutTheApp, not a copy of its current state.

1. 1

   Add the board or backlog

   In the **Issue Tracking** category, add a link to the sprint board or the backlog. If you have more than one board, for example one for development and one for support, add each of them and adjust the label to what the board is for.

5. Implementation: the repository and access to services

Put the source code in a repository. The Git branching strategy guide explains how to organize merging changes into the source code. Passwords and API keys don't belong in the repository. Store them in a password manager or in CI secrets; the .env file guide has more detail.

1. 1

   Add a link to the repository

   In the **Source Code & Architecture** category, add a link to the main branch of the repository. If the repository is private, mark the link as private.

2. 2

   Keep a list of the services the app uses

   List the services the app connects to in the **Links & Resources** tab, with a link to where each one is managed. Don't enter keys into AboutTheApp; they belong in your password manager or CI secrets. The third-party services list guide walks through the setup.

6. Testing: environments and the test plan

Tests check that the app behaves as the brief says after each change. Most teams run them on a separate environment that differs from production. The smoke testing guide covers the basic check, and the staging environment guide explains how to test on a pre-production environment. The test plan and the test results belong to the acceptance criteria and usually live in Confluence or a testing tool.

1. 1

   Check the testing environment

   The **Environments & Versions** tab shows the environments where the app runs. Each one shows the version currently deployed to it.

2. 2

   Add a link to the test results

   Store a link to the test plan or the test results in the **Monitoring & Quality** category.

7. Release and deployment: versions and the deployment record

A release brings the previous phases together into one version. The app versioning guide covers version numbers, and the release notes template shows how to write the notes. If CI/CD runs your deployments, the GitHub Actions guide shows how each deployment writes its version and environment to AboutTheApp, so you don't have to enter them by hand.

1. 1

   Add the release notes

   Attach the release notes to the matching app version, or let CI/CD write them for you.

2. 2

   Check the deployment record

   The deployment record stays on the app's **Environments & Versions** tab.

8. Operations and maintenance: work after the release

After the release, maintenance of the app begins: fixes, dependency updates, monitoring and support. The software maintenance guide describes a maintenance plan, and the application inventory guide covers the list of apps the team runs. Logs and monitoring belong to the app just as the repository does, so add their links to the app too.

1. 1

   Add the monitoring and logs

   Store links to monitoring and logs in the **Monitoring & Quality** category. Support then doesn't have to hunt for the details of the running app.

2. 2

   Store the provider contacts

   Add the contacts for hosting, service providers and support to the **Support** category, so they're at hand when something goes down.

9. What belongs in AboutTheApp and what stays elsewhere

AboutTheApp doesn't replace Confluence, Jira or the repository. Documents and code stay in the tools the team uses. AboutTheApp keeps the links in one place for each app and, where relevant, for the customer and environment they belong to. When a tool changes, you only update the link.

Frequently asked questions