애자일은 도구가 아니다.
사람과 사람이 이해를 바탕으로 일할 수 있도록 돕는 철학과 목적이다.
애자일 방법론이라는 것은 생각해 보면 오히려 비즈니스 사이드에서 요청하기 더 좋은, 또 적용하고 싶은 개발 방법론일 수 있다고 생각한다. 뭔가 좋은 회사라면 당연히 이렇게 일할 것 같다는 느낌이 나기도 하고, 독특할 것 같아서도 있지만, "그래서 언제까지 되는데?"를 잘못된 스토리 포인트 산정 방법을 통해서 통제를 하려 하고, 그때까지 수행하지 못한 팀에 책임을 전가하고 비난할 수 있는 도구가 될 수 있기 때문에.
출처: https://agilesista.com/애자일 매니페스토에서 이야기한 것처럼, 프로덕트를 만들며
1. "프로세스"와 "도구를 사용하는 것"에 집중하기보단 사용자에게 맞는 프로덕트를 만들어 가고 있는지 먼저 확인하고, 목표를 이루기 위해 무엇을 먼저 해야 하고 높은 확장성(Scalability)을 가져가기 위해선 어떻게 해야 하는지에 대해 서로가 의논을 통해 가안을 도출하고 결과에 대해서 자유롭게 의사소통하는
2. "문서를 만들었는데 급급"하기보단, 지속적으로 엔드유저에게 제공하는 가치를 만드는 과정 자체가 자동적으로 문서화되고, 프로덕트가 지속적으로 성장하는 것 자체가 동력이 되는
3. "아무리 적어도 이 정도는 만들어야 되진 않을까"로 지속적으로 늘어나는 개발 공수와 복잡도에 배포를 늦추지 말고, 진짜 사용자들이 얻을 수 있는 가치부터 빨리 배포하고, 예상했던 문제들 중 가장 문제라고 사용자들이 이야기하는 것부터 고쳐나가는
4. "이번 분기 계획"도 중요하지만, 계획보다 실제 서비스를 만들어 가면서 사용자들에게 가장 필요한 부분을 찾는다면 필요한걸 먼저 진행할 수 있는
방법으로 일하는 것을 선호하고 잘할 수 있다고 생각하는 것이지,
"우리 스토리 포인트가 n 점이니깐 다음 주에 이거 못하면 문제다."
"우리 팀 한 명의 스프린트 기준 스토리는 n 점인데 너만 항상 n-2 점이다. 너는 뭐가 문제냐."
"스프린트 목표 달성에 실패했으니, 이번 스프린트는 3주째로 밀린다. 회고도 스프린트 끝난 다음에 한다."
"회고도 없을 수 있다. 스토리 포인트 다 맞춰야 하니까."
"우리가 일을 잘 못하는 이유는 네가 지라에 업무 공유를 잘 안 해서이다."
"나는 내가 고객으로 생각했을 때 이 기능은 정말 최소기준이라고 생각한다."
의 형식의 애자일을 옹호하는 게 아니다.
IT, Product Management, Agile, Scrum, Kanban, Waterfall, 등등등 방법론과 수행과정에 대한 수많은 도서들과 글들이 생산되고 소비되는 이유는, 그만큼 다양한 IT 프로덕트/ 프로젝트들이 생겨나고 있다는 뜻이고, 많은 사람들이 시작할 때 생각한 만큼 원하는 것들을 달성하지 못하고 있다고 생각하고 있다는 뜻이라고 생각한다. 방법론과 적용방법에 관한 도서들이 많아지고 글들이 많아질수록, "본질"을 찾아가기보단 "누군 이렇게만 했는데 안 밀리고 잘되었다고 하더라"에 집중하게 되는 것 같아 마치 미취학 아동들에게 전기톱을 쥐어준 것 같은 무서움을 느낀다.
Forbes에 실린 "The End of Agile"이란 글은 애자일이라는 "무기"로 진행되던 다양한 프로젝트들 때문에 애자일 차제에 대해 환멸과 공포를 가진 사람들이 생겨나고, 왜 그리고 어떻게 이런 상황이 발생했는지에 대해 이야기한다. 그리고 그 중심엔 사용자가 얻는 가치가 아닌, 기능 개발과 달성 여부에만 집중하게 되는 경향에 있다.
이 글에서는 프로세스 자체가 사용자가 얻는 효용보다는 특정한 기능에 대해서 집중하고, 기능을 개발하기 위한 환경과 상황을 자신이 아는 배경을 가지고 "추측" 후 규정짓기 쉬운, 또는 익숙한 도구를 사용해 진행하고, 달성의 조건을 "완료해야만 하는 시간"으로 설정하고, 완료해야 하는 시간 안에 기능을 만들지 못한다는 것은 프로젝트 실패를 의미한다는 강박에서 업무를 하다 보니 많은 팀들은 애자일에 환멸을 느끼고 떠나게 됨을 이야기하고 있다.
그리고 이는 처음 애자일이라는 소프트웨어 개발에 도입하고, 다양한 방법과 구현 방법을 만들고자 하는 사람들이 생각한 개념에서 방법론을 도입하는 것이 아니라, 만들어져 있는 템플릿과 달성의 조건을 프로덕트 라이프 사이클에 대한 집중이 아닌, 단기적인 프로젝트의 달성 조건에서만 집중하는데서 비롯된다고 생각한다.
애자일은 중앙중심적으로 기계처럼 내려가 목표를 달성하기 위해 사용되는 도구가 아니다. 같이 일하는 우리 모두가 재밌게 같이 일할 수 있는 방법을 제시하는 것이고, 이를 통해 공감을 기반한 프로덕트를 만들자는 철학이고 이를 달성하기 위해서는 체크리스트에 한줄한줄을 추가해 "달성 여부"를 판단한다기 보단, 지속적으로 서로를 이해하고, 사용자를 이해하는 과정을 공유하는 것이 더 소중하다.
