Dr. Dobb‘s | Scaling Scrum | (一)

来源:百度文库 编辑:神马文学网 时间:2024/03/28 20:51:17
? 08, 2008
Scaling Scrum
Meeting real-world development needs
(Page1 of3)
Scott W. Ambler
Scrumis an agile methodology that focuses on a subset of project managementand requirements management. But some organizations are finding it canbe a challenge to scale Scrum to meet the complexities of theirreal-world environments.
Scott is a DDJ Senior Contributing Editor and author of numerous IT books. He can be contacted atwww.ambysoft.com/scottAmbler.html.
is an agile methodology that focuses on a subset of project managementand requirements management. Scrum has become popular in the past fewyears with the rise of agile software development, and is often used toround out Extreme Programming (XP); or perhaps XP is used to fill outScrum, I guess it depends on your point of view. Scrum is particularlysuited for "agile in the small" projects due to its simplicity, but asmany organizations are finding, it can be a challenge to scale Scrum tomeet the complexities of their real-world environments. The good newsis that over the past few decades various people have identified awealth of techniques which we can adopt and adapt to address thesechallenges.
Scrum was developed by Jeff Sutherland, John Scumniotales, and JeffMcKenna in 1993 during their work at Easel Corporation. It was thenpopularized through the efforts of Ken Schwaber and more recently bythe Scrum Alliance (www.scrumalliance.org). Although there is a lot ofmaterial available online and in books about Scrum, my favoriteresource is Mike Vizdos‘s www.implementingscrum.com site because it notonly provides real-world advice for making Scrum work in practice, itdoes so in a light-hearted manner through the use of cartoons.
Figure 1 depicts the Scrum Construction lifecycle, modified from the lifecycle diagram presented by Jim Highsmith in Agile Software Development Ecosystems(Pearson Education, 2002) showing the fundamentals of the methodology.Scrum teams work from a product backlog, a prioritized stack ofrequirements maintained by the "product owner" who is responsible forworking closely with the team to represent the overall stakeholdercommunity. At the beginning of each "sprint", a timebox which issuggested to be 30 calendar days but can be any length in practice, theteam identifies the requirements that they will implement during thatsprint and plans out how they‘ll do it. At the beginning of each daythroughout the sprint the team gets together for a 15-minute "scrummeeting" where each person indicates what they did yesterday, what theythink that they‘ll do that day, and whether anything is blocking theirprogress. At the end of the sprint, the team should have produced apotentially deployable version of the system that they‘re developingwhich now implements the requirements that the team committed to at thebeginning of the sprint. A demo is held with relevant stakeholders toobtain feedback and commitment to fund the next sprint. Many Scrumteams, as is the norm with agile teams in general, will hold aretrospective to identify potential improvements to the process thatthe team is following.
The lifecycle of Figure 1 is reasonable from a high-level point ofview, but it leaves out a lot of detail. Scrum doesn‘t provide anyadvice for how to go about actual implementation; that‘s a detailthat‘s left up to you. Nor does the lifecycle indicate how to initiatea project, or deploy your system into production at the end of thelifecycle. Recently Scrum has been touted as a process framework, butas you‘ll see a more accurate way to think about it is to view it asone part of the overall process picture. It is definitely a processframework from a consultantware point of view, and we‘ve not only seena consulting cottage industry grow up around Scrum but even an allianceof said consultants. I‘ve found that to scale Scrum to meet thereal-world needs of IT departments, you must consider the fulldevelopment lifecycle and consider the full range of IT concerns.
[Click image to view at full size]

Figure 1: The Scrum Construction Lifecycle. Deliver a potentially shippable system every 30-day sprint.