Merge pull request #33 from Niodus/update

Update

Author: idmac75

LICENSE.md

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) [2022] [Scott McCarthy]
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

docs/best-practices/continuous-planning/Design-Patterns.md

@@ -0,0 +1,12 @@
+# Design Patterns
+
+The design patterns section recommends patterns of software and architecture design.
+This section provides a curated list of commonly used patterns from trusted sources.
+Rather than duplicate or replace the cited sources, this section aims to compliment them with suggestions, guidance, and learnings based on firsthand experiences.
+
+## Subsections
+
+* [Data Heavy Design Guidance](data-heavy-design-guidance/README.md)
+* [Object Oriented Design Reference](object-oriented-design-reference/README.md)
+* [Distributed System Design Reference](distributed-system-design-reference/README.md)
+* [REST API Design Guidance](rest-api-design-guidance/README.md)

docs/best-practices/continuous-planning/agile-development/sprint-planning.md

@@ -1,5 +1,9 @@
-# Sprint Planning
+---
+title: Sprint Planning
+summary: A guide to sprint planning
+author: Scott McCarthy
 
+---
 ## Overview
 
 During the [sprint planning](https://www.agilealliance.org/glossary/sprint-planning), the team discusses and agrees on the scope for the upcoming sprint.
@@ -30,9 +34,9 @@ Specific roles:
 
 [**Product owner**](https://www.agilealliance.org/glossary/product-owner/):
 
-- Prior to the sprint planning: performs some [backlog refinement](/continuous-planning/agile-development/backlog-management/backlog-refinement.md) to ensure that each story that they want to propose for the new sprint (*)  
+- Prior to the sprint planning: performs some [backlog refinement](backlog-management.md#backlog-refinement) to ensure that each story that they want to propose for the new sprint (*)  
 - Is in the correct position in the backlog, by right priority order.
-- Is attending the [definition of ready](/continuous-planning/agile-development/team-agreements/definition-of-ready.md)- Do NOT pre-assign stories to the future sprint. This is the purpose of the sprint planning.
+- Is attending the [definition of ready](team-agreements/definition-of-ready.md)- Do NOT pre-assign stories to the future sprint. This is the purpose of the sprint planning.
 - During the meeting:
   - Clarify team's questions and improve the story accordingly, if necessary.
   - Describe to the team the stories that they propose for the sprint.
@@ -41,11 +45,11 @@ Specific roles:
 
 - Listen to the product owner story description.
 - Ask questions to make sure everyone understands each story properly.
-- [Estimate](/continuous-planning/agile-development/sprint-planning/estimation.md) the effort for each backlog item, as a team.
+- [Estimate](sprint-planning/estimation.md) the effort for each backlog item, as a team.
 - Split each story into tasks.
 - (Optional) self assign first task to team members.
 
-*(\*) some teams find useful to define a **[Definition of ready](/continuous-planning/agile-development/team-agreements/definition-of-ready.md)** that describes the list of things that needs to be done in each story before the **product owner** can propose it for a **sprint**. The list proposed here is the classic minimal definition of ready.*
+*(\*) some teams find useful to define a **[Definition of ready](team-agreements/definition-of-ready.md)** that describes the list of things that needs to be done in each story before the **product owner** can propose it for a **sprint**. The list proposed here is the classic minimal definition of ready.*
 
 ## Impact
 
@@ -68,7 +72,7 @@ Prior to the meeting:
 
 - Set sprint goal.
 - Make sure the backlog is prioritized.
-- Make sure each story that is a candidate for next sprint is [ready](/continuous-planning/agile-development/team-agreements/definition-of-ready.md).
+- Make sure each story that is a candidate for next sprint is [ready](team-agreements/definition-of-ready.md).
 
 During the meeting:
 
@@ -81,4 +85,4 @@ During the meeting:
 Other considerations:
 
 - Take into account off days (vacations, national holidays, unavailability).
-- When the backlog reaches a size that makes it difficult to manage by one team, you might want to split into different work streams. This might require thinking about [scrum of scrums](/continuous-planning/agile-development/scrum-of-scrums.md) and all related ceremonies.
+- When the backlog reaches a size that makes it difficult to manage by one team, you might want to split into different work streams. This might require thinking about [scrum of scrums](scrum-of-scrums.md) and all related ceremonies.

docs/best-practices/continuous-planning/agile-development/sprint-planning/Sprint-Structure.md

@@ -1,4 +1,10 @@
-# Goals for Estimation
+---
+title: Estimation
+summary: A guide to estimating stories and tasks
+author: Scott McCarthy
+date: 18/08/2022
+
+---
 
 When a team adopts agile, as the team works together, the process of estimating
 new work becomes more effective. Over time, they get a sense for how their team

…evelopment/sprint-planning/Estimation.md …evelopment/sprint-planning/estimation.mddocs/best-practices/continuous-planning/agile-development/sprint-planning/Estimation.md renamed to docs/best-practices/continuous-planning/agile-development/sprint-planning/estimation.md docs/best-practices/continuous-planning/agile-development/sprint-planning/Estimation.md renamed to docs/best-practices/continuous-planning/agile-development/sprint-planning/estimation.md

@@ -0,0 +1,81 @@
+---
+title: Structure of a Sprint
+summary: A guide to how a sprint should be structured
+author: Scott McCarthy
+date: 18/08/2022
+
+---
+
+The purpose of this document is to:
+
+- Organize content in the playbook for quick reference and discoverability
+- Provide content in a logical structure which reflects the engineering process
+- Extensible hierarchy to allow teams to share deep subject-matter expertise
+
+## The first week of a Project
+
+### Before starting the project
+
+- Discuss and start writing the [Team Agreements](../team-agreements.md). Update these documents with any process decisions made throughout the project
+    - [Working Agreement](../team-agreements/working-agreements.md)
+    - [Definition of Ready](../team-agreements/definition-of-ready.md)
+    - [Definition of Done](../team-agreements/definition-of-done.md)
+    - [Estimation](estimation.md)
+- XXX [Set up the repository/repositories](source-control/README.md#creating-a-new-repository)
+    - Decide on repository structure/s
+    - XXX Add the following files [README.md](resources/templates/README.md), [LICENSE.md](resources/templates/LICENSE), [CONTRIBUTING.md](resources/templates/CONTRIBUTING.md), .gitignore, etc
+- Build a [Product Backlog](../backlog-management.md)
+    - Set up a project in your chosen project management tool (ex. Azure DevOps or JIRA)
+    - [INVEST](<https://en.wikipedia.org/wiki/INVEST_(mnemonic)>) in good User Stories and Acceptance Criteria
+    -  XXX [Non-Functional Requirements Guidance](design/design-patterns/non-functional-requirements-capture-guide.md)
+
+### Day 1 Activities
+
+- [Plan the first sprint](../sprint-planning.md)
+    - Agree on a sprint goal, and how to measure the sprint progress
+    - Determine team capacity
+    - Assign user stories to the sprint and split user stories into tasks
+    - Set up Work in Progress (WIP) limits
+- XXX [Decide on test frameworks and discuss test strategies](automated-testing/README.md)
+    - Discuss the purpose and goals of tests and how to measure test coverage
+    - Agree on how to separate unit tests from integration, load and smoke tests
+    - Design the first test cases
+- XXX  [Decide on branch naming](source-control/naming-branches.md)
+- XXX  [Discuss security needs and verify that secrets are kept out of source control](continuous-delivery/secrets-management/recipes/azure-devops/secrets-per-branch.md)
+
+### Day 2 Activities
+
+- XXX  [Set up Source Control](source-control/README.md)
+    - XXX  Agree on [best practices for commits](source-control/README.md#commit-best-practices)
+- XXX [Set up basic Continuous Integration with linters and automated tests](continuous-integration/README.md)
+- Set up meetings for [Daily Stand-ups](../stand-ups.md) and decide on a Process Lead
+    - Discuss purpose, goals, participants and facilitation guidance
+    - Discuss timing, and how to run an efficient stand-up
+- If the project has sub-teams, set up a [Scrum of Scrums](../scrum-of-scrums.md)
+
+### Day 3
+
+- [ ] [Agree on code style](code-reviews/README.md) and on [how to assign Pull Requests](code-reviews/pull-requests.md)
+- [ ] [Set up Build Validation for Pull Requests (2 reviewers, linters, automated tests)](code-reviews/README.md) and agree on [Definition of Done](agile-development/team-agreements/definition-of-done.md)
+- [ ] [Agree on a Code Merging strategy](source-control/merge-strategies.md) and update the [CONTRIBUTING.md](resources/templates/CONTRIBUTING.md)
+- [ ] [Agree on logging and observability frameworks and strategies](observability/README.md)
+
+### Day 4
+
+- [ ] [Set up Continuous Deployment](continuous-delivery/README.md)
+  - Determine what environments are appropriate for this solution
+  - For each environment discuss purpose, when deployment should trigger, pre-deployment approvers, sing-off for promotion.
+- [ ] [Decide on a versioning strategy](source-control/component-versioning.md)
+- [ ] Agree on how to [Design a feature and conduct a Design Review](design/design-reviews/README.md)
+
+### Day 5
+
+- [ ] Conduct a Sprint Demo
+- [ ] [Conduct a Retrospective](agile-development/retrospectives.md)
+  - Determine required participants, how to capture input (tools) and outcome
+  - Set a timeline, and discuss facilitation, meeting structure etc.
+- [ ] [Refine the Backlog](agile-development/backlog-management/backlog-refinement.md)
+  - Determine required participants
+  - Update the [Definition of Ready](agile-development/team-agreements/definition-of-ready.md)
+  - Update estimates, and the [Estimation](agile-development/sprint-planning/estimation.md) document
+- [ ] [Submit Engineering Feedback for issues encountered](engineering-feedback/README.md)

docs/best-practices/continuous-planning/agile-development/sprint-planning/sprint-structure.md

@@ -7,7 +7,7 @@ The stand-up is a time-boxed ceremony that is held each day of the sprint. In th
 1. What did you work on yesterday that contributes to meet the sprint goal?
 2. What are you working on today that will contribute to meet the sprint goal?
 3. Do you have any impediments/blockers or need any help? (defer discussion / resolution to "the parking lot", described below)
-4. An [optional social question](/continuous-planning/agile-development/stand-ups/social-question.md), e.g. "would you rather see the past or the future?"
+4. An optional [social question](stand-ups/social-question.md), e.g. "would you rather see the past or the future?"
 
 During the stand-up, additional discussions may arise. Make sure that someone adds them to the parking lot for after meeting discussion.  
 
@@ -90,7 +90,7 @@ Ensure discussion leaders call out necessary parties for their discussion points
 
 ### Social question
 
-Teams are frequently geographically distributed and include members who have not worked on projects together previously. Social interactions facilitate the development of trust between team members and lower the barriers to collaboration. A social question-of-the-day that has a one-sentence answer contributes to trust development over the course of many stand-ups, with a minimal additional time commitment. The answer to the social question should be brief and follow the project questions answer. The facilitator may choose the social question or take a suggestion from the room. Description of what makes a good question, and a list of starter questions are available within the [social question](/continuous-planning/agile-development/stand-ups/social-question.md) page.
+Teams are frequently geographically distributed and include members who have not worked on projects together previously. Social interactions facilitate the development of trust between team members and lower the barriers to collaboration. A social question-of-the-day that has a one-sentence answer contributes to trust development over the course of many stand-ups, with a minimal additional time commitment. The answer to the social question should be brief and follow the project questions answer. The facilitator may choose the social question or take a suggestion from the room. Description of what makes a good question, and a list of starter questions are available within the [social question](stand-ups/social-question.md) page.
 
 ### Start On Time
 

docs/best-practices/continuous-planning/agile-development/stand-ups.md

@@ -1,4 +1,10 @@
-# Social Question of the Day
+---
+title: Social Question
+summary: Some optional questions that will help to build team trust.
+author: Scott McCarthy
+date: 18/08/2022
+
+---
 
 The social question of the day is an optional short question to follow the [three project questions](README.md) in the daily stand-up. It develops team cohesion and interpersonal trust over the course of an engagement by facilitating the sharing of personal preferences, lifestyle, or other context.
 

…development/stand-ups/Social-Question.md …development/stand-ups/social-question.mddocs/best-practices/continuous-planning/agile-development/stand-ups/Social-Question.md renamed to docs/best-practices/continuous-planning/agile-development/stand-ups/social-question.md docs/best-practices/continuous-planning/agile-development/stand-ups/Social-Question.md renamed to docs/best-practices/continuous-planning/agile-development/stand-ups/social-question.md

@@ -1,4 +1,9 @@
-# Definition of Ready
+---
+title: Definition of Ready
+summary: a definition of what Ready means in agile
+author: Scott McCarthy
+
+---
 
 When the development team picks a user story from the top of the backlog, the user story needs to have enough detail to estimate the work needed to complete the story within the sprint. If it has enough detail to estimate, it is Ready to be developed.
 
@@ -37,6 +42,6 @@ The ready checklist should contain items that apply broadly. Don't include items
 
 In the case that the highest priority work is not yet ready, it still may be possible to make forward progress. Here are some strategies that may help:
 
-* [Backlog Refinement](../backlog-management/backlog-refinement.md) sessions are a good time to validate that high priority user stories are verified to have a clear description, acceptance criteria and demonstrable business value. It is also a good time to breakdown large stories will likely not be completable in a single sprint.
+* [Backlog Refinement](../backlog-refinement.md) sessions are a good time to validate that high priority user stories are verified to have a clear description, acceptance criteria and demonstrable business value. It is also a good time to breakdown large stories will likely not be completable in a single sprint.
 * Prioritization sessions are a good time to prioritize user stories that unblock other blocked high priority work.
 * Blocked user stories can often be broken down in a way that unblocks a portion of the original stories scope. This is a good way to make forward progress even when some work is blocked.