지난주 토요일과 주일(2013년 4월 13일부터 14일까지) 이틀간 Scrum.org 에서 진행하는 The Professional Scrum Foundations Program 에 다녀왔습니다.
오랜만에 듣는 교육이고, 지난 번에 게으름으로 선착순에서 밀려서 듣지 못했던터라 두근거리는 가슴을 안고 참여했습니다.
배우고자 하는 지식을 배운다는 사실은 언제나 기분이 좋습니다.
회사에서 별 쓰잘데기 없이 강제로 시켜주는 교육은 지옥이지만요..
어쨌든 그동안 책으로만 배운 지식을 체계적으로 배울 수 있지 않을까? 라는 기대로 교육에 참여했습니다.
이틀동안 진행된 교육은 이론적인 설명은 거의 없이 실습으로만 구성되었습니다.
다른 분들은 어떨지 모르겠지만 전 나름 괜찮았습니다.
그런데, 실습 속에서 무언가를 스스로 배우고 깨닫는다는 것은 분명 약간의 한계는 있는 것 같습니다.
체계적으로 정리가 잘 안된다고 할까요..
반면에 그 느낌은 참 오래도록 기억될 것 같습니다.
교육 내용이나 이런걸 여기서 상세하게 피력하는 것은 한계가 있고..
교육을 듣고 제게 가장 의미가 깊고 가장 기억에 남는 것 딱 두가지만 공유하고자 합니다.
첫째는, 프로덕트 백로그에 대해서 다시 한번 생각해 볼 수 있는 시간이었습니다.
기존에 저는 프로덕트 백로그라 하면 사용자 스토리나 기능 리스트 정도로만 생각했었는데, 이번 교육에서는 프로덕트 백로그에는 Features definitions, Contraints, Behaviours, User actions or stories, Bugs / defects, Use cases, Desirements, Non-functional requirements 등 다양한 내용들을 아이템으로 다룰 수 있다는 얘기가 가장 신선했습니다.
반면에 저런 모든 것들을 스프린트 안에서 잘 다루기는 또 쉽지 않을 거라는 생각도 같이 들었습니다.
두번째는, 스크럼에는 실패도 성공도 없다는 말이 가장 기억에 남았습니다.
우리가 스크럼을 도입하고 프로젝트 또는 팀이 실패하는 경우 스크럼이 실패했다고 인식하는 경우가 많은데, 스크럼이 문제가 아니라 적용하는 사람이 문제라는 것이 어찌보면 아주 당연한건데 그동안 뚜렷하게 인식하지 못했다는 것이 기억에 남습니다.
그러고보면 언제 어디서나 문제는 항상 사람이지요.
제약이론에서도 근본 원인을 탐색하다보면 많은 경우 특정 사람(특히 경영층이나 의사결정권자)의 가치관이나 어떤 행동이 원인이 되는 경우가 많다는 것으로 미루어보아도 사람은 참 어렵다는 것을 새삼 깨닫게 되었습니다.
아쉬운 점은 저는 이번 교육에서 프로덕트 오너의 역할을 수행했었는데, 프로덕트 오너로서 고객과 얘기를 많이 해보지 못했다는 것이 가장 아쉽습니다.
실습 시간 배정에서 고객과 프로덕트 오너가 같이 요구사항에 대해서 얘기를 나눌 수 있는 그런 시간 배정을 해주는 것이 더 좋지 않을까라는 생각을 해보았습니다.
저와 같은 팀을 이루셨던 분들은 저처럼 무능한 프로덕트 오너를 만나셔서 고생만 하시고 많이 배우시지 못한것이 아니신지 심히 반성을 해봅니다.
저 자신도 명확하게 프로덕트 오너의 역할에 대한 이해가 부족한 상황에서 제대로 요구사항을 전달하지 못한것이 아닌가라는 반성을 해봅니다.
욕심은 많고 머리와 몸은 따라가주지 않으니.. 에휴..
교육이 끝나고 드는 생각은 이렇습니다.
우리가 개선을 하고자 할때 어떤 방법론을 선택하는가는 중요치 않다라는 생각을 해봅니다. 중요한 것은 변화와 개선을 조직과 이해관계를 같이 하는 사람들이 모두 가지고 있고 그에 대한 열정을 가지고 변화에 대한 준비가 되어 있는가라고 봅니다.
그런 마음가짐이 있을 때 더 나은 방법 중 하나가 스크럼이라고 봅니다. 세상에는 스크럼 말고도 많은 방법론들이 있지만 역시 중요한 것은 사람이지요.
오랜만에 그런 생각을 할 수 있었던 것 만으로도 이번 스크럼 교육은 저에게 많은 도움이 되었습니다.
여러분도 기회가 되신다면 꼭 한번 들어보시기 바랍니다.
오랜만에 듣는 교육이고, 지난 번에 게으름으로 선착순에서 밀려서 듣지 못했던터라 두근거리는 가슴을 안고 참여했습니다.
배우고자 하는 지식을 배운다는 사실은 언제나 기분이 좋습니다.
회사에서 별 쓰잘데기 없이 강제로 시켜주는 교육은 지옥이지만요..
어쨌든 그동안 책으로만 배운 지식을 체계적으로 배울 수 있지 않을까? 라는 기대로 교육에 참여했습니다.
이틀동안 진행된 교육은 이론적인 설명은 거의 없이 실습으로만 구성되었습니다.
다른 분들은 어떨지 모르겠지만 전 나름 괜찮았습니다.
그런데, 실습 속에서 무언가를 스스로 배우고 깨닫는다는 것은 분명 약간의 한계는 있는 것 같습니다.
체계적으로 정리가 잘 안된다고 할까요..
반면에 그 느낌은 참 오래도록 기억될 것 같습니다.
교육 내용이나 이런걸 여기서 상세하게 피력하는 것은 한계가 있고..
교육을 듣고 제게 가장 의미가 깊고 가장 기억에 남는 것 딱 두가지만 공유하고자 합니다.
첫째는, 프로덕트 백로그에 대해서 다시 한번 생각해 볼 수 있는 시간이었습니다.
기존에 저는 프로덕트 백로그라 하면 사용자 스토리나 기능 리스트 정도로만 생각했었는데, 이번 교육에서는 프로덕트 백로그에는 Features definitions, Contraints, Behaviours, User actions or stories, Bugs / defects, Use cases, Desirements, Non-functional requirements 등 다양한 내용들을 아이템으로 다룰 수 있다는 얘기가 가장 신선했습니다.
반면에 저런 모든 것들을 스프린트 안에서 잘 다루기는 또 쉽지 않을 거라는 생각도 같이 들었습니다.
두번째는, 스크럼에는 실패도 성공도 없다는 말이 가장 기억에 남았습니다.
우리가 스크럼을 도입하고 프로젝트 또는 팀이 실패하는 경우 스크럼이 실패했다고 인식하는 경우가 많은데, 스크럼이 문제가 아니라 적용하는 사람이 문제라는 것이 어찌보면 아주 당연한건데 그동안 뚜렷하게 인식하지 못했다는 것이 기억에 남습니다.
그러고보면 언제 어디서나 문제는 항상 사람이지요.
제약이론에서도 근본 원인을 탐색하다보면 많은 경우 특정 사람(특히 경영층이나 의사결정권자)의 가치관이나 어떤 행동이 원인이 되는 경우가 많다는 것으로 미루어보아도 사람은 참 어렵다는 것을 새삼 깨닫게 되었습니다.
아쉬운 점은 저는 이번 교육에서 프로덕트 오너의 역할을 수행했었는데, 프로덕트 오너로서 고객과 얘기를 많이 해보지 못했다는 것이 가장 아쉽습니다.
실습 시간 배정에서 고객과 프로덕트 오너가 같이 요구사항에 대해서 얘기를 나눌 수 있는 그런 시간 배정을 해주는 것이 더 좋지 않을까라는 생각을 해보았습니다.
저와 같은 팀을 이루셨던 분들은 저처럼 무능한 프로덕트 오너를 만나셔서 고생만 하시고 많이 배우시지 못한것이 아니신지 심히 반성을 해봅니다.
저 자신도 명확하게 프로덕트 오너의 역할에 대한 이해가 부족한 상황에서 제대로 요구사항을 전달하지 못한것이 아닌가라는 반성을 해봅니다.
욕심은 많고 머리와 몸은 따라가주지 않으니.. 에휴..
교육이 끝나고 드는 생각은 이렇습니다.
우리가 개선을 하고자 할때 어떤 방법론을 선택하는가는 중요치 않다라는 생각을 해봅니다. 중요한 것은 변화와 개선을 조직과 이해관계를 같이 하는 사람들이 모두 가지고 있고 그에 대한 열정을 가지고 변화에 대한 준비가 되어 있는가라고 봅니다.
그런 마음가짐이 있을 때 더 나은 방법 중 하나가 스크럼이라고 봅니다. 세상에는 스크럼 말고도 많은 방법론들이 있지만 역시 중요한 것은 사람이지요.
오랜만에 그런 생각을 할 수 있었던 것 만으로도 이번 스크럼 교육은 저에게 많은 도움이 되었습니다.
여러분도 기회가 되신다면 꼭 한번 들어보시기 바랍니다.
댓글
댓글 쓰기