EBM & Documentation Notes

Career/evidence-based-management.md

@@ -108,3 +108,64 @@ What should be measured? "It depends."
 3. KVMs (Key Value Measures)
 
 Frequency: Sprint-based, every two weeks.
+
+### Experimentation
+
+The sprint goal is the Immediate Tactical Goal.
+
+The sprint goal/backlog is hypthesis (the cards on the scrum board). The sprint itself is the experiment to prove the hypothesis (what we thing we can accomplish) right or wrong.
+
+### Goals
+
+### Setting Goals
+
+A good, well developed goal is:
+
+* Outcome focused
+* Specific
+* Success is clearly defined (measurable)
+* Focused on delivering value to the customer
+
+Implement Strategic, Intermediate (product), and Immediate Tactical (sprint) Goals against the needs of the client.
+
+Add this information to the Dashboard.
+
+### Key Value Areas
+
+![KVAs: Unrealized Value, Current Value, Ability to Innovate, and Time to Market](./images/kva-sprint.png)
+
+KVAs: Current Value, Unrealized Value, Ability to Innovate, and Time to Market
+
+### Key Value Measures
+
+Ask these questions:
+
+* What is hindering the team from doing great work?
+* How do we know our customers like and want what we are delivering?
+
+### Interpreting a Dashboard
+
+1. Review Key Value Areas (KVAs) and Key Value Measures (KVMs)
+
+    * KVMs are the data points to measure and track.
+    * There are 4 KVAs that act as groups to categorize KVMs.
+    * What story are the metrics telling?
+
+2. Review Goals
+
+    * How do the KVAs/KVMs support the goals?
+    * Are there any behaviors that need to be changed or metrics that need to be adjusted when looking at the complete picture?
+
+### Without a Dashboard
+
+Start asking questions about the goals, direction, and value of the project.
+
+* Figure out what the goals are and document them.
+* Ask the Scrum Master, Product Owner, and stakeholders to help the team determine and document the goals.
+* Are the goals outcome focused?
+* Ask "why?" - and keep asking until you get to the root of what you are trying to accomplish.
+
+Measure things independently.
+
+* Use that data to provide and explanation for things (not an excuse).
+* Measure time spent in meetings, context switching, requirements approval, etc.

Documentation/README.md

@@ -2,54 +2,6 @@
 
 > Documentation of knowledge.
 
-## Architectual Decision Record
-
-An **Architectural Decision (AD)** is a justified technical choice that addresses a functional or non-functional requirement that is architecturally significant. An Architecturally Significant Requirement (**ASR**) is a requirement that has a measurable effect on the architecture and quality of a software and/or hardware system. An Architectural Decision Record (ADR) captures a single AD and its rationale; the collection of ADRs created and maintained in a project constitute its decision log. All these are within the topic of Architectural Knowledge Management (AKM), but ADR usage can be extended to design and other decisions (“any decision record”).
-
-A “lightweight” ADR consists of title, status, context, decision, and consequences.
-
-### Template
-
-#### [asr-####] Title
-
-##### Status
-
-What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.?
-
-##### Context
-
-What is the issue that we're seeing that is motivating this decision or change?
-
-##### Decision
-
-What is the change that we're proposing and/or doing?
-
-##### Consequences
-
-What becomes easier or more difficult to do because of this change?
-
-## Best Practices
-
-The purpose of a style guide is to provide guidance on building an applications by showing the conventions used and, more importantly, why they were chosen.
-
-### Template
-
-Group these together into **topics**.
-
-#### [style-####] Title
-
-* Bulleted list of what the style or pattern is.
-
-***Why?***: Reasons why we are using this style/pattern
-
-**Example**
-
-```javascript
-/* avoid */
-...
-
-/* recommended */
-...
-```
-
-* **Note**: Additional notes here.
+* [Application Structure](./application-structure.md)
+* [Architectual Decision Record](./architectual-decision-record.md)
+* [Best Practices](./best-practices.md)

Documentation/application-structure.md

@@ -0,0 +1,53 @@
+# Application Structure
+
+This guide is a focused on having an idea of what is important in structuring my application instead of focusing on the actual structure.
+
+Instead of just picking a structure, it's helpful to think about the "why", 
+
+> There are many **right ways** of doing this, and consistency in your project is key.
+
+## Structure
+
+- Core
+    - Constants
+    - Enums
+    - Interfaces
+    - Services
+        - (api-service abstraction)
+- Features
+- Pages
+    - (generally, component and api-service)
+- Shared
+    - (folder for _spec-files)
+    - (page abstractions)
+
+## LIFT Guidelines
+
+The structure should follow these 4 basic guidelines. When the structure is not feeling comfortable, go back and revisit these LIFT guidelines
+
+* **L**ocating code is easy
+* **I**dentify code at a glance
+* **F**lat structure as long as possible
+* **T**ry to stay DRY (Don't Repeat Yourself)
+
+Another way to check your app structure is to ask yourself ...
+
+> How quickly can you open and work in all of the related files for a feature?
+
+### Locating
+
+If the team cannot find the files they need to work on quickly, that needs to change.
+
+Locating code needs to be untuitive, simple and fast. You may not know the file name or where its related files are, so putting them in the most intuitive locations and near each other saves a ton of time.
+
+### Identify
+
+Looking at a file we expect to know what it contains and represents. If this means longer file names, then so be it. It's more about being descriptive with file names and keeping that contents of the file to exactly one thing. No files with multiple controllers, multiple services, or a mixture.
+
+There are deviations of the 1-per-file rule when there are small sets of things that are all related to each other, they are still easily idnetifiable. If not, 1-per-file.
+
+### Flat
+
+Nobody wants to search 7 levels of folders to find a file. In a folder structure there is no hard and fast number rule, but when a folder has 10 files, that may be time to create subfolders.
+
+The general guidelines here is comfort level. 

Documentation/architectual-decision-record.md

@@ -0,0 +1,25 @@
+# Architectual Decision Record
+
+An **Architectural Decision (AD)** is a justified technical choice that addresses a functional or non-functional requirement that is architecturally significant. An Architecturally Significant Requirement (**ASR**) is a requirement that has a measurable effect on the architecture and quality of a software and/or hardware system. An Architectural Decision Record (ADR) captures a single AD and its rationale; the collection of ADRs created and maintained in a project constitute its decision log. All these are within the topic of Architectural Knowledge Management (AKM), but ADR usage can be extended to design and other decisions (“any decision record”).
+
+A “lightweight” ADR consists of title, status, context, decision, and consequences.
+
+## Template
+
+### [asr-####] Title
+
+#### Status
+
+What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.?
+
+#### Context
+
+What is the issue that we're seeing that is motivating this decision or change?
+
+#### Decision
+
+What is the change that we're proposing and/or doing?
+
+#### Consequences
+
+What becomes easier or more difficult to do because of this change?

Documentation/best-practices.md

@@ -0,0 +1,33 @@
+# Best Practices
+
+This pattern is borrowed from [John Papa's Angular 1 Documentation](https://github.com/johnpapa/angular-styleguide/blob/master/a1/README.md).
+
+## Use and Purpose
+
+The purpose of a style guide is to provide guidance on building applications by showing the conventions used and, more importantly, why they were chosen.
+
+That last part is important: it is not important to follow a guideline as much as it is to understand why people choose what they do; to shed some light on the challenges and solutions.
+
+## What this Guide is Not
+
+The style guide is not intended to serve as a demo of reusable code, code snippets, or advanced solutions though it may drop a few here or there. Rather it is intended to be a starting point for a team looking for consistency.
+
+## Template
+
+### [style-####] Title
+
+* Bulleted list of what the style or pattern is.
+
+***Why?***: Reasons why we are using this style/pattern.
+
+**Example**
+
+```javascript
+/* avoid */
+...
+
+/* recommended */
+...
+```
+
+* **Note**: Additional notes here.