Create Definition of Ready en Definition of Done #5
Conversation
RikHooft007
changed the title
berrydenhartog
force-pushed
the
Definition-of-Ready-branch
branch
from
37725e7 to
ce801e5
Compare
RikHooft007
force-pushed
the
Definition-of-Ready-branch
branch
from
ce801e5 to
53f99c0
Compare
There was a problem hiding this comment.
Tof Rik,
Hier onder wat opmerkingen. Ook is het denk ik goed om de bestanden in de openbsw map te zetten en om de bestandsnamen daar op aan te passen. Ik stel voor openbsw/definition-of-ready.md en openbsw/definition-of-done.md.
@berrydenhartog, heb jij nog wat in de pap te brokkelen?
Way of Working/Definition of Done.md
Outdated
| 1. Issue is getest en werkt | ||
|
|
||
| 2. Issue is zo gedocumenteerd of gecodeerd zodat deze reproduceerbaar is als we naar een andere omgeving gaan dan Digilab | ||
|
|
||
| 3. Architectuur is bijgewerkt | ||
|
|
||
| 3. Issue is gedocumenteerd in relatie tot BSW en aanbevelingen en selectie projecten | ||
|
|
||
| 4. Issue is gedemonstreerd aan het team en/of belanghebbende |
There was a problem hiding this comment.
Lijstjes in Markdown behoeven geen witregel tussen de punten. Er staan ook 2 3. in dit lijstje. Als je in Markdown alles een 1. geeft dan word de lijst automatisch geordend. Ik zie hier echter geen noodzaak voor een volgoorde, dus een ongeordende lijst is beter denk ik.
| 1. Issue is getest en werkt | |
| 2. Issue is zo gedocumenteerd of gecodeerd zodat deze reproduceerbaar is als we naar een andere omgeving gaan dan Digilab | |
| 3. Architectuur is bijgewerkt | |
| 3. Issue is gedocumenteerd in relatie tot BSW en aanbevelingen en selectie projecten | |
| 4. Issue is gedemonstreerd aan het team en/of belanghebbende | |
| * Issue is getest en werkt | |
| * Issue is zo gedocumenteerd of gecodeerd zodat deze reproduceerbaar is als we naar een andere omgeving gaan dan Digilab | |
| * Architectuur is bijgewerkt | |
| * Issue is gedocumenteerd in relatie tot BSW en aanbevelingen en selectie projecten | |
| * Issue is gedemonstreerd aan het team en/of belanghebbende |
Een andere suggestie is hier niet issue maar bijvoorbeeld oplossing te gebruiken om het generieker en duidelijker te maken. En ik zou de als we naar een andere omgeving gaan dan digilab vervangen met bijvoorbeeld zodat het herbruikbaar is, inspiratie: https://codefor.nl/community-translations-standard/nl/criteria/make-the-codebase-reusable-and-portable.html
Co-authored-by: Boris van Hoytema <Boris.Hoytema@minbzk.nl>
Nu nog verplaatsen
no nog verplaatsen
|
Hi Boris, ik heb Berry gesproken en zijn feedback (grotendeels 😀) verwerkt. Dat verplaatsen naar openbsw lijkt op een delete + upload, klopt dat? |
Way of Working/Definition of Done.md
Outdated
| @@ -0,0 +1,11 @@ | |||
| **Definition of Done:** | |||
| # Definition of Ready: | ||
|
|
||
| - Oplossing is besproken binnen het team | ||
| - Omvang en duur van de oplossing kunnen worden geschat |
There was a problem hiding this comment.
Omdat we kanban doen en dingen voor het eerst hoeft voor mij de oplossing niet altijd geschat te worden.
| @@ -0,0 +1,9 @@ | |||
| # Definition of Ready: | |||
|
|
|||
| - Oplossing is besproken binnen het team | |||
There was a problem hiding this comment.
Het hoeft voor mij niet met het team besproken te zijn, als het maar goed gedocumenteerd is.
Way of Working/Definition of Done.md
Outdated
| @@ -0,0 +1,5 @@ | |||
| # Definition of Done: | |||
|
|
|||
| - Oplossing is getest en werkt | |||
There was a problem hiding this comment.
Ik zou dit veranderen in dat alle technische testen succesvol gedraaid zijn. (dat betekend natuurlijk niet dat het werkt, dat kan je nooit 100% garanderen)
|
|
||
| - Oplossing is getest en werkt | ||
| - Oplossing is zo gedocumenteerd of gecodeerd zodat deze reproduceerbaar/herbruikbaar is voor andere omgevingen | ||
| - Oplossing (ervaring) is gedocumenteerd in relatie tot BSW en aanbevelingen en selectie projecten |
There was a problem hiding this comment.
Een aantal punten die ik zou willen aandragen:
- Willen we ook dat alles peer reviewed is?
- Willen we dat er Security en Quality tools gedraaid worden op onze oplossingen voordat ze door mogen?
- Willen we dat style guides gehandhaaft worden. Zodat het goed leesbaar blijft en iedereen dezelfde style gebruikt? deze styleguides kunnen we per project vast stellen.
There was a problem hiding this comment.
Ik denk ook hier dat de teamafspraken meer helder moeten maken hoe we testen en controleren of het werkt, verder:
- Geen verkeerd idee, maar doen we dat voor elke oplossing?
- Als die er voor alle initiatieven zijn en werken zou ik zeggen: ja.
- Idem.
There was a problem hiding this comment.
- ik zou het doen waar logisch is. Maar bij zoveel mogelijk opleverbare Oplossingen
- 👍
- 👍
|
|
||
| - Oplossing is besproken binnen het team | ||
| - Omvang en duur van de oplossing kunnen worden geschat | ||
| - Een oplossing is op de juiste manier geadministreerd in GitHub |
There was a problem hiding this comment.
Wat betekend op de juiste manier geadministreerd? kan je dit verder toelichten
There was a problem hiding this comment.
Die vraag is geen verrassing 😄 . Ik stel voor dat we dat apart vastleggen. Zo willen we dat de rapportage onderweg worden opgebouwd zodat we de afgesproken rapporten handig kunnen vullen. Dat vormen onderdeel van de teamafspraken en die duidelijk, vindbaar en begrepen zijn.
|
As we couldnot remove a commit I close this PR and start a new one on the same subjects |
Zoals besproken.