티스토리 뷰

반응형

Photo by David Travis on Unsplash

 

클린 애자일 4장은 실천 방법을 다루고 있다 실천 방법은 팀원들 사이의 관계, 그리고 팀원과 제품 사이의 관계 대한 것이다 제프리즈의 삶의 순환(Circle of Life) 그림을 다시 보자. 가운데 원이 실천 방법이다.

 

 

 

<이미지 출처: https://blog.ynkb.xyz/89/ >

 

실천 방법 다음과 같다.

 

- 메타포(Metaphor): 프로젝트와 관련이 있는 모든 사람들이 공감하고 이해하며 사용할 있는 개념과 언어가 필요하다.

- 지속 가능한 속도(Sustainable Pace): 단숨에 해치우려 하기보다 꾸준한 페이스로 개발할 있어야 한다. 개발은 마라톤이다.

- 공동 소유(Collective Ownership): 팀원들은 모든 코드를 다루고 이해할 있어야 한다.

- 지속적 통합(Continuous Integration): 계속 머지하면서 다른 팀원의 머지에 나쁜 영향을 끼쳐서는 안되는 것이다.

- 그리고 덧붙여 스탠드업 미팅(Stand-up Meeting): 짧은, 최소한의 팀원간 상황 공유

 

이제 가지 방법 + 1 하나씩 들여다보자.

 

메타포(Metaphor)

책에서는 프로젝트의 기능, 동작의 특성을 공장 조립 라인, 요리, 쓰레기차 등으로 비유(메타포)했다.

이런 개념을 팀원들이 공유하여 누군가가 반죽이라는 표현을 쓰면 무얼 말하는지 다들 이해하게 되는 것이다.

 

도메인 주도 설계(DDD, Domain-Driven Design)에서 제대로인 표현이 나왔다. 유비쿼터스 언어(Ubiquitous Language), 모든 사람들이 공유하고 이해하는 언더

 

"도메인 주도 설계에서는 해결하려는 문제 도메인의 모델을 모든 사람이 동의하는 어휘로 표현해야 한다. 여기서 모든 사람은 프로그래머, QA, 관리자, 고객, 사용자를 모두 포함한다." 114p

 

지속 가능한 속도(Sustainable Pace)

"나는 소프트웨어 프로젝트가 단거리 경주가 아니라 마라톤이라는 것을 배웠다. 좋은 성적을 내려면 자신에게 맞는 속도를 찾아야 한다." 117p

 

언듯 고리타분한 이야기같기도 하고, 편으로는 사람마다 성향이 다르지 않나 생각할 수도 있겠다. 하지만 나는 문장을 곰곰이 씹어보고 싶다. 로버트 마틴이 이렇게 이야기 한다면 상당한 수준으로 일반화를 해도 괜찮을지 모른다. 개발자라면 자신만의 페이스를 알아내서 꾸준히, 계획한 만큼 예측 가능하게 개발해 나가야 하는 것이다.

 

공동 소유(Collective Ownership)

"애자일 프로젝트에서는 아무도 코드를 소유하지 않는다. 코드는 전체 팀이 소유한다. 팀 구성원 누구나, 언제든지, 프로젝트의 어느 모듈이든 체크아웃해서 개선할 수 있다. 팀 전체가 코드를 공동으로 소유한다." 119p

 

"공동 소유를 실천하면, 지식이 팀 전체에 퍼진다. 팀 구성원 모두가 모듈 사이의 경계나 전반적인 시스템 동작을 더 잘 이해하게 된다. 그 결과, 팀 내 의사소통이 훨씬 원활하게 이루어지고, 더 좋은 결정을 내릴 수 있게 된다." 121p

 

실천 방법은 관계에 대한 것이라 하였다. 팀원들간의 관계, 그리고 팀원과 제품 사이의 관계. 인용한 문장에서 살을 붙일 것이 없다. 관계가 좋아진다그런데 실무적 입장에서는 궁금한 지점이 있기는 하다. 팀이 백엔드와 프론트엔드로 이루어져 있다면? DBA 있다면

 

지속적 통합(Continuous Integration)

"(개발한 코드는 지속적으로 주 브랜치에 머지하여야 하며) 모든 단위 테스트와 인수 테스트는 계속 통과해야 한다. 기능 브랜치가 통합되지 않은채 남아 있어서는 안 된다. 배포할 때 동작하면 안 되는 기능은 토글로 비활성화 시켜야 한다." 123p

 

"지속적 빌드는 절대 깨지지 않아야 한다." 125p

 

가능한 자주 브랜치로 머지를 해야 하고, 머지한 코드가 자동으로 빌드되고, 단위 테스트, 인수 테스트를 통과하여 언제든 릴리즈하거나 고객에게 전달 있어야 하는 것이다. 빌드가 깨진다는 것은 상상할 수도 없는 일인 것이라고 생각하자. 

스탠드업 미팅(Stand-up Meeting)

개발자들에게 많은 오해가 쌓여있다는 판단에, 로버트 마틴이 생각하는 스탠드업 미팅을 간결하게 이야기해 두었다.

 

- 한두 명쯤 빠져도 되고, 매일 필요도 없다. -> 엄격하게 생각하지 말고 주기적으로 가볍게 소통하는 시간이라 생각하자

- 사람에 30, 전체 10분이 넘어선 안된다. -> 묻고 답하고 따지지 말자

- 사람은 다음 가지 + a 하면 된다.

    1) 지난 스탠드업 미팅이후 지금까지

    2) 다음 스탠드업 미팅까지

    3) 장애물

    4) 그리고 만약 언급하고 싶다면 감사인사

 

메타포, 지속가능한 속도, 공동 소유, 지속적 통합, 그리고 스탠드업 미팅 모두가 머리에서 이야기했던 대로

팀원들간의 관계, 팀원과 제품간의 관계에 윤활유 역할을 한다는 것이 느껴지는가? 느껴져야 한다.

 

비즈니스 실천 방법에 이어, 팀 실천 방법을 정리해 보았다. 다음 포스팅에는 마지막 기술 실천 방법을 정리해 보겠다. 

반응형
댓글
댓글쓰기 폼