Software development methodology notes

Glossary (Agile)

Acceptance Test Driven Development (ATDD)

Acceptance Test Driven Development (ATDD) involves team members with different perspectives (customer, development, testing) collaborating to write acceptance tests in advance of implementing the corresponding functionality.

Acceptance Testing

An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.

AntiPattern

Antipatterns are common solutions to common problems where the solution is ineffective and may result in undesired consequences.

Automated Build

In the context of software development, build refers to the process that converts files and other assets under the developers' responsibility into a software product in its final or consumable form. The build is automated when these steps are repeatable, require no direct human intervention, and can be performed at any time with no information other than what is stored in the source code control repository.

Backlog Refinement

Backlog grooming is when the product owner and some, or all, of the rest of the team refine the backlog on a regular basis to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery.

Behavior Driven Development (BDD)

BDD is a practice where members of the team discuss the expected behavior of a system in order to build a shared understanding of expected functionality.

Burndown Chart

Burndown charts and burnup charts track the amount of output (in terms of hours, story points, or backlog items) a team has completed across an iteration or a project.

Business Agility

Business agility is the ability of an organization to sense changes internally or externally and respond accordingly in order to deliver value to its customers.

Collective Ownership

Collective code ownership is the explicit convention that every team member can make changes to any code file as necessary: either to complete a development task, to repair a defect, or to improve the code's overall structure.

Continuous Deployment

Continuous deployment aims to reduce the time elapsed between writing a line of code and making that code available to users in production. To achieve continuous deployment, the team relies on infrastructure that automates and instruments the various steps leading up to deployment, so that after each integration successfully meeting these release criteria, the live application is updated with new code.

Continuous Integration

Continuous Integration is the practice of merging code changes into a shared repository several times a day in order to release a product version at any moment. This requires an integration procedure which is reproducible and automated.

CRC Cards

Class Responsibility Collaborator (CRC) Cards are an object oriented design technique teams can use to discuss what a class should know and do and what other classes it interacts with.

Customer Development

Customer development is a four-step framework, originally identified by Steve Blank, to discover and validate that you have identified a need(s) that customers have built the right product to satisfy […]

Daily Meeting

The daily meeting is one of the most commonly practiced Agile techniques and presents opportunity for a team to get together on a regular basis to coordinate their activities.

Definition of Done

The definition of done is an agreed upon list of the activities deemed necessary to get a product increment, usually represented by a user story, to a done state by the end of a sprint.

Definition of Ready

Definition of Ready involves creating clear criteria that a user story must meet before being accepted into an upcoming iteration. This is typically based on the INVEST matrix.

Epic

An epic is a large user story that cannot be delivered as defined within a single iteration or is large enough that it can be split into smaller user stories.

Estimation

In software development, an "estimate" is the evaluation of the effort necessary to carry out a given development task; this is most often expressed in terms of duration.

Exploratory Testing

Exploratory testing is, more than strictly speaking a "practice," a style or approach to testing software which is often contrasted to "scripted testing."

Extreme Programming

Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software, and higher quality of life for the development team. XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development.

Facilitation

A facilitator is a person who chooses or is given the explicit role of conducting a meeting.

Frequent Releases

An Agile team frequently releases its product into the hands of end users, listening to feedback, whether critical or appreciative.

⇑ back to top

Given – When – Then

The Given-When-Then formula is a template intended to guide the writing of acceptance tests for a User Story: (Given) some context, (When) some action is carried out, (Then) a particular set of observable consequences should obtain.

Heartbeat Retrospective

The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.

Incremental Development

In an Agile context, Incremental Development is when each successive version of a product is usable, and each builds upon the previous version by adding user-visible functionality.

Information Radiators

"Information radiator" is the term for any of a number of visual displays which a team places in a highly visible location, so that all team members can see the latest information at a glance.

Integration

"Integration" (or "integrating") refers to any efforts still required for a project team to deliver a product suitable for release as a functional whole.

INVEST

The acronym INVEST stands for a set of criteria used to assess the quality of a user story. If the story fails to meet one of these criteria, the team may want to reword it.

Iteration

An iteration is a timebox during which development takes place. The duration may vary from project to project and is usually fixed.

Iterative Development

Agile projects are iterative insofar as they intentionally allow for "repeating" software development activities, and for potentially "revisiting" the same work products (the phrase "planned rework" is sometimes used; refactoring is a good example).

Kanban

The Kanban Method is a means to design, manage, and improve flow systems for knowledge work. The method also allows organizations to start with their existing workflow and drive evolutionary change. They can do this by visualizing their flow of work, limit work in progress (WIP) and stop starting and start finishing.

Kanban Board

A Kanban Board is a visual workflow tool consisting of multiple columns. Each column represents a different stage in the workflow process.

Lead Time

Lead Time is the time between a customer order and delivery. In software development, it can also be the time between a requirement made and its fulfillment.

Milestone Retrospective

A Milestone Retrospective is a team's detailed analysis of the project's significant events after a set period of time or at the project's end.

Minimum Marketable Feature (MMF)

A Minimum Marketable Feature is a small, self-contained feature that can be developed quickly and that delivers significant value to the user.

Minimum Viable Product (MVP)

A Minimum Viable Product is the "version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."

Mob Programming

Mob Programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer.

Mock Objects

Mock Objects (commonly used in the context of crafting automated unit tests) consist of instantiating a test-specific version of a software component.

Niko-niko Calendar

A Niko-niko Calendar is updated daily with each team member's mood for that day. Over time the calendar reveals patterns of change in the moods of the team, or of individual members.

Open Space

When you bring together a group of folks, empower them to co-create their own learning, provide just enough structure to ensure progress, and hit the Start button – that’s Open […]

Pair Programming

Pair programming consists of two programmers sharing a single workstation (one screen, keyboard and mouse among the pair). The programmer at the keyboard is usually called the "driver", the other, also actively involved in the programming task but focusing more on overall direction is the "navigator"; it is expected that the programmers swap roles every few minutes or so.

Personas

Personas are synthetic biographies of fictitious users of the future product.

Planning Poker

An approach to estimation used by Agile teams. Each team member "plays" a card bearing a numerical value corresponding to a point estimation for a user story.

Points (estimates in)

Agile teams generally prefer to express estimates in units other than the time-honored "man-hours." Possibly the most widespread unit is "story points."

Product Backlog

A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome.

Product Owner

The product owner is a role on a product development team responsible for managing the product backlog in order to achieve the desired outcome that a product development team seeks to accomplish.

Project Chartering

A high-level summary of the project's key success factors displayed on one wall of the team room as a flipchart-sized sheet of paper.

Quick Design Session

When "simple design" choices have far-reaching consequences, two or more developers meet for a quick design session at a whiteboard.

Refactoring

Refactoring consists of improving the internal structure of an existing program's source code, while preserving its external behavior.

Relative Estimation

Relative estimation is one of the several distinct flavors of estimation used in Agile teams, and consists of estimating tasks or user stories, not separately and in absolute units of time, […]

Rules of Simplicity

Rules of Simplicity is a set of criteria, in priority order, proposed by Kent Beck to judge whether some source code is "simple enough."

Scrum

Scrum is a process framework used to manage product development and other knowledge work. Scrum is empirical in that it provides a means for teams to establish a hypothesis of how they think something works, try it out, reflect on the experience, and make the appropriate adjustments. That is, when the framework is used properly.

Scrum Master

The scrum master is the team role responsible for ensuring the team lives agile values and principles and follows the processes and practices that the team agreed they would use.

Scrum of Scrums

A technique to scale Scrum up to large groups (over a dozen people), consisting of dividing the groups into Agile teams of 5-10.

Scrumban

Scrumban is a mixture of the Scrum Method and the Kanban Method.

Sign Up For Tasks

Members of an Agile development team normally choose which tasks to work on, rather than being assigned work by a manager.

Simple Design

A team adopting the "simple design" practice bases its software design strategy on a set of "simple design" principles.

Sprint Backlog

A sprint backlog is the subset of product backlog that a team targets to deliver during a sprint to accomplish the sprint goal and progress toward an outcome.

Story Mapping

Story mapping consists of ordering user stories along two independent dimensions based on the order activities occur and sophistication of implementation.

Story Splitting

Splitting consists of breaking up one user story into smaller ones, while preserving the property that each user story separately has measurable business value.

Sustainable Pace

The team aims for a work pace that they would be able to sustain indefinitely.

Task Board

A basic task board is divided into three columns labeled "To Do," "In Progress," and "Done." Cards are placed in the columns reflecting the current status.

TDD

Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.

Team

A "team" in the Agile sense is a small group of people, assigned to the same project or effort, nearly all of them on a full-time basis.

Team Room

The team has the use of a dedicated space for the duration of the project, set apart from other groups' activities.

The Three C’s

"Card, Conversation, Confirmation" is a formula that captures the social nature of user stories.

Three Amigos

Three amigos refers to the primary perspectives to examine an increment of work before, during, and after development. Those perspectives are: Business - What problem are we trying to solve? Development - How might we build a solution to solve that problem? Testing - What about this, what could possibly happen?

Three Questions

The daily meeting is structured around the following three questions: What have you completed? What will you do next? What is getting in your way?

Timebox

A timebox is a previously agreed period of time during which a person or a team works steadily towards completion of some goal.

Ubiquitous Language

Teams use a ubiquitous language to use the vocabulary of a business in the requirements, design discussions and source code for a software product.

Unit Testing

A unit test is a short program fragment which exercises some narrow part of the product's source code and checks the results.

Usability Testing

Usability testing is an empirical, exploratory technique to answer questions such as "how would an end user respond to our software under realistic conditions?"

User Stories

In consultation with the customer or product owner, the team divides up the work to be done into functional increments called "user stories."

User Story Template

The "role-feature-reason" template is one of the most commonly recommended aids to write user stories: As a ... I want ... So that ...

Velocity

Velocity is the total effort estimates associated with user stories that were completed during an iteration.

Version Control

Version control is not merely "good practice" but an enabler of a number of Agile practices, such as continuous integration

Organising Source Code

Organizing source code files and folders is essential for maintaining a clean, efficient, and easily navigable codebase. Here are some best practices for organizing your source code effectively.

Consistent Naming Conventions:

Use a consistent and meaningful naming convention for files and folders. This makes it easier to understand the purpose of each component.

Separation of Concerns:

Follow the principle of separation of concerns. Group related code and resources together in separate directories. For example, keep HTML, CSS, and JavaScript files for a web page in separate folders.

Group related files and folders together. For example, put all of the source code files for a single module or component in the same folder, and group all of the test files for that module or component in a separate folder.

Modularization

Break your code into modular components. Each module or class should have its own file. This makes it easier to find and maintain specific parts of your code.

Use Meaningful Directories

Create directories with descriptive names that reflect the purpose of the contained files. Avoid using generic names like "misc" or "temp."

Keep your project's root directory clean, only include essential files and folders. Things like documentation, test files, and build artefacts should be kept in subfolders.

Layered Architecture

If your project follows a specific architectural pattern (e.g., MVC, MVVM), organize your codebase accordingly. Separate models, views, and controllers into distinct directories.

Top-Level Categories

Consider having top-level directories for different categories of code, such as "src" for source code, "tests" for unit tests, "docs" for documentation, and "config" for configuration files.

Version Control Integration

If you're using version control (e.g., Git), keep version control files (e.g., `.gitignore`, `.gitattributes`) at the root of your project.

Use version control software to track changes to your source code files. This makes it easy to revert to a previous version of a file if something goes wrong.

Dependency Management

Store configuration files related to dependency management tools (e.g., `package.json` for Node.js projects) at the root of your project.

Asset Management

Keep assets (images, fonts, etc.) in dedicated directories within your project to maintain clear separation from source code.

Avoid Overly Deep Hierarchies

While organizing directories is important, avoid creating overly deep directory hierarchies. A balance between organization and simplicity is key.

Use a logical hierarchy of folders to organize your files. This makes it easy to navigate your project and find the files you need.

Documentation

Include README files in directories to provide information about the purpose and usage of the code within. This helps other developers (and your future self) understand the code's structure.

Naming Files

Choose descriptive and consistent file names that reflect the content. For example, use "user-authentication.js" instead of generic names like "file1.js" or "util.js."

Use a consistent naming convention for all files and folders. This makes it easier to find and understand the purpose of each file and folder.

Code Style and Linting

Enforce code style and linting rules to maintain consistency in your codebase. Many programming languages and frameworks have tools and guidelines for this.

Comments and Documentation

Add comments and documentation to your code to explain its functionality, especially for complex or non-intuitive sections.

Use comments to document your code. This makes it easier for others to understand how your code works and how to use it.

Tests and Test Data

Keep unit tests, integration tests, and test data separate from your main codebase. Place them in dedicated directories, such as "tests" or "test-data."

Build and Deployment Scripts

Store build scripts, deployment configurations, and CI/CD pipeline files in specific directories, like "build" or "deploy."

Backup and Archive

Archive and store old or deprecated code separately to avoid cluttering the active codebase.

Refactoring and Cleanup

Regularly review and refactor your code organization as the project evolves. Remove unused files and folders to maintain a clean codebase.

Tools and IDE Support

Leverage tools and integrated development environments (IDEs) that help with code organization and navigation, such as code refactoring, project search, and code folding.

Collaborative Considerations

If you're working on a team, establish coding standards and conventions that everyone follows to ensure consistency in code organization.

Minimise Folder Contents

Keep the number of files and folders in each directory to a minimum. This makes it easier to find what you're looking for and reduces the risk of clutter.

Separate Source Code from 3rd Party Content

Separate the source code from third-party libraries, frameworks, and dependencies. This makes it easier to manage dependencies, update them and also it makes the code more readable.

The key is to keep it consistent, simple, and well-documented to make your codebase more manageable and maintainable over time.