Jeff Sutherland om Scrum og lean...
Her er en yderst interessant artikel, som ridser det historiske perspektiv for både Scrum og lean op:
http://jeffsutherland.com/scrum/2007/11/is-it-scrum-or-lean.html
Spændende pointer og uddrag til dem som ikke har lyst til at læse hele artiklen:
Fastest path to appearance of the next feature:
"The reason the first Scrum team called Sprint Backlog items SyncSteps was that developers executed the Sprint Backlog in a carefully chosen order - that order which produced the fastest path to appearance of the next feature from the users point of view. Just as proper ordering of the Product Backlog optimizes revenue, proper ordering of the Sprint Backlog optimizes production of value. It accelerates software evolution and can produce effects seen in biological systems."
Hele tanken om, at arbejde med sprint backloggen på den måde er super interessant. Gad godt høre om nogle af jer har specifikke erfaringer med dette?
Punctuated equilibrium:
"The "punctuated equilibrium" effect is achieved at Toyota using set-based concurrent engineering. As an example, Toyota does not build one radiator for a new car. They build six, and wait to the last possible moment to choose the best radiator to deploy in production. This is similar to competition between biological species in an ecosystem and the species that adapts best to the environment wins. The Scrumcommunity has yet to implement set based concurrent engineering strategies"
Kunne man gøre brug af denne tankegang i software-udvikling? Det er en naturlig konkurrence situation, som jeg i hvert fald føler vi ofte mangler på vores software-projekter.
Scrum failure:
"Less than 10% of the Scrum teams worldwide can pass the Nokia test, primarily because they cannot deliver potentially shippable (fully tested) software at the end of a Sprint."
Skræmmende! Ifølge ovenstående er vi i øjeblikket også temmelig langt fra at have implementeret korrekt Scrum. Vi øver os, men det som oftest viser at spænde ben, er opstarten af projekter, hvor der bruges alt for lang tid på arkitektur upfront.
On teams:
"A project team is typically 3 developers, 3 QA people, 3 doc people, and one or two users. They meet daily and all agree on steps completed and next steps. For large projects, small teams of this size build components and a SCRUM of SCRUMs meets less frequently to work out interfaces between components. Developers must be outnumbered on the team by QA and documentation people or they generate too much code too fast (malignant functionality)."
Jeg har i lang tid syslet med, at der ikke måtte være flere end 4 udviklere på et team. Ovenstående går meget godt i spænd med den tankegang. Men uha. Vi har ikke en eneste QA person tilknyttet teamet fast. Tesen om, at udviklere skal være i mindretal i forhold til testere, fortæller mig et og andet, om at vi også har en del arbejde på den front, der skal gøres før vi er i mål. Hvordan ser jeres teams ud?
http://jeffsutherland.com/scrum/2007/11/is-it-scrum-or-lean.html
Spændende pointer og uddrag til dem som ikke har lyst til at læse hele artiklen:
Fastest path to appearance of the next feature:
"The reason the first Scrum team called Sprint Backlog items SyncSteps was that developers executed the Sprint Backlog in a carefully chosen order - that order which produced the fastest path to appearance of the next feature from the users point of view. Just as proper ordering of the Product Backlog optimizes revenue, proper ordering of the Sprint Backlog optimizes production of value. It accelerates software evolution and can produce effects seen in biological systems."
Hele tanken om, at arbejde med sprint backloggen på den måde er super interessant. Gad godt høre om nogle af jer har specifikke erfaringer med dette?
Punctuated equilibrium:
"The "punctuated equilibrium" effect is achieved at Toyota using set-based concurrent engineering. As an example, Toyota does not build one radiator for a new car. They build six, and wait to the last possible moment to choose the best radiator to deploy in production. This is similar to competition between biological species in an ecosystem and the species that adapts best to the environment wins. The Scrumcommunity has yet to implement set based concurrent engineering strategies"
Kunne man gøre brug af denne tankegang i software-udvikling? Det er en naturlig konkurrence situation, som jeg i hvert fald føler vi ofte mangler på vores software-projekter.
Scrum failure:
"Less than 10% of the Scrum teams worldwide can pass the Nokia test, primarily because they cannot deliver potentially shippable (fully tested) software at the end of a Sprint."
Skræmmende! Ifølge ovenstående er vi i øjeblikket også temmelig langt fra at have implementeret korrekt Scrum. Vi øver os, men det som oftest viser at spænde ben, er opstarten af projekter, hvor der bruges alt for lang tid på arkitektur upfront.
On teams:
"A project team is typically 3 developers, 3 QA people, 3 doc people, and one or two users. They meet daily and all agree on steps completed and next steps. For large projects, small teams of this size build components and a SCRUM of SCRUMs meets less frequently to work out interfaces between components. Developers must be outnumbered on the team by QA and documentation people or they generate too much code too fast (malignant functionality)."
Jeg har i lang tid syslet med, at der ikke måtte være flere end 4 udviklere på et team. Ovenstående går meget godt i spænd med den tankegang. Men uha. Vi har ikke en eneste QA person tilknyttet teamet fast. Tesen om, at udviklere skal være i mindretal i forhold til testere, fortæller mig et og andet, om at vi også har en del arbejde på den front, der skal gøres før vi er i mål. Hvordan ser jeres teams ud?
indsendt af Rune Mai kl.
13:20
0 kommentarer:
Send en kommentar
<< Startside