Scrum Development Process는 "Agile Alliance"의 대표 주자 중 하나입니다. XP(eXtreme Programming)만이 Agile은 아닙니다. XP가 프로그래밍에 초점을 맞춘다면, Scrum은 Management Process에 초점을 맞추고 있습니다. Scrum에 대한 자세한 내용은 [Pattern Languages of Program Design 4]에 실린 [SCRUM: An extension pattern language for hyperproductive software development]를 참조하시면 됩니다.
http://ootips.org/yonat/Scrum.pdf
그 외 Scrum을 이끌고 있는 Ken Schwaber와 Jeff Sutherland의 홈페이지도 참조하시기 바랍니다.
http://www.controlchaos.com/
http://www.jeffsutherland.com/scrum/index.html
내용 하나
Most development teams respond with, 'Make the chaos go away! Give us better requirements!' Unfortunately or not, chaos is the reality in this new business environment - as software developers we must learn how to meet customer needs and turn this chaos to our advantage.(26 page)Chaos(멍 청하고 변덕스러운 고객과 기술 및 시장의 급격한 변화 등)는 위협(Threat)이 아닌 사업기회(Business Opportunity)입니다. 멍한 고객이 요구사항을 바꾸자고 하면 화내지 말고 쓰다듬어 주어야 합니다. 이 이쁜 것... Just embrace change!
내용 둘
Scrum advocates the use of small teams - no more than 10 team members..... (In the big project,) We thought initially that we could simply divide larger teams into collections of smaller subteams, each no larger than 10. We found that when the subteams are independent and the interfaces well defined, this works. When the overlap is considerable and the interfaces poorly understood, the benefits are not as great. Clearly, this(Scrum) is not an approach for large, complex team structures, but we found that even small, isolated teams on a large project could make use of some elements of Scrum. This is true process diversity.(29 page)아직까지는 Agile Software Development와 프로젝트 규모와의 관계에 대한 적절한 답은 위의 발췌 내용이라고 생각합니다. 결국 규모가 큰 프로젝트는 Agile 대신 다른 것(RUP? ... 옌 될까?)을 선택하거나 위의 조건(when the subteams are independent and the interfaces well defined)을 충족시키도록해야 할 것입니다. 이를 위해서 중요한 것은 Common Team, Core Team에 대한 고민입니다. 다른 Module Team은 주로 Common Team, Core Team과 Interface를 이룰 뿐 자신들끼리의 Interface는 적기 때문입니다.
내용 셋.
As in all projects, there must be an initial planning phase. During this phase, the project team must develop an architecture and identify a chief architect. During development, the team should be prepared to make changes to this architecture, but they need a plan, an architecture, and a chief architect at the start. The chief architect defines the development project's vision based on this architecture and ensures that visions consistency throughout all the development phases.... 'The Architect role should advise and control the Developer roles and communicate closely with the developers.'(30 page)개인적으로 Architect라는 역할을 좋아하진 않지만 위의 발췌 내용이 바로 Common Team이 해야 하는 것을 정확하게 서술하고 있습니다. Iterative 개발이 가능하려면 바로 Initial planning phase(혹은 warming up time)을 획기적으로 줄여야합니다. 바로 이게 표준 프레임워크의 목표입니다. 워크 플로우, 동적 메뉴 관리, 인증 및 권한 관리, 개발 기법 및 표준의 제공 등... Enterprise Common Team이 Project Common Team(EPM Common 팀)을 리드하고 도와줌으로써, 프로젝트 구성원은 Core Team을 중심으로 움직이도록 해야합니다. Core Team은 해당 애플리케이션에서 가장 중요한 모듈을 개발하는 팀입니다. 인사애플리케이션 개발의 경우 Core는 임직원 및 부서를 포함한 조직 체계를 관리하는 모듈을 개발하는 것이 될테고, 프로젝트 관리 애플리케이션 개발의 경우 프로젝트 정보를 관리하는 것이 Core가 될 것입니다.
내용 넷.
A sprint produces a visible, usable, deliverable product that implements one or more user interactions with the system. The key idea behind each sprint is to deliver valuable functionality..... A sprint is time-boxed development, meaning that the end date for a sprint does not change, The team can reduce delivered functionality during the sprint, but the delivery date cannot change.(30 page)Sprint 는 Iteration 주기와 Release 주기의 중간개념으로 생각하면 됩니다. Sprint의 기간은 무조건(?) 4주보다 짧아야 합니다. SCMS에 비해서 NRMS의 결과나 생산성이 떨어졌던 이유에 대한 답이라고 생각합니다. 도메인의 복잡도에 차이가 있기 했지만 SCMS의 경우에는 time-box를 지켰던데 비해서 NRMS에서는 계속 날짜를 미루면서 Waterfall도 Iterative도 아닌 애매한 방식으로 개발을 진행했던 것이 가장 큰 실수 였다는 개인적인 생각이 듭니다.
클라이언트 애플리케이션과 웹 애플리케이션 개발 사이에 나타나는 차이 중에 하나가 바로 Beta 버전의 존재라고 생각합니다. 클라이언트 애플리케이션에는 여러차례의 Beta 버전의 출시 후에 최종 제품이 릴리즈 되는 반면, 웹 애플리케이션에는 Beta 버전 개념이 없는 것 같습니다. Iterative 개발을 하기 위해서는 Beta 버전이라는 개념에 기반한 Dynamic Release 방식을 채택할 필요가 있다고 봅니다.
내용 다섯.
The organization can make one very important decision at the end of a sprint: whether to continue product development. Given what was delivered during the last sprit and the current state of the market, the stakeholder meeting should address the question, "Should this project contiune?" This is a business decision and must be made after considering all the technical and marketing issues.'(32 page)어렵지만 회피해서는 안되는 고민인 것 같습니다. 안그러면 NRMS 처럼 됩니다.
저번 주는 5년 전에 배웠던 생산 관리 교제[Operations Management - Strategy and Analysis, 4th (Krajewski / Ritzman)]를 꺼내 읽어야 했습니다. CMM과 RUP에서는 Frederick Tayler의 과학적 관리법이나 포드적 생산방식의 냄새가 난다면 과장일까요. 5년전 생산관리 시간에도 그런 구다닥리 기법은 가르치지도 배우지도 않았습니다. Lean Manufacturing이나 JIT(Just-In-Time) 등에서 Agile의 냄새가 난다면 과장일까요.
At XP2002 in Sardinia, noted economist Enrico Zaninotto observed, "... it appeared to me that software industry was trying to mimic method of industrial organization already exhausted ... industrial organization theory changed its view during the 1970's." What the software industry had been trying to mimic over the last twenty years - a more defined and granular approach to the process of software development was discredited and abandoned by a manufacturing industry that embraced lean manufacturing. Enrico observed that lean manufacturing is much like Extreme Programming and the agile processess.
XP2002에서 Kent Beck이 이런 말을 했군요.
At XP2002, Kent Beck called for focus during the next year on "the year of the manager," as we move agile practices into IT management and even into the business and IT management relationship. Indeed! Agile causes profound changes to this relationship and practicing, educating, and assisting IT and business management in the change will be a major factor in the success of the agile processes over the next years.
이미 NEXT YEAR은 올해입니다. 그리고 벌써 4월말입니다. 중학교 때 보았던 찰리 채플린의 [Modern Times]가 보고 싶은 하루입니다. 그 우울한 웃음도...
No comments:
Post a Comment