Skip to content

Commit f08a244

Browse files
committed
project template
1 parent 2921cac commit f08a244

File tree

3 files changed

+62
-82
lines changed

3 files changed

+62
-82
lines changed

0racexp.md

+48-15
Original file line numberDiff line numberDiff line change
@@ -12,23 +12,31 @@
1212
- [Concepts](https://en.wikipedia.org/wiki/Extreme_programming#Concept): overarching thereotical practices
1313
- [Extreme Programming](https://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658)
1414

15-
## [THE FIELD](https://en.wikipedia.org/wiki/Glossary_of_motorsport_terms)
15+
## RACE circuits
16+
17+
- aka sprints, 24 day iterations, 15 circuits a year
18+
19+
## RACE track
20+
21+
### [THE FIELD](https://en.wikipedia.org/wiki/Glossary_of_motorsport_terms)
1622

1723
- The competing races on a track.
1824
- `the pits` + `the grid`
1925
- all the tickets that could potentially be worked on
2026

21-
## [THE PITS](https://en.wikipedia.org/wiki/Pit_stop)
27+
#### [THE PITS](https://en.wikipedia.org/wiki/Pit_stop)
2228

2329
- In motorsports, a pit stop is a pause for refueling, new tires, repairs, mechanical adjustments, a driver change, as a penalty, or any combination of the above. These stops occur in an area called the pits, most commonly accessed via a pit lane which runs parallel to the start/finish straightaway of the track
2430
- tickets that require business + engineering attention
2531

26-
## [THE GRID](https://en.wikipedia.org/wiki/Glossary_of_motorsport_terms)
32+
#### [THE GRID](https://en.wikipedia.org/wiki/Glossary_of_motorsport_terms)
2733

2834
- The starting formation of a race, generally in rows of two for cars and three or four for bikes. The Indianapolis 500 traditionally has a unique grid of three cars per row.
2935
- tickets ready to be developed
3036

31-
## THE RACE
37+
### COMPETITION
38+
39+
> tracks _complexity of implementation_
3240
3341
- I like to use 4 in progress tracks (see `THE GROOVE` below)
3442
- depending on the drivers part of your team, and each developers capabilities, will determine the set of in progress tickets and how they are categorized in the 4 in progress tracks
@@ -42,20 +50,45 @@
4250
- there are a lot of stats and insights to glean from plotting tickets on these 4 dimensions over time...
4351
- `DEPLOYED`: refrain from the use of `DONE` status, DONE doesnt exist in the real world; this also supports the adoption of `refactoring as a lifestyle`
4452

45-
## [ADR-TYPES](https://adr.github.io/)
53+
#### ETD
54+
55+
> tracks estimated time to ~complete~ deploy
56+
57+
- tracked as total days till deployed in 2 day increments
58+
- max allowed time should equal circuit length (24 days)
59+
60+
#### RACE Flags
61+
62+
- [RACING FLAGS](https://en.wikipedia.org/wiki/Racing_flags)
63+
- the dimensions on which a ticket is evaluated to ascertain quality:
64+
- basically anything you want, but all should be:
65+
- technical principals/best practices, e.g. DRY, SOLID, KISS, efficiency, effectiveness, etc.
66+
- not solvable by automation: keep your biases/opinions to a minimum and the team focused on finishing the race successfully, not perfectly
67+
- [MEATBALL](https://en.wikipedia.org/wiki/Racing_flags#Black_flag)
68+
> only `meatballs` are rejected/reworked, everything else is pushed through
69+
- A mechanical black flag is a black flag with an orange disc in its center which indicates that a vehicle is being summoned to the pits due to serious mechanical problems or loose bodywork that presents a risk to other competitors. At some road racing events, it is used to summon the vehicle to the pits to inform the driver of violation "maximum sound levels.” Also known as the 'Meatball' flag.
70+
- [YELLOW FLAG](https://en.wikipedia.org/wiki/Racing_flags#Yellow_flag)
71+
> _too many_ yellow flags and a ticket could be labeled a meatball<br/>_too few_ yellow flags is indicative of over optimizing/no critical feedback
72+
- dont over optimize, be overly optimistic
73+
- dont push things through without identifying future rework
74+
- the idea being all tech is techdebt eventually, there is no perfectly groomed/scoped ticket. eventually all work will be reworked
75+
- this idea should be built into your strategic planning and accepted as a first principle
76+
- The solid yellow flag, or caution flag, universally requires drivers to slow down due to a hazard on the track, typically an accident, a stopped car, debris or light rain. However, the **procedures for displaying the yellow flag vary for different racing styles and sanctioning bodies**.
77+
- [CHEQUERED FLAG](https://en.wikipedia.org/wiki/Racing_flags#The_chequered_flag)
78+
> keep track of the tickets that represent the flawless fatality and apply the chequered flag
79+
- Useful for keeping track of [all the factors](https://www.nature.com/articles/s41467-021-25477-8) that were in alignment for a particular ticket, developer, PM, etc that joined together and executed fkn flawlessly.
80+
- you should ask yourself right now: Do you know the specific levers to pull in order to push your team across the finish line... and if you have the data to back that shit up
81+
- The chequered flag (or checkered flag) is displayed at the start/finish line to indicate that the race is officially finished. At some circuits, the first flag point will display a repeat chequered flag (usually on the opposite side of the circuit). The flag is commonly associated with the winner of a race, as they are the first driver to "take" (in other words, drive past) the chequered flag.
82+
83+
#### [ADR-TYPES](https://adr.github.io/)
4684

4785
- for tracking architectural decision records of a particular type
4886
- architecture is key to turning tech-debt into tech-features
49-
- TODO
50-
- complexity of [scale and scope](https://econproph.com/2019/05/20/scale-and-scope/)
51-
- complexity of implementation (i.e. normal story points)
52-
- just because a ticket has a high story point, doesnt mean it takes a long time to complete
53-
- complexiity of completion (a time dimension)
54-
- just because a ticket takes a long time to complete, doesnt mean its developmentally complex
55-
- complex solutions dont always require complex deployments, and straight forward requirements can be a pain in the ass
56-
- understanding the scale and scope of product reqiurements, and the scale and scope to which a developed product satisfies a customers needs, provides the two unanswerable questions in development: how difficult is this to build, and how long will it take to build it
57-
- the RACE
58-
- each lane (slow, groove, fast, last lap) is the sum of implementation & completion complexity based on an individual/teams capabilities
87+
- these labels are applied to races in competition that signficantly impact future work
88+
- biz
89+
- dev
90+
- ops
91+
- sec
5992

6093
## RACE Teams
6194

README.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,11 @@
11
# BizDevOps+Sec @ NIRV
22

3+
- [use the project template](https://github.com/orgs/nirv-ai/projects/8/views/2)
4+
35
> understanding all of our planning... triangulate the ideal path towards a future state of being. @NIRV
46
57
> ![RACExp](./images/racexp-racexp.png)
68
7-
- [use the project template](https://github.com/orgs/nirv-ai/projects/8/views/2)
8-
99
## RACExp
1010

1111
- Holistic high performance bizdevops teams

meatballs/scratch.md

+12-65
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,5 @@
1+
- TODOs
2+
- we need to to find time to finish copying stuff on paper into this readme
13
- racexp: three pillars of racexp
24
- organizational structure: as defined by investopedia
35
- system that outlines how certain activities are directed in order to achieve the goals of an organization
@@ -44,26 +46,6 @@
4446
- embrace the complexity, risk and potential for failure.
4547
- Focus on change-management and short-feedback loops with immediate corrective actions
4648
- trend analysis: ...TODO review trading strategies and apply to racexp
47-
- [RACING FLAGS](https://en.wikipedia.org/wiki/Racing_flags)
48-
- the dimensions on which a ticket is evaluated to ascertain quality:
49-
- basically anything you want, but all should be:
50-
- technical principals/best practices, e.g. DRY, SOLID, KISS, efficiency, effectiveness, etc.
51-
- not solvable by automation: keep your biases/opinions to a minimum and the team focused on finishing the race successfully, not perfectly
52-
- [MEATBALL](https://en.wikipedia.org/wiki/Racing_flags#Black_flag)
53-
- A mechanical black flag is a black flag with an orange disc in its center which indicates that a vehicle is being summoned to the pits due to serious mechanical problems or loose bodywork that presents a risk to other competitors. At some road racing events, it is used to summon the vehicle to the pits to inform the driver of violation "maximum sound levels.” Also known as the 'Meatball' flag.
54-
- only `meatballs` are rejected/reworked, everything else is pushed through
55-
- [YELLOW FLAG](https://en.wikipedia.org/wiki/Racing_flags#Yellow_flag)
56-
- The solid yellow flag, or caution flag, universally requires drivers to slow down due to a hazard on the track, typically an accident, a stopped car, debris or light rain. However, the **procedures for displaying the yellow flag vary for different racing styles and sanctioning bodies**.
57-
- _too many_ yellow flags and a ticket could be labeled a meatball
58-
- _too few_ yellow flags is indicative of over optimizing (dont over optimize, be overly optimistic)
59-
- the idea being all tech is techdebt eventually, there is no perfectly groomed/scoped ticket. eventually all work will be redone
60-
- this idea should be built into your strategic planning and accepted as a first principle
61-
- [CHEQUERED FLAG](https://en.wikipedia.org/wiki/Racing_flags#The_chequered_flag)
62-
- The chequered flag (or checkered flag) is displayed at the start/finish line to indicate that the race is officially finished. At some circuits, the first flag point will display a repeat chequered flag (usually on the opposite side of the circuit). The flag is commonly associated with the winner of a race, as they are the first driver to "take" (in other words, drive past) the chequered flag.
63-
- Upon seeing the chequered flag and crossing the finish line, drivers are required to slow to a safe speed, and return to their garage, parc fermé, or paddock, depending on the applicable regulations of the series.
64-
- Useful for keeping track of [all the factors](https://www.nature.com/articles/s41467-021-25477-8) that were in alignment for a particular ticket, developer, PM, etc that joined together and executed fkn flawlessly.
65-
- you should ask yourself right now: Do you know the specific levers to pull in order to push your team across the finish line... and if you have the data to back that shit up
66-
- and if not, you should atleast be keeping track of the tickets that represent the flawless fatality: apply the chequered flag
6749

6850
# blah
6951

@@ -77,48 +59,13 @@ uses the `race [car|team] metaphor` as the ontology of rapid prototyping/product
7759
- ~one day I'll publish this~
7860
- for now: the below should suffice
7961

80-
[THE FIELD](https://en.wikipedia.org/wiki/Glossary_of_motorsport_terms)
81-
82-
- The competing cars in an event.
83-
- `the pits` + `the grid`
84-
85-
[THE PITS](https://en.wikipedia.org/wiki/Pit_stop)
86-
87-
- In motorsports, a pit stop is a pause for refueling, new tires, repairs, mechanical adjustments, a driver change, as a penalty, or any combination of the above. These stops occur in an area called the pits, most commonly accessed via a pit lane which runs parallel to the start/finish straightaway of the track
88-
- tickets not ready for the race
89-
90-
[THE GRID](https://en.wikipedia.org/wiki/Glossary_of_motorsport_terms)
91-
92-
- The starting formation of a race, generally in rows of two for cars and three or four for bikes. The Indianapolis 500 traditionally has a unique grid of three cars per row.
93-
- tickets in the race
94-
- I like to use 4 in progress tracks (see `THE GROOVE` below)
95-
96-
[THE GROOVE](https://en.wikipedia.org/wiki/Glossary_of_motorsport_terms)
97-
98-
- The optimal path around the track for the lowest lap time. In drag racing it is about the center portion of the lane, where the cars can gain traction quicker.
99-
- `SLOW lane` too many of these and your drivers wont be happy, forecasts wont be accurate, and the _fast_ lane will be over utilized to compensate for poor finishes
100-
- `THE GROOVE` the optimal ticket: your team is successful, drivers are winners, races are predictable
101-
- `FAST lane` too many of these means all your trophies are gold plated, but hey - you can fill your team with cheap engineers and junior devs
102-
- `THE LAST LAP` if our users arent using it then its not providing utility, and usually not useful to consider the ticket done, so use the the last lap for this usecase
103-
- there are a lot of stats and insights to glean from plotting tickets on these 4 dimensions over time...
104-
105-
[RACING FLAGS](https://en.wikipedia.org/wiki/Racing_flags)
106-
107-
- the dimensions on which a ticket is evaluated to ascertain quality:
108-
- basically anything you want, but all should be:
109-
- technical principals/best practices, e.g. DRY, SOLID, KISS, efficiency, effectiveness, etc.
110-
- not solvable by automation: keep your engineers biases to a minimum and the team focused on finishing the race successfully, not perfectly
111-
- [MEATBALL](https://en.wikipedia.org/wiki/Racing_flags#Black_flag)
112-
- A mechanical black flag is a black flag with an orange disc in its center which indicates that a vehicle is being summoned to the pits due to serious mechanical problems or loose bodywork that presents a risk to other competitors. At some road racing events, it is used to summon the vehicle to the pits to inform the driver of violation "maximum sound levels.” Also known as the 'Meatball' flag.
113-
- only `meatballs` are rejected/reworked, everything else is pushed through (fk your opinions: the team has a race to win; if its not a _meatball_, it must be **steak**)
114-
- [YELLOW FLAG](https://en.wikipedia.org/wiki/Racing_flags#Yellow_flag)
115-
- The solid yellow flag, or caution flag, universally requires drivers to slow down due to a hazard on the track, typically an accident, a stopped car, debris or light rain. However, the **procedures for displaying the yellow flag vary for different racing styles and sanctioning bodies**.
116-
- _too many_ yellow flags and a ticket could be labeled a meatball
117-
- _too few_ yellow flags is indicative of over optimizing (dont over optimize, be overly optimistic)
118-
- [CHEQUERED FLAG](https://en.wikipedia.org/wiki/Racing_flags#The_chequered_flag)
119-
- The chequered flag (or checkered flag) is displayed at the start/finish line to indicate that the race is officially finished. At some circuits, the first flag point will display a repeat chequered flag (usually on the opposite side of the circuit). The flag is commonly associated with the winner of a race, as they are the first driver to "take" (in other words, drive past) the chequered flag.
120-
- Upon seeing the chequered flag and crossing the finish line, drivers are required to slow to a safe speed, and return to their garage, parc fermé, or paddock, depending on the applicable regulations of the series.
121-
- [ADR-TYPE](https://adr.github.io/)
122-
- for tracking architectural decision records of a particular type
123-
- types could be testing, ci, cd, recommended jamaican rums, etc
124-
- anything with an ADR tag should also have a `good first issue` as github automation surfaces `good first issue` to newcomers
62+
- TODO
63+
- complexity of [scale and scope](https://econproph.com/2019/05/20/scale-and-scope/)
64+
- complexity of implementation (i.e. normal story points)
65+
- just because a ticket has a high story point, doesnt mean it takes a long time to complete
66+
- complexiity of completion (a time dimension)
67+
- just because a ticket takes a long time to complete, doesnt mean its developmentally complex
68+
- complex solutions dont always require complex deployments, and straight forward requirements can be a pain in the ass
69+
- understanding the scale and scope of product reqiurements, and the scale and scope to which a developed product satisfies a customers needs, provides the two unanswerable questions in development: how difficult is this to build, and how long will it take to build it
70+
- the RACE
71+
- each lane (slow, groove, fast, last lap) is the sum of implementation & completion complexity based on an individual/teams capabilities

0 commit comments

Comments
 (0)