TDD, Agile, DDD, MSA - 2

2022년 초에 읽었던 애자일 선언문과 2022년 말에 읽은 애자일 선언문은 달랐다. - 애자일 선언문 : https://agilemanifesto.org/iso/ko/manifesto.html - '가치 있는 소프트웨어' : 가치 있는 소프트웨어란 고객이 원하는 소프트웨어를 말하는 것이고, 고객이 원하는 소프트웨어를 만들기 위해서는 고객 요구사항 분석 능력이 아주 뛰어나야 한다. PO가 원하는 걸 만드는게 아니라 고객이 '필요로'하는 것을 만들어야 한다. - '일찍 지속적으로' : 어떤 방법으로 고객의 요구사항을 분석하더라도 완벽하게 고객이 '원하는 것'이 아닌 '필요한 것'을 한 방에 이해할 수는 없다. 그래서 최소단위의 실행가능한 프로덕트를 고객이 원하는 시점보다 '일찍 지속적으로' 딜리버리 함으로써 고객이 필요로하는 프로덕트를 만들어 나가는 것이라고 생각한다. 그냥 단순히 빨리빨리 개발하는게 애자일이 아니다. - '개발의 후반부일지라도 요구사항 변경을 환영하라' : 후반부라도 요구사항이 변경되었다는 것은 시장이 혹은 고객의 고객이 변한 것이다. 세상은 변했는데 프로덕트가 변하지 않는다면, 이미 시장의 수요를 충족하지 못하는 프로덕트다. 변화하는 요구사항을 수용해서 더 높은 가치의 소프트웨어를 딜리버리 해야한다. 그러나 여기서 반드시 구분해야할 것이 있다. '요구사항 분석'을 못해서 나중에 밝혀진 '고객의 요구사항'과 시장이 바뀌면서 수정된 '고객의 요구사항'은 구분 해야한다. - '비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체 라이프 사이클 동안 항상 함께 일해야 한다.' : 워터풀 모델, V자 모델, 나선형 모델, 여러 개발 방법론으로 프로젝트를 수행했지만 계속해서 새로운 유형의 개발 방법론이 나오고 그렇게 애자일 방법론까지 나왔다. 이유가 있다면, 지속해서 변하는 외부 요인에 대응하여 프로젝트 종단에도 살아있는, 가치있는 프로덕트를 만들기 위해서일 것이다. 즉, 프로덕트가 시장과 함께 움직여야하고 그러기 위해서는 비즈니스 쪽의 사람들(시장)과 개발자(프로덕트)가 프로젝트의 시작부터 끝까지 같이 일해야 한다. - '동기가 부여된 개인들 중심으로 프로젝트를 구성하라' : 글 내에서는 다른 말로 '자기 조직적인 팀(Self-Organized Team)'이라고도 표현한다. 쉽게 말하면 알잘딱하는 구성원들로 이루어져야 한다. 도메인에 대한 이해와 지식을 높인다. 요구사항이 알맞은지 검증&검토할 수 있다. 이에 맞게 시스템을 설계할 수 있다. 차후의 변화에 대응이 가능하도록 설계할 수 있다. 개발 및 테스트까지 최소한의 노력으로 목표한 결과물을 생산한다. - '팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.' : 스프린트 회고를 통해 팀이 일하는 방식이나 프로세스를 팀에 맞게 개선해 나가야 한다. 이는 팀 전체 구성원에게 영향을 주는 것으로 어느 한 명만 의견을 내서도 어느 한 명이 결정해서도 안 된다. 일하는 방식이나 프로세스에 문제가 있음을 느끼면 문제를 공유하고 모두가 참여하여 해결 방법을 도출해야한다. 그러한 팀원들로 구성되어야 한다. 애자일이라는 이름따라 '빠르게'라는 의미에 꽂혀서 애자일 방법론을 채택하는 조직을 보면, 화로에 던져지는 개발자들이 떠오른다. 애자일은 절대 쉬운 개발방법론이 아니다. 특히나 수준 높은 조직원들이 셋팅되어야 가능한 방법론이라고 생각한다. 새해에 새로운 프로젝트를 할 때 애자일 방법론을 채택하게 된다면, 그때는 작년보다는 좀 더 잘 해보고 싶다.