본문 바로가기

소프트웨어 개발방법론/애자일 방법론

애자일 기르기

애자일은 자신을 변화에 적응시켜 유지해나갈 것을 요구합니다.

이것은 계속해서 변화하고 진화하는 분야인 소프트웨어에서 특히 프로그래머에게 맞는 말입니다.

 

대부분의 신기술들은 기존의 기술이나 아이디어에 의존합니다.

새로운 내용을 다루는 일은 단지 점진적인 변화를 인지하느냐의 문제이지만, 계속 따라가지 못하면 기술 변화는 갑작스럽고 극복하기 힘들어 보입니다.

 

새로운 기술과 접근 방법을 배우는 일도 중요하지만, 때로는 오래된 구식의 접근 방법을 버리는 일도 필요합니다.

또한 잘 이해하지 못하는 사실들은 계속해서 알려고 하는 태도가 있어야 할 것입니다.

 

- 변화에 뒤처지지 말라

 

기술의 발전 속도는 상당히 빠릅니다. Java 를 예로 든다면, Swing, servelts, JSP, struts, JSF, JDBC, JDO, Hibernate, JMS, EJB, Lucene, Spring 등 영어 약자가 모자랄 지경입니다.

개발자는 당장 업무를 하는데 필요한 기술을 가진 것으로는 더 이상 충분하지 않습니다.

그렇다면 기술 발전의 속도에 어떻게 맞출 것인가? 이 포인트가 중요할 수 있습니다.

 

• 반복해서 조금씩 배우자

 

신기술을 따라잡는 데 매일 일정 시간을 확보해서, 길 필요는 없지만 규칙적으로 활용하는 편이 좋습니다.

 

• 최신 소식을 얻자

 

웹에는 새로운 기술에 대해 배울만한 방대한 자료가 있습니다. 사람들이 발견한 멋진 솔루션이나 그들이 겪는 문제점에 대해 최신 동향을 얻기 위해서 포럼의 토론을 읽거나 구독하고, 자료가 풍부한 기술 블로그를 골라서 규칙적으로 읽는 것이 도움 됩니다.

 

• 워크숍이나 학회에 참석하자

 

이런 모임은 전문가에게 직접 배울 수 있는 좋은 기회가 될 수 있습니다.

 

모든 분야에서 전문가가 될 필요는 없지만, 업계가 어디로 가는지 알고 있어야 하고 그러한 기술이 소개되고 적용되는 때를 알아야 합니다.

만약 새로운 기술 분야로 직업을 바꿔야 한다면, 그렇게 바꿀 수도 있어야 합니다.

 

저의 경우에도 현재는 코로나 상황인만큼 오프라인 컨퍼런스 등에는 참여하기 힘들지만, 온라인 컨퍼런스를 통해서 최근의 기술 흐름에 대해 파악하는 편입니다. 또한 페이스북과 같은 소셜 네트워크에서 특정 기술에 대한 사용자 모임이나 IT 업계에 대한 글들을 자주 접하는데, 이러한 부분이 기술 변화를 따라 가는데 꽤 도움이 되는 것 같습니다.

 

- 팀에 투자하라

 

팀에는 다양한 능력과 경험과 기량을 가진 개발자가 있고, 사람마다 역량과 전문 분야가 다릅니다.

이러한 재주와 배경이 다양하게 조합되어 학습하기에 이상적인 환경이 탄생합니다.

 

팀에서 본인 혼자 많이 아는 것으로는 충분하지 않습니다. 다른 팀원이 많이 알고 있지 않다면, 본인 그리고 팀으로서 효율이 떨어집니다.

교육이 잘 된 팀일수록 더 좋은 팀입니다.

 

프로젝트를 수행할 때 설계한 개념과 그 의도를 명확히 전달하기 위해 다양한 용어와 메타포를 사용해야 합니다.

팀원 다수가 이런 아이디어에 친숙하지 않다면 스스로도 효율적이기 힘듭니다.

 

'도시락 회의' 라는 형태는 팀에서 지식을 공유하는 훌륭한 방법입니다. 모두에게 똑같이 흘러갈 수 있는 점심시간을 활용하여 매주 팀원 중 한 명에게 토의를 이끌게 합니다. 뭐든지 도움이 될 만한 것, 토의 주제를 열어 모두가 자신의 아이디어를 제안하고 프로젝트에 해당 주제가 어떻게 연관되는지 토의해 이점을 논의하고 여러 계획을 세울 수 있습니다.

 

위와 같은 것들을 통해 본인과 팀에 대한 기대치를 높여나갈 수 있습니다.

때로는 이런 말도 있습니다. 본인이 팀에서 최고라면, 스스로에게 투자를 계속할만한 동기를 얻지 못한다. 주위 사람들이 모두 본인보다 낫다면, 그 사람들을 따라잡겠다는 매우 큰 동기가 생길 것이고 그리하여 자신의 분야에서 최고가 될 것이다.

이 말에 100% 동의하지는 않지만 팀에 본인보다 나은 개발자가 많을수록 많은 도움과 배움이 있는 것은 확실합니다.

본인이 팀에서 최고라면 그 점을 활용해 팀 전체의 가치를 높여나갈 수도 있겠지만, 대체로 이건 어렵기도 하고 그런 사람들은 결국 이직을 통해 본인이 최고가 아닌 팀을 찾아 나서기도 하는 것 같습니다.

 

- 버려야 할 때가 언제인지 알자

 

애자일의 기초 중 하나는 변화에 익숙해지는 것입니다. 더 나아가 '버릴' 필요성도 생각해야 합니다.

아주 옛날에는 프로그래밍에서 메모리 오버레이가 큰 문제였고, 때로는 메인 메모리에 전체 프로그램을 맞출 수 없어 프로그램을 나눠야 했습니다. 한 부분에서 다른 부분의 함수를 부를 수 없는 문제가 빈번했죠.

컴파일러의 어셈블리 언어 출력을 수작업으로 튜닝해 프로세서로부터 부가 사이클을 뽑아내기 위해 많은 노력을 하기도 했습니다.

 

하지만 위와 같은 문제점과 노력들은, 지금의 환경에선 일어나는 일이 거의 없습니다.

대부분의 비즈니스 어플리케이션에서 기술의 엄청난 변화 때문에 제한된 메모리, 수동 오버레이, 수작업으로 튜닝한 어셈블리 언어같은 것은 생각할 수도 없게 되었습니다.

 

이제는 기계와 CPU 사이클이 비싸던 시절과 달리 개발자의 시간이야말로 부족하고 비싼 자원이 되었습니다.

버린다라는 것은 어렵지만, 새로운 기술을 배우려고 접근할 때 너무 낡은 태도를 취하는 게 아닌지 스스로에게 물어봐야 합니다.

예를 들어 Java 에서 C 코드 형식으로 작성하는 것과 같은 태도는, 오점을 남기기 쉽습니다.

 

• 대가를 많이 치른 사고방식은 쉽게 버릴 수 없다

 

오래된 습관은 바꾸기 힘들뿐 아니라 습관 자체를 깨닫는 것 조차 어렵습니다. 그리고 사실 오래된 습관을 완전히 버리려고도 하지 않습니다.

우리는 오래된 습관을 단지 습관적으로 끌지 말고, 예전 지식을 쓸 수 있는 상황에서 그 지식을 다시 활용해 개발을 하는 방식을 취해야 합니다.

 

새로운 개발 환경으로 바꾸려고 할 땐 가능한 확실히 하는게 좋습니다.

예를 들어 새로운 프로그래밍 언어를 배울 땐, 낡은 개발 환경에 플러그인을 쓰는 대신 새 언어와 같이 나온 새 개발 환경을 사용하는 것이 좋습니다. 물론 IDE 와 같은 경우엔 요즘 워낙 잘 통합되어있다보니, 조금 논외긴 한 것 같습니다.

 

- 이해할 때까지 질문하라

 

문제를 빨리 파악해야 한다는 압력을 받으면 괜히 겁을 먹어 이슈가 되고 있는 내용에 대해 충분히 물어보지 못할 수도 있습니다.

하지만 컴퓨터상에서, 많은 이슈가 어플리케이션에 영향을 줄 수 있고 문제를 해결하기 위해선 많은 요인을 알아야 합니다.

연관이 있다고 생각한다면, 더 계속해서 묻거나 얘기해야 합니다.

 

저도 대체로 지금의 팀에서, 여러 가지 이슈를 해결함에 있어 계속해 의문을 제기하거나, 다른 포인트를 얘기하곤 합니다.

그 과정에선 의미없는 물음인 것들도 있지만, 다른 사람이 생각하지 못했던 부분에 대해 끄집어낼 수 있는 기회가 되곤 합니다.

 

시스템을 많이 파악하고 있는 사람이어도, 때로는 여러 가지를 놓칠 수 있습니다.

개발자 개개인의 서로 다른 관점과 질문으로 인해 다른 사람들이 새로운 시야를 얻고 고민하던 문제에 대한 답을 찾을 수 있습니다.

'왜 그래요?' 라는 것은 아주 훌륭한 질문입니다.

'모르겠는데..' 라는 말도 경우에 따라선 얘기의 끝이 아닌, 새로운 탐구의 출발점이 될 수 있습니다.

(물론 대부분의 경우엔 맥이 빠지는 말로 들리긴 합니다..)

 

- 리듬을 느껴라

 

애자일 프로젝트에는 리듬과 주기가 있습니다.

예를 들어 스크럼 같은 경우 30일 스프린트동안 요구사항 변화로부터 팀을 보호합니다. (스프린트는 개발, 마무리, 리뷰 및 수정으로 구성)

애자일 프로젝트에선, 모든 일이 한꺼번에 혹은 예상할 수 없게 발생하지 않도록 할 필요가 있습니다.

 

• 타임 박싱

 

많은 애자일 기법이 타임 박싱에 의존하는데, 타임 박싱이란 연장할 수 없는 활동에 대해 확고하고 짧은 마감을 정하는 것 입니다.

마감을 정함으로써 어떤 면에서는 손해를 볼 수 있지만, 명확한 목표를 성취하게 합니다.

확고한 마감이 확고한 선택을 불러 일으킵니다. 즉 타임 박싱은, 앞으로 나아가게 만듭니다.

 

스탠드업 미팅 (정규 대면회의) 은 늘 항상 같은 시간과 장소에서 하는 것이 좋습니다.

지금 제가 속한 팀의 경우에도 매일 오후 2시반부터 30분씩, 스탠드업 미팅을 진행하고 있습니다.

이렇게 회의 하는 습관을 들이기 시작하면, 그 시점까지 회의에 필요한 모든 것을 확보하게 됩니다.

 

 

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

 

'소프트웨어 개발방법론 > 애자일 방법론' 카테고리의 다른 글

애자일 코딩  (0) 2021.05.29
애자일 피드백  (0) 2021.05.22
애자일에서 고객과의 협력  (0) 2021.05.15
애자일 시작하기  (0) 2021.05.01
애자일 소프트웨어 개발  (0) 2021.04.24