Pikkukuvaa napsauttamalla pääset Google Booksiin.
Ladataan... Scrum and XP from the Trenches (Enterprise Software Development)Tekijä: Henrik Kniberg
- Ladataan...
Kirjaudu LibraryThingiin nähdäksesi, pidätkö tästä kirjasta vai et. Ei tämänhetkisiä Keskustelu-viestiketjuja tästä kirjasta. ei arvosteluja | lisää arvostelu
This book aims to give you a head start by providing a detailed down-to-earth account of how one Swedish company implemented Scrum and XP with a team of approximately 40 people and how they continuously improved their process over a year's time.Under the leadership of Henrik Kniberg they experimented with different team sizes, different sprint lengths, different ways of defining "done", different formats for product backlogs and sprint backlogs, different testing strategies, different ways of doing demos, different ways of synchronizing multiple Scrum teams, etc. They also experimented with XP practices - different ways of doing continuous build, pair programming, test driven development, etc, and how to combine this with Scrum.This second edition is an annotated version, a "director's cut" where Henrik reflects upon the content and shares new insights gained since the first version of the book. Kirjastojen kuvailuja ei löytynyt. |
Current Discussions-Suosituimmat kansikuvat
Google Books — Ladataan... LajityypitMelvil Decimal System (DDC)004Information Computing and Information Computer scienceKongressin kirjaston luokitusArvio (tähdet)Keskiarvo:
Oletko sinä tämä henkilö? |
I read Henrik Kniberg's book, Scrum and XP (Extreme Programming) from the Trenches, on his suggestion and, well, he's right!
Kniberg's book is a concise "how to" on how his company implements Agile in their software development business. It's chock full of great ideas and details that come only from those that have actually practiced something. As such, I gained a good insight into how Agile and Scrum work, and you will too.
What I want to explore more, however, is the idea that Agile can be applied as a model for leadership, or, more precisely, how can the practices of Agile be applied more broadly to knowledge workers? I think the best way to think about it to briefly recap the points of Agile and at every point where you see the word "product" think "culture." Let's see how that works.
1. The Agile process starts with describing stories about how the product should work. The focus is not on how things aren't working but how they should work. Process step 1: collect stories.
2. In preparation for the sprint planning meeting, have the product backlog (the list of stories about how we want our culture/product to be) in shipshape. This means being clear about the outcome including an defined "when done." This invokes the element of clarity and measurability. When we do workshops on changing culture this reminds me of the step where I ask, "...and how would we know...."
3. Have the sprint planning meeting with the team. Allow the team to determine the scope of what projects will be included in the upcoming sprint. Principle: give control, don't take control. Corollary: move authority to information, not information to authority.
4. Determine overall sprint goal prior to closing the planning meeting. This ensures the necessary supporting condition of clarity is in place.
5. Launch the team and get managers, coacher, owners, out of the way. Again, giving control to the people who know (the coders, testers, developers).
6. Always test the product with a demo before saying "done." This emphasis on actual products is very helpful, especially when changing business cultures where sometimes there is a tendency to think in terms of vague changes in mindset. Instead, we should focus on specific behavioral changes that we can observe and measure.
7. Conduct an assessment of how the Sprint went and measure team velocity. This would apply to following up on whether behavioral changes are sticking or not?
OK, well, that seems clear enough but when it came down to it, what was the leadership team actually working on -- the parallel to the code the developers were writing? Well, I think the code (sometimes I call it the DNA) for the company's culture is written in the policy documents that give authority for making decisions and detail how we will interact with each other. The cultural "coders" work on these policy documents in the same way the software developers work on the code. ( )