들어가며
우리팀은 애자일하게 일합니다.
IT회사 채용 공고라면 흔하게 나오는 말이고, 와닫지도 않는 말이다.
음.. 애자일? 애자일 방법론이라는게 있었는데..
아~ 빠르고 기민하게 개발하는 소프트웨어 개발 방식이지! 근데, 그래서?
나는 애자일하게 일한다는게 뭔지 와닿지 않고, 의례적으로 써둔 말인지 알았다.
물론 이제는 채용 공고 단어 하나하나에 얼마나 고민을 하고 올리는지 알게 되었지만, 그때는 그랬다.
애자일 선언문
애자일 방법론이 워낙 대중적인 단어이기 때문에, 단순히 소프트웨어의 개발 방식이라고만 생각하는 분도 계실거라고 생각한다.
하지만 애자일은 단순히 소프트웨어 개발에 필요한 작업을 나열해놓은 규칙 같은게 아니라, 일종의 가치다.
우리가 협업을 어떻게 하고, 개발을 어떻게 하는지, 무엇을 중요하게 생각하는지에 대한 내용이다.
애자일은 정확히 말하자면 소프트웨어 개발에 필요한 작업을 알려주는 일련의 규정이 아닙니다. 그보다는 협업과 워크플로우를 바라보는 하나의 관점이며, 우리가 무엇을 어떻게 만들지에 관한 선택을 안내하는 가치 체계입니다.
구체적으로 말하자면, 애자일 소프트웨어 개발 방법론의 핵심은 작동하는 소프트웨어의 작은 구성 요소를 신속하게 제공하여 고객의 만족도를 개선하는 것입니다. 이러한 방법은 적응형 접근 방식과 팀워크를 활용한 지속적인 개발에 중점을 두고 있습니다. 일반적으로, 애자일 소프트웨어 개발은 소프트웨어 개발자와 비즈니스 담당자가 자체적으로 조직한 소규모 팀으로 이루어지며, 이들은 소프트웨어 개발 라이프사이클 전체에 걸쳐 정기적으로 직접 만나 협업합니다. 애자일 개발은 소프트웨어 도큐멘테이션에 대한 경량화 방식을 선호하며 라이프사이클의 모든 단계에서 변화를 적극 수용합니다.
[레드햇, 애자일 방법론이란?] https://www.redhat.com/ko/devops/what-is-agile-methodology
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
That is, while there is value in the items on the right, we value the items on the left more.
© 2001, the Agile Manifesto authors
This declaration may be freely copied in any form, but only in its entirety through this notice.
스크럼
스크럼에대해서는 마이크로소프트 블로그에 잘 정리되어있다.
스크럼은 매일 스탠드업이라고도 하는 일일 스크럼이라는 관행을 정의합니다. 매일 스크럼은 15분으로 제한된 일일 모임입니다. 팀 구성원은 간략하게 유지하기 위해 모임 중에 대기하는 경우가 많습니다. 각 팀원은 어제부터 진행 상황, 오늘의 계획, 진행 상황을 방해하는 모든 것을 간략하게 보고합니다.
- 출처 [https://learn.microsoft.com/ko-kr/devops/plan/what-is-scrum]
나는 이번 회사에 들어와서 처음 스크럼이란걸 해봤는데, 주간 회의나 업무 보고와는 다른 느낌이었다.
주간회의는 대부분 일방적인 전달이 목적이었다. 물론 다양한 의견이 오가기도 하지만, 그건 어디까지나 마스터의 마음..
업무보고는 다른 사람이 어떤 일을 하는지는 알 수 있지만, 보고를 하는 사람도 다른 팀원을 청자로 생각하고 준비하는게 아니고, 마스터만을 청자로 생각하고 보고를 하기때문에 이해가 안될 때도 있고 그냥 그렇구나.. 저런 일을 하는구나.. 정도로 그치게 된다.
그런데 스크럼은 조금 달랐다. 마스터(팀장 등)에게 보고를 하는게 목적인 주간회의, 업무보고와 달리 팀에 업무를 공유하고, 서로 동기화를 하는 시간같은 느낌이 들었다. 서로가 이해할 수 있도록 설명해주고, 누군가가 어디서 막힌다고 하면 해결방법을 아는 사람이 도와주거나, 같이 해결하도록 노력하는 시간이다 ( ex. 저 비슷한 문제겪은 적 있는데, 스크럼 끝나고 공유드리겠습니다 🙋♂️ ).
격식 갖춘 회의 처럼 부담스럽지 않으면서도, 효과는 제일 큰 방식 같다.
물론 모든 팀에 이런 방식이 적합하진 않을거라고 생각한다. 서로가 하는 업무를 알고 있어야하고, 공통적인 부분이 많을 때 도움이 되는 거 같다.
스크럼은 애자일의 핵심 원칙인 지속적 개선에 중점을 두기 때문에 스크럼과 애자일이 동일하게 여겨지는 경우가 많습니다. 그러나 스크럼은 작업 수행을 위한 프레임워크이며, 애자일은 철학입니다. 애자일 철학은 빈번한 소규모 릴리스를 통한 지속적이고 점진적인 개선에 중점을 두고 있습니다. 고객에게 가치를 제공하는 방식에 대한 팀의 사고방식을 바꾸는 데에는 팀 전체의 노력이 필요하므로, 단순히 '애자일로 전환'할 수는 없습니다. 하지만 스크럼과 같은 프레임워크를 사용하면 그러한 사고방식을 갖추고 일상적인 커뮤니케이션과 작업에 애자일 원칙을 실현하는 연습을 할 수 있습니다.
스크럼의 정의는 경험주의 및 린 사고를 기반으로 합니다. 경험주의는 경험을 통해 지식을 얻고 관찰한 것을 기반으로 결정을 내리는 것입니다. 린 사고는 불필요한 것을 줄이고 필수 사항에 집중하는 것을 말합니다. 스크럼 프레임워크는 체험을 중시하며, 지속적으로 학습하고 변동 요인을 조정하는 것을 기반으로 합니다. 또한 프로젝트가 시작될 때 팀이 모든 내용을 알고 있지 않으며 경험을 통해 진화해 나간다고 말합니다. 스크럼은 팀이 변화하는 조건과 사용자 요구 사항에 자연스럽게 적응할 수 있도록 구성되었으며, 팀이 지속해서 학습하고 개선할 수 있도록 프로세스에 대해 우선 순위를 재지정하고 릴리스 주기가 짧습니다.
- 출처 [https://www.atlassian.com/ko/agile/scrum]
그래서 플래닝포커는 ?
개인적으로 팀원들과의 신뢰를 키울 수 있는 방법이라고 생각하는 플래닝 방법이다.
나는 이렇게 일하는데 쟤는 뭐하지?
내가 더 잘한거같은데 왜 쟤가 평가 더 잘받았지?
(뭐하는지는 모르겠지만) 엄청 대단한 느낌..
뭐 얼마나 대단한거 한다고 저렇게 오래 걸린대?
이런 생각이 든다는건 팀원에게 신뢰가 떨어졌다는 건데.. 여기서 핵심은 위의 내용은 모두 제대로 알지못해서 생기는 불만이다.
'나는 이렇게 일하는데, 내가 더 잘한거같은데, 뭐 얼마나 대단한거 한다고'는 어디까지나 주관적인 생각이고, 상대방이 어떻게 일하는지는 모르는 거다.
나는 그동안 집단생활이나, 회사생활을 하면서 이런 문제가 생기는건 어쩔수 없고, 리더가 얼마나 역량이 있어서 개별 구성원들에게 잘 설명을 해주는가가 중요하다고 생각했다. 그런데 이번에 플래닝포커를 해보고 '이게 이렇게 되네?' 라는 생각이 들 정도로 놀랐다.
- 카카오 "포커, 어디까지 쳐봤니?" https://tech.kakao.com/2020/09/08/planning-poker/
- 우아한형제들 "데일리미팅! 플래닝포커! 회고!" https://techblog.woowahan.com/2548/
- 올리브영 "플래닝포커" https://oliveyoung.tech/blog/2022-12-07/planning-poker/
플래닝포커는 서로가 납득할 수 있는 공수산정을 하는 시간이다. 따라서 위의 불만들이 없어질 수 밖에(줄어들거나) 없다.
뭐 하는지도 알고, 일정 산정도 같이 했으니까.
플래닝포커를 하면서, 정말 많은 걸 느끼고 배웠다.
일단 팀원에 대한 신뢰도 더 강해졌고, 업무 문화에 대해 관심도 생겼다.
온전히 리더의 영역이라고 생각했던 구성원간의 신뢰가, 일하는 방식을 바꾸는 것만으로 가능하다는 것이 놀라웠다.
서로에 대한 신뢰가 없는 팀은 아무리 개개인의 능력치가 높아봤자, 오래가지 못한다고 생각한다.
하지만 서로에 대한 신뢰가 높은 팀은 개개인의 능력보다 더 좋은 결과를 낼 수 있다고 생각한다.
짧게 보면 괜스레 시간도 오래 걸리고, 귀찮을 수도 있다고 생각이 드는 플래닝포커.
길게 보면 오히려 시간도 절약하고, 신뢰도 높은 팀을 만들 수 있지 ㅇ낳을까?
'회고 > 느낀점' 카테고리의 다른 글
| 펄어비스 필기테스트 후기와 앞으로의 계획 (18) | 2021.06.23 |
|---|---|
| 펄어비스 코딩테스트 후기 (1) | 2021.06.18 |
| 2021 상반기 네이버 코딩 테스트 후기 (0) | 2021.04.25 |
| 3월 알고리즘 공부 총결산 (1) | 2021.04.05 |
