애자일에 대한 경험이 많다고 할 수는 없지만

오랜 기간 IT업계에 있으면서 나름 회사에 애자일 도입도 시도해보고

독립해서 애자일스럽게 일을 해본 경험들을 토대로 짧은 답변 정도 드릴 수 있을 것 같습니다.

올리신 질문에 답변을 드리자면 다음과 같습니다.

첫째, 실제 현업에서 개발을 하실 때, 흔히 말하는 애자일, 혹은 폭포수 개발 방법론에 입각하여 개발을 진행 하시나요? 혹시 그렇다면 어떤 방식으로 진행되는지 궁금합니다.

제가 알기론 대부분의 업체에서는 애자일 방법론보다는 폭포수 개발 방법론에 입각하여 개발을 진행하는 경우가 훨씬 많은 것으로 알고 있습니다.

일단 소위 SI라고 하는 외주 개발 방식의 업계에서는 100% 폭포수 방법론이라고 보시면 됩니다.

SI라는 것이 만들어야 할 제품을 최대한 미리 정의하고 최대한 그것에 맞추어 개발을 해야하는 것이 현실이기 때문입니다.

서비스 형태의 IT 업계에서도 많은 회사가 폭포수 방법론에 가까운 프로세스로 진행을 하고 있는 것 같습니다.

애자일이 도입되려면 구성원들이 애자일에 대한 이해와 의지가 있어야 하는데 아직은 현실이 그렇지 못한 경우가 많은 것 같습니다.

회사의 대표, 임원, 기획자, 개발자가 모두 그런 의지를 갖기는 현실적으로 어렵습니다.

그런 이유로 이미 폭포수 방법론에 가까운 조직 문화가 형성된 회사에 애자일을 도입한다는 것이 쉬운 일은 아니었던 것 같습니다.

독립해서는 보다 애자일스러운 방법론을 지향하고 있기는 합니다.

하지만 한편으론 “방법론”이라는 것에 최대한 신경쓰지 말자는 것이 저의 방법론이기도 합니다.

이상과 달리 현실에서는 뭔가 프로세스를 정하기엔 너무나도 다양한 변수와 조건들이 있기 때문인 것 같습니다.

둘째, 혹시 애자일 방식으로 진행하실 경우, 하나의 Sprint에 프로그램 전체의 뼈대를 잡고 스프린트를 반복시키며 구체화해 나가시는지, 혹은 Sprint별로 하나의 컴포넌트 단위로 진행해 나가시는지 궁금합니다.

케이스 바이 케이스인 것 같기는 하나 보통은 전체 뼈대를 잡고 스프린트를 반복시키는 방식에 가까운 것 같습니다.

결국 서비스는 서로가 유기적으로 연결되어있고 항상 전체 그림을 염두하면서 진행해야하기 때문인 것 같습니다.

셋째, 개발을 계획하고 실행하기 위해 작성되는 문서들에는 무엇이 있을까요?

회사에 있을 때는 다양한 문서들을 요구하곤 합니다.

기획서, 요구사항 명세, DB 설계서 등 보고를 위한 각종 문서를 작성하곤 합니다.

회사를 나온 후에는 최대한 불필요한 문서는 만들지 않으려고 합니다.

기획서는 손으로 그린 아이디어 스케치로 대체하고, 간단한 요구사항 명세만 만듭니다.

DB 설계서 같은 것들은 DB ERD 툴로 대체합니다.

그 밖에는 솔직히 보고를 위한 목적이 아니라면 특별히 문서를 만들 필요는 없는 것 같습니다.

마지막으로, 실제 프로젝트를 진행하시는 데에 있어 활용하시는 협업툴이 있으시다면, 어떤 종류가 있으신지 궁금합니다. 또한, 그러한 협업툴에서 느끼는 장점과 단점 혹은 추가되었으면 하는 기능들에는 무엇이 있을까요??

요구사항 목록을 공유할 때는 간단하게 구글 문서도구를 사용해도 충분한 것 같습니다.

Slack과 같은 메신저를 쓰기도 하지만 때로는 Slack 사용을 어려워하시는 분들도 있고 메신저는 카카오톡 정도로도 충분한 경우도 많은 것 같습니다.

마지막으로 드리고 싶은 의견은

방법론이라는 것이 필요한 고민이긴 하지만 그것은 항상 비지니스의 성공을 전제로 해야한다는 것입니다.

방법론을 고민하다가 자칫하면 원래의 목적을 소홀히하고 방법에만 집중하느라 리소스를 낭비하는 경우들도 많이 보았습니다.

그러한 상황이 발생하지 않으려면 어떻게 해야하는 지에 대한 고민도 매우 중요하다는 의견을 말씀드리고 싶습니다.

아마도 원하시는 답변을 드리지 못한 것 같아 죄송합니다.

언제든지 관련해서 혹은 관련없는 내용이라도 궁금한 것들을 남겨주시면 성심성의껏 답변드리도록 하겠습니다.

감사합니다.