쉬운 것은 올바르다

정보

지은이: Ken Schwaber and Mike Beedle
펴낸 곳: Prentice Hall
펴낸 날: 2001년 10월 21일
ISBN: 978-0130676344(9780130676344)

평점

★★★☆☆

평가

스크럼의 철학에 대해 알고 싶은 사람에겐 어느 정도 도움이 될 수 있겠지만, 구체적인 실천 방법에 대해 잘 나와 있지 않습니다. 그리고 구체적인 문제나 결과에 대해 나와 있지 않아서, 글쓴이의 주장에 쉽게 동의하기 어렵습니다.

인상깊은 부분

viii쪽:
Scrum represents a new, more accurate way of doing software development that is based on the assumption that software is a new product every time that it is written or composed.

viii쪽:
Finally, we show through case studies that Scrum reduces risk and uncertainty by making everything visible early and often to all the people involved and by allowing adjustments to be made as early as possible.

5쪽:
Of course, the PNP team was still approached innumerable times (even by Rusty) with requests to develop functionality that was not on the Product Backlog for the current Sprint. People who made these requests were asked to wait and to put these items in the Product Backlog. If their requests became top priority, they would be implemented in the next Sprint. Because the Sprint was only for thirty days, everyone could accept waiting until the end of the Sprint.

11쪽:
Requirements are not fully understood before the project begins. The user knows what they want only after they see an initial version of the software.

34쪽:
The practice Scrum adds is that only one person is responsible for maintaining and sustaining the content and priority of a single Product Backlog. Otherwise, multiple conflicting lists flourish and the Scrum teams don't know which list to listen to.

37쪽:
Minimize the interaction and dependencies between the teams and maximize the cohesion of the work within each team.

45쪽:
The Scrum Master's top priority is removing impediments.

49~50쪽:
The team modifies Sprint Backlog throughout the Sprint. As it gets into individual tasks, it may find out that more or fewer tasks are needed, or that a given task will take more or less time than had been expected. As new work is required, the team adds it to the Sprint Backlog. As tasks are worked on or completed,  the hours of estimated remaining work for each task is updated. When tasks are deemed unnecessary, they are removed.

51쪽:
No person outside the team can change the scope or nature of the work the team is doing during a Sprint.

52쪽:
The risk is limited to thirty calendar days of the team's Sprint.

56쪽:
Sprint Review Meetings are very informal. What matters is the product the team has been able to create.

73쪽:
Scrum is result oriented, not process oriented.

83쪽:
Establishing an open, honest relationship with the customer is the most important aspect of Scrum; Scrum makes everything visible;

106쪽:
First and foremost, the assumption that software is manufactured and that it therefore should follow similar processes to manufacturing is incorrect.

109쪽:
Another useful way to look at Scrum is as a risk reduction system.

120쪽:
The virtues of Scrum from this perspective, are that Scrum provides very many feedback cycles at different levels of scale

124~125쪽:
Very many developers and managers that work with new technologies touted as "reusable technologies" are accustomed to always working in the first release of an application. They tend to think that this is the most interesting part of development. The contrary is true - the interesting part of "reusability" starts to happen in the release of a second application and beyond.

125쪽:
My advice is simply: don't try to reuse anything that is not stable enough.

152~153쪽:
Since it is the team as a whole that commits to the Sprint goal, the team is going to sink or swim together. There are no individual heroics, just team heroics. When a team member is weak, other team members have to pick up the slack.