애자일 시작하기

어떠한 방법론에선 하나의 프로젝트를 하기 위해 약 서른가지 이상의 구분된 역할을 수행하는게 필요하다고 제시합니다.

하지만 애자일에선 소프트웨어 개발자. 단 한 가지 역할만 합니다. (지나치게 '사람' 에 의존하는 것 같기도 합니다)

 

피드백은 애자일의 근간입니다. 일이 잘못된 방향으로 가고 있다는 것을 깨닫자마자 변화시켜야 하며, 때로는 과감히 비난하고 앞으로 나아갈 용기도 필요합니다.

 

애자일은 결국 소프트웨어 개발자가 프로다운 태도를 수용할 때만 작용합니다.

 

- 결과를 위해 일하라

 

일을 함에 있어 범인을 찾는 것 보다는 문제를 고치는 일을 최우선으로 삼아야 합니다. (그러지 못하는 경우를 많이 봤습니다..)

비난을 하는 대신 문제를 해결하는데 집중해야 합니다.

 

• 비난은 버그를 수정하지 못한다

 

감정적으로 일하는 사람들과 일하거나 본인이 그렇게 한다면, 그 팀의 생산성은 매우 낮습니다.

애자일 팀원들은 명확한 동기, 즉 결과를 위해 문제를 해결하려고 노력할 것입니다.

 

• 프로세스 준수가 결과는 아니다

 

간혹 프로젝트를 진행할 때 프로세스를 얼마나 잘 따라서 했는지 측정하고 평가하는데 집중하는 경우가 있습니다.

애자일에선, 프로세스를 얼마나 잘 따르는지 재는 것은 결과를 측정하는 것이 아닙니다.

 

• 팀이란 함께 일하는 것

 

손가락질 하는 대신 가능한 해결책을 제시하는데 집중해야 합니다. 본인을 포함해 팀원 누구도 실수하지 않는다면, 너무나도 능력이 뛰어나다 라고 해석할 수도 있지만 대체로 충분히 열심히 일하지 않는 것입니다.

간혹 한 팀원이 반복해서 잘못된 행동으로 팀에 해를 끼친다면, 또는 팀이 해결책으로 나갈 수 없도록 한다면, 팀에서 제외하는 방법도 고려해야 합니다. 만약 모두가 그렇다면, 본인이 나와야겠네요.

 

- 땜질은 늪을 만든다

 

보통 시간의 압박이 있는 프로젝트를 진행할 때, 쉬운 길로 타협하는 경우가 있습니다. 시간이 촉박하다면 충분히 선택할 수 있는 부분입니다만, 그 다음 스텝에서 좋은 프로그래머와 나쁜 프로그래머를 구분합니다.

나쁜 프로그래머는 코드를 그대로 남겨 두고 다음 문제로 재빨리 넘어가지만, 좋은 프로그래머는 다음 단계로 가서 이 부분의 수정이 왜 필요한지, 다른 무언가가 영향을 받는지 이해하려고 노력합니다.

 

나쁜 프로그래머가 하는 근본적 내재된 문제를 무시한 땜질식 수정은 결국 프로젝트의 생명을 위협하게 됩니다.

 

• 지뢰를 조심하라

 

땜질식 수정은 코드에 들어가자마자 코드의 명료함이 떨어지고, 땜질식 수정이 많이 쌓이면 코드의 명백함은 사라지고 불투명성이 두드러집니다. 수많은 땜질식 수정의 짐을 지고는 애자일할 수 없습니다.

 

• 따로 코딩하지 말라

 

개발자들이 따로 코딩하는, 고립은 위험합니다. 코드는 서로 자주 읽을수록 더 나아지고, 지속적인 코드 리뷰는 코드를 이해하는데 도움이 될 뿐 아니라 버그를 찾아내는데 가장 효과적인 방법 중 하나입니다.

 

• 단위 테스트를 사용하라

 

코드가 불명료해지는 일을 막는 또 하나의 주요 기법은 단위 테스트입니다. 단위 테스트로 인해 코드는 더 작고 더 이해하기 쉬운 모듈로 보여질 수 있으며, 단위 테스트는 코드와 함께 실행하고 작업하기 때문에 코드를 철저히 이해하게 해줍니다.

이렇게 작성된 단위 테스트는 문서를 대체할 수도 있게 됩니다.

 

격리된 코드는 존재하지 않습니다. 코드의 모든 세부 내용이나 모든 알고리즘의 전체 단계를 모를 순 있지만, 일반적인 동작에 대해서는 잘 알아야 합니다.

 

간혹 코드에 본인만의 스타일을 너무 녹여내거나, 추상화가 과하거나, 본인 머릿속 생각을 그대로 코드에 옮겨 복잡한 케이스가 있습니다. 동작에는 문제 없을 수 있지만, 팀원 가운데 한 사람이라도 코드가 어렵다고 한다면 결국 그 코드는 유지 보수하기가 힘들어 질 수 있습니다. 가능하면 단순한게 좋습니다.

 

- 사람이 아니라 생각을 비판하라

 

• 개인 감정을 드러내지 말고, 프로다운 자세를 유지하자

 

사실 개발자도 사람이라 어려운 말이긴 합니다. (저도 가끔씩은 특정 상황에서의 감정 컨트롤이 어렵다고 느낍니다..)

감정을 드러내지 않고 사람에 대한 비판, 상황에 대한 본인만의 판단을 제거하면 단순한 명료함만이 남게 됩니다.

질문은 논쟁이 아닌 대화를 시작하게끔 되어야 합니다. (결국 이러한 부분들은 개인의 인성이 중요하단 소리 같기도 합니다)

 

• 부정적인 생각은 혁신을 죽인다

 

모두에겐 좋은 아이디어도 있고 나쁜 아이디어도 있습니다. 팀의 모든 사람은 아이디어를 자유롭게 표현할 수 있어야 합니다.

스스로도 비판 받는 것을 두려워하지 말아야 합니다.

 

• 마감을 정하라

 

변하지 않는 마감 같은 시간 제한은 팀이 계속 활동하게 만들며 끝없는 이데올로기적 논쟁에 메달리지 않게 합니다.

확고한 마감을 정하면 확고한 선택을 할 수 있게 해줍니다.

 

• 상대방과 논의하라

 

팀의 멤버들은 항상 트레이드오프가 있다는 것을 깨달아야 합니다.

상반되는 관점을 갖는 목적은 장점이 가장 많으면서 단점은 적은 해결책을 고르는 것이고, 이것은 가능한 많은 장단점을 모으기 위한 좋은 방법입니다.

 

• 결정을 지원하라

 

일단 해결책이 선택되면 각 팀원은 준비를 하고 구현이 될 때까지 완벽하게 협력해야 합니다.

팀이 몇 가지 해결책 후보들의 진정한 장점과 있을지 모르는 단점들에 대해 토의할 때 편안해야 하며, 때로는 일부 해결책을 거절할 수 있어야 합니다.

 

본인의 생각을 관철시키기 위해 쓸데없는 군더더기를 넣어선 안됩니다. 생각을 넣거나, 혹은 반박하기 위해 프로토타입을 만들어야 한다면 그렇게 해야 합니다.

최선의 해결책을 찾으려고 하기 전에 모두가 이 맥락에서 최선이란 무엇인가에 동의하는지를 확인하는 편이 좋습니다.

사실 절대적인 최선은 없습니다. 더 나은 것 만이 있을 뿐입니다.

 

- 위험을 무릅쓰고 앞으로 나아가라

 

좀 오글거리는 멘트긴 합니다만, 때로는 최선의 계획이라도 실행할 용기가 없다면 실패합니다. 위험을 무릅쓰고 돌진해서 옳은 일을 해야 합니다.

 

코드를 이해하기 어려워서 작업이 힘들다면, 코드를 가지고 계속 작업하는 일과 아예 코드를 다시 만드는 일 사이의 장단점을 제시해야 합니다. 모두가 현재 상황을 판단하고 올바른 해결책에 도달하도록 이유를 제시해야 합니다.

 

설계나 코드가 이상하다는 생각이 들면, 코드가 왜 그런지 이해할 시간을 우선 가집니다. 처음 볼땐 이거 왜이래? 싶던 코드들도 보다보면 어쩔수없는 상황에 의한 것이구나 라고 이해될 때가 있습니다. 단지 당장 이해 안된다고 기존 코드를 거부하고 새로 만드는 건, 용기가 아니라 인내심이 없다고 할 수 있습니다.

 

 

출처 : 애자일 프랙티스(책)