Definition of done - Revision history

Jakobbuis: clarify ambiguous requirements with conclusions from the retrospective meeting d.d. 28-06-2024

2024-06-30T19:57:06Z

clarify ambiguous requirements with conclusions from the retrospective meeting d.d. 28-06-2024

← Older revision		Revision as of 12:57, 30 June 2024
Line 7:		Line 7:
	== Quality ==		== Quality ==

	In order to keep the code maintainable and relatively bug-free, as well as broaden the amount of people that know about a certain feature's implementation, we expect PRs to be peer-reviewed ~~and senior-reviewed (~~someone senior to the project, or, if ~~not available~~, ~~senior~~ in the company).		In order to keep the code maintainable and relatively bug-free, as well as broaden the amount of people that know about a certain feature's implementation, we expect PRs to be peer-reviewed by one other person. Ideally, this would be someone senior who knows more about the project than you do; or if you know the most, a more experienced person in the company. If you're written this feature using pair-programming, no code review after the fact is required.

	Any automated analysis that runs on a project should also be without errors. When there are warnings, it should be explained ''why'' the warning isn't resolved. Yes, some of this tooling sometimes gets it wrong, but overall they make the code more consistent in style, and it often prevents a lot of common issues.		Any automated analysis that runs on a project should also be without errors. When there are warnings, it should be explained ''why'' the warning isn't resolved. Yes, some of this tooling sometimes gets it wrong, but overall they make the code more consistent in style, and it often prevents a lot of common issues.

SleeplessByte: Fix format

2021-03-05T14:03:53Z

Fix format

← Older revision		Revision as of 07:03, 5 March 2021
Line 1:		Line 1:
	At Delft Solutions we aim to have a shared understanding what it takes to release an incremental update to one of our projects. Having a shared understanding of what it means to call something done also means we don't have to ask "But is it ~~_really_~~ done?" or "Hey you said it was done but I don't see it, where is it?".		At Delft Solutions we aim to have a shared understanding what it takes to release an incremental update to one of our projects. Having a shared understanding of what it means to call something '''done''' also means we don't have to ask "But is it ''really'' done?" or "Hey you said it was done but I don't see it, where is it?".

	== Functional Requirements ==		== Functional Requirements ==

Thexa4: /* Non-Functional Requirements */

2021-03-05T14:00:17Z

Non-Functional Requirements

← Older revision		Revision as of 07:00, 5 March 2021
Line 15:		Line 15:
	== Non-Functional Requirements ==		== Non-Functional Requirements ==

	* ~~No known defects~~		* We make things better, not worse
	* ~~No build failures~~		* Build errors and warnings must be solved or explained (and accepted)
	* No errors ~~in coding standards~~ (~~automated analysis~~)
	* Existing tests passed		* Existing tests passed
	* Peer code review passed		* Peer code review passed
	* Deployed (if applicable)		* Deployed (if applicable)

SleeplessByte at 13:55, 5 March 2021

2021-03-05T13:55:34Z

← Older revision		Revision as of 06:55, 5 March 2021
Line 3:		Line 3:
	== Functional Requirements ==		== Functional Requirements ==

	These are the ~~_business_~~ requirements that emerge through conversation about a particular issue or feature, as well as the requirements listed in the issue (acceptance criteria).		These are the ''business'' requirements that emerge through conversation about a particular issue or feature, as well as the requirements listed in the issue (acceptance criteria).

	== Quality ==		== Quality ==
Line 9:		Line 9:
	In order to keep the code maintainable and relatively bug-free, as well as broaden the amount of people that know about a certain feature's implementation, we expect PRs to be peer-reviewed and senior-reviewed (someone senior to the project, or, if not available, senior in the company).		In order to keep the code maintainable and relatively bug-free, as well as broaden the amount of people that know about a certain feature's implementation, we expect PRs to be peer-reviewed and senior-reviewed (someone senior to the project, or, if not available, senior in the company).

	Any automated analysis that runs on a project should also be without errors. When there are warnings, it should be explained ~~_why_~~ the warning isn't resolved. Yes, some of this tooling sometimes gets it wrong, but overall they make the code more consistent in style, and it often prevents a lot of common issues.		Any automated analysis that runs on a project should also be without errors. When there are warnings, it should be explained ''why'' the warning isn't resolved. Yes, some of this tooling sometimes gets it wrong, but overall they make the code more consistent in style, and it often prevents a lot of common issues.

	The code must be tested. This can be a manual test or an automated test. If changes are made after the test has been performed, the test must be performed again.		The code must be tested. This can be a manual test or an automated test. If changes are made after the test has been performed, the test '''must''' be performed again.

	== Non-Functional Requirements ==		== Non-Functional Requirements ==

	- No known defects		* No known defects
	- No build failures		* No build failures
	- No errors in coding standards (automated analysis)		* No errors in coding standards (automated analysis)
	- Existing tests passed		* Existing tests passed
	- Peer code review passed		* Peer code review passed
	- Deployed (if applicable)		* Deployed (if applicable)

SleeplessByte: Created page with "At Delft Solutions we aim to have a shared understanding what it takes to release an incremental update to one of our projects. Having a shared understanding of what it means..."

2021-03-05T13:54:41Z

Created page with "At Delft Solutions we aim to have a shared understanding what it takes to release an incremental update to one of our projects. Having a shared understanding of what it means..."

New page

At Delft Solutions we aim to have a shared understanding what it takes to release an incremental update to one of our projects. Having a shared understanding of what it means to call something **done** also means we don't have to ask "But is it _really_ done?" or "Hey you said it was done but I don't see it, where is it?".

== Functional Requirements ==

These are the _business_ requirements that emerge through conversation about a particular issue or feature, as well as the requirements listed in the issue (acceptance criteria).

== Quality ==

In order to keep the code maintainable and relatively bug-free, as well as broaden the amount of people that know about a certain feature's implementation, we expect PRs to be peer-reviewed and senior-reviewed (someone senior to the project, or, if not available, senior in the company).

Any automated analysis that runs on a project should also be without errors. When there are warnings, it should be explained _why_ the warning isn't resolved. Yes, some of this tooling sometimes gets it wrong, but overall they make the code more consistent in style, and it often prevents a lot of common issues.

The code must be tested. This can be a manual test or an automated test. If changes are made after the test has been performed, the test **must** be performed again.

== Non-Functional Requirements ==

- No known defects
- No build failures
- No errors in coding standards (automated analysis)
- Existing tests passed
- Peer code review passed
- Deployed (if applicable)