애자일 소프트웨어 개발

들어가기 앞서 애자일 소프트웨어 개발 선언을 한번 같이 보자

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.
이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:

공정은 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보단 고객과의 협력을
계획을 따르기보다 변화에 대응하기를

가치있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

최우선 순위는, 가치 소프트웨어를 일찍 그리고 지속적으로 개발하고 고객에게 전달해 만족시키는 거싱라고 볼 수 있다.

비록 개발의 후반부일지라도 요구사항 변경을 환영하고 변경에 유연하게 대처하는 것이다. 당신이 사업계획을 한다고 했을때 모든것이 계획서대로 순탄하게 흘러간다면 모두가 사업가를 했을 것이다.

그렇지 않다. 당신의 조사가 틀렸을 수도 있고, 시장이 변화할 수도 있기 때문이다. 그렇기에 우리가 요즘세대에 갖춰야할 스탠스는 바로 유연함이다. 사업 뿐만 아니라 공부든 학습이든 전략을 세울때 변화에 대응하는 유연성이 존재하지 않는다면 바로 깨지게 되어있다.

내가 계획이나 전략을 짤 때 타협은 무조건 존재할 것이다. 하지만 타협은 어떤 상황을 전제하고 그 전제 안에서만 성립되는 것인데, 전제가 깨지게 된다면 모든것이 무너지게 될 것이다.

유연함의 강함은 여기서 나온다. 전제가 아무리 깨지더라도 그에 맞춰 전략을 새로 수립하거나 변경할 수 있다. 소프트웨어적으로 더 들어가 보면 작동하는 소프트웨어를 고객에게 맞춰 다시 작동하게 만들어 만족시켜야 한다.

비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해 고객의 반응에 맞춘 소프트웨어를 개발해나가야 한다. 동기부여된 개인들을 중심으로 프로젝트를 구성하고 그들이 필요한 환경 자원을 주고 일하게 하고 신뢰해야한다.

개발팀 #

개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법이 무엇이라고 생각하는가?

dm? 어떠한 프레임워크? 문서화? 아니다 바로 면대면 대화다. PR을 올리고 그 글을 읽고 코드를 분석해 리뷰를 남긴다. pr 내용에 어떤 부분을 중점적으로 봐달라고 요청을 해도 직접 면대면으로 한 화면을 바라보며 대화하는 것보다 강한 효과를 낼 순 없다.

물론 모든 상황에서 면대면 대화를 하기가 힘들기에 우리는 이런 개발 프로세스들을 사용하지만 가능하다면 최대한 면대면을 자주 활용해 보아라. 전제상황을 전파시키기 가장 좋은 방법이 면대면이기 때문이다.

그리고 어떤 생산성 툴을 쓰려고 억지로 적응시키지마라, 개발팀에선 화이트보드만 있어도 어떤 요구사항이든 개발하고 전달할 수 있다. 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높힌다.

단순해야 한다. 파레토의 법칙으로 내가한 20이 전체 영향의 80을 미치도록 하는 선택들을 반복해야한다. 100점짜리 코드를 간헐적으로 뱉기보단 80점 짜리 코드를 꾸준하게 뱉는것이 중요하다. 단순하며 기민하고 빠르게 반영해야 한다.

최고의 아키텍처, 요구사항, 설계는 조직적인 팀에서 창발한다고, 다른 조직에서 좋더라도 팀 내에서 좋다고 생각하지 못한다면 도입하지 않는것이 좋다. 억지로 사용하게 된다면 생산력과 도입비용 두배로 깨지게 되는것이다.

단순해도 괜찮다. 단순하면 혹은 모던하지 않으면 뒤처지고 생산성이 떨어질거라는 생각을 할 수 있다. 당연한것이다 왜냐면 난이도가 쉬우면 가치가 없을거라고 판단하는게 인간의 특성이기 때문이다. 그렇지않다. 적어도 그렇게 걱정할 시간에 단순하게 하다가 막히는 부분이 더 있지는 않는가 찾아보아라 그부분이 새로운 변화가 필요한 시점일테니 말이다.