본문 바로가기

IT

[Agile] 애자일 적용 우선순위


우선 본 포스팅을 게시함에 앞서,

본 포스팅은 지극히 개인적인 의견임을 알려드립니다.


프로젝트에 애자일을 도입할 때,

애자일의 지엽적인 부분만 도입해놓고 제대로 적용했다고 주장하는,

우스꽝스러운 상황을 보고 싶지 않기에,

지극히 주관적인 관점에서 우선순위를 지정해보았습니다.


< 우선순위 上 >

- 프로젝트 라이프사이클

프로젝트의 라이프사이클 내내 요구수집, 제품디자인, 기술훈련, 개발활동 그리고 검증절차 모두가 지속되어야 합니다.

요구수집을 초반에 진행하고,

검증절차는 과제 막바지에 진행하는 단계별 절차관리는 애자일이 아닙니다.

요구사항은 언제든지 바뀔 수 있기에 아키텍쳐는 언제든지 재설계되어야 합니다.


- 반복주기와 피드백

프로젝트 라이프사이클 중에는 일정 기간이 되풀이되는 반복주기가 있습니다.

하나의 반복주기에는 제품개발을 위한 모든 활동을 포괄합니다.

제품 디자인부터 구현과 검증까지 하나의 반복주기에 수행됩니다.

각 반복주기의 끝은 과제 관련인들이 모여 피드백을 합니다.

피드백은 다음 반복주기에 다뤄질 수 있겠죠.


- 프로젝트 구성원

프로젝트를 진행할 때 필요한 모든 사람이 프로젝트 구성원이 될 수 있습니다.

개발자들로만 이뤄진 프로젝트일 필요는 없습니다.

디자이너와 테스터 혹은 상품기획자나 검증자도 함께할 수 있습니다.

소프트웨어 업계에서 분업이 각자 따로 일한다는 것을 의미하지 않습니다.

어느 정도 서로의 역할분담은 정해져 있지만,

역할경계를 초월하여 문제를 바라봐야 좋은 아이디어가 나올 수 있습니다.


- 프로젝트 의사결정권

프로젝트에서 다뤄지는 수많은 요구사항들에 대한 우선순위를 정하는 주체는,

프로젝트에 직접적으로 참여하는 디자이너 + 개발자가 되어야합니다.

디자인은 디자이너에게 위임하고,

개발은 개발자에게 위임해야 합니다.

프로젝트에 직접 참여하지 않은 사람이 프로젝트의 세부사항에 대해 의사결정을 하는 것은,

때로는 굉장히 위험해보이기까지 합니다.


< 우선순위 中 >

- 백로그 관리

자신이 수행해야하는 작업은 백로그로 관리해야 합니다.

백로그에는 우선순위, 작업예측시간, 실제소요시간 등이 기입되겠지요.

백로그에 기입된 작업들은 철저히 우선순위에 따라 진행되기 때문에,

무분별한 컨텍스트 스위칭으로 인한 업무방해를 근본적으로 배제할 수 있습니다.

작업시간 예측은 지속적인 예측행위를 통해 점차 정밀한 시간예측 축으로 수렴할 겁니다.

사전예측을 통해 업무분담이나 일정을 잡아야 하기 때문에,

예측을 하는 훈련을 계속할 필요가 있습니다.


- 간소한 설계

소프트웨어 업계에서 완벽한 설계가 있는지 모르겠습니다.

요구사항이 빈번하게 바뀌기에 매번 완벽한 설계를 유지하는 것도 상당한 시간이 소요됩니다.

설계는 바로 코드로 치환이 가능할 정도로 자세할 필요가 없습니다.

세부사항은 코드를 짜며 확정해도 무방합니다.

설계는 프로그램의 방향을 결정짓고 정책을 확정하는 정도로 진행하여 시간소모를 줄여야 합니다.


- 트레이드오프의 이해

모든 조건을 만족하는 완벽한 해결책은 보기 힘듭니다.

대부분의 경우 하나를 얻으면 다른걸 놓치게 됩니다.

모두를 취하는 묘수는 인생의 은사를 만나는 것만큼 힘듭니다. :)

성능, 비용, 소요시간, 일정, 개발편의 등 수많은 요소가 상충하기 때문에,

한계효용이 가장 높은 요소를 택하여 기회비용을 가급적 낮춰야합니다.

별로 중요하지 않은 요소를 지키고자 무리하게 다른 요소를 희생하는 경우가 있는데요,

그런 부류의 사람들과 함께 개발하는 것은 참 곤욕입니다.


- 독해우선의 코딩

코딩을 하면 코드 최적화를 위해 수많은 테크닉을 사용하는 경우가 있습니다.

하지만, 코드 최적화보다는 코드를 쉽게 독해할 수 있게 짜야합니다.

자기 혼자만의 코드라 할지라도,

코드독해에 노력과 시간이 소요된다면 코드 재활용성 측면에서 좋지 않습니다.

과거 몇 년전만 하더라도 최적화 테크닉을 신봉하던 때가 있었는데요,

이제는 기계를 위한 코드보다 인간을 위한 코드로 무게중심이 바뀌었습니다.


- 코드통합

코딩은 지속적으로 메인 스트림에 통합되어야합니다.

통합주기가 길어지면 통합을 위한 비용도 증가하게 됩니다.

작업할 내용이 많다면,

작업을 몇가지 단계로 쪼개어 단위작업별로 통합할 수 있게 관리해야합니다.


- 단위테스트

프레임워크 개발자들은 코드를 수정하면 반드시 단위테스트를 해야합니다.

단위테스트 없이 수정사항을 통합하면,

문제가 발생하여 다른 개발자의 시간을 소모할 수 있습니다.

매번 단위테스트를 하느라 수 분을 버리는게 아깝다면,

자신의 실수로 인해 다른 수많은 개발자의 몇 시간을 소모한다고 생각해주세요.


- 이슈추적

발생한 이슈는 반드시 관리되어야 합니다.

이슈라는게 유사한 형태로 끊임없이 되풀이되는 특징이 있습니다.

문제발생일, 문제에 대한 묘사, 해결책에 대한 상세한 설명, 관련 코드나 문서를 정리해놓으면,

반드시 재사용하여 빛을 볼 날이 올 겁니다.

소극적으로 경험을 쌓는 것 뿐만 아니라,

적극적으로 경험을 되새길 수 있도록 약간의 노력을 가미하면,

좀 더 기민하게 문제에 대응할 수 있게 됩니다.


< 우선순위 下 >

- 멘토되기

훌륭한 멘토는 좋은 질문을 멘티에게 던져,

멘티가 스스로 답을 찾을 수 있게 도와준다고 하는데요.

이것도 상황을 봐가면서 해야합니다.

프로젝트에는 일정이 있고 개발자의 수준은 천차만별이기 때문에

직접 답을 보여주고 왜 그게 답인지 직설적으로 설명해야하는 경우도 있습니다.

이슈가 터져서 수 분 혹은 수 시간 내에 해결을 해야 하는데,

구글링의 키워드를 알려주는 것은 때로는 너무 잔혹한 행동입니다.


- 짝 프로그래밍

두 사람이 함께 코딩을 하는 것은 굉장한 즐거움입니다.

키보드를 잡고 있는 사람이 놓친 부분은 관전하는 사람에게 발견됩니다.

짝 프로그래밍을 하면 별도의 코드리뷰가 필요없어집니다.

코딩을 하는 순간 리뷰가 되니까요.

짝 프로그래밍은 혼자 코딩하는 것보다 효율이 좋고,

모듈의 전문가를 다수 양성할 수 있다는 측면에서 널리 유포하고 싶습니다.


- '왜'인지 질문하기

'무엇'에 대한 질문도 필요하지만,

'왜'에 대한 질문도 꼭 필요합니다.

코드로 확정된 사실을 살펴볼 수는 있지만,

행간에 놓인 존재이유는 코드만 가지고 파악하기가 쉽지 않습니다.

끊임없는 질문으로 스스로 납득하고,

더 나아가 다른 개발자도 납득시킬 수 있는 코드를 만들어야 합니다.


- 신기술에 대한 태도

프로젝트에 새로운 기술을 적용해야하는 시점이 있습니다.

이때는 직접 프로토타이핑을 진행하여 신기술의 구현정도와 구현상태를 확인해야합니다.

제대로 프로토타이핑을 진행하지 않은 상태에서,

무턱대로 신기술을 탑재한다면,

해당 기술을 적용할 개발자들의 시간만 낭비하는 셈이 되겠지요.


- 간이세미나

개발자간의 끊임없는 교육활동의 일환으로,

한주에 한두번 간단한 세미나를 통해 정보를 공유해야 합니다.

발표는 10~15분 정도 간단하게 진행하고,

프로제트와 세미나 주제간의 연결고리를 찾아 토의를 진행하면 좋겠지요.

발표를 준비하는 사람이나 발표를 듣는 사람이나 모두가 발전할 수 있는 기회가 될 겁니다.


- 실수의 인정

숙련된 프로개발자도 연중 행사로 간혹 실수를 하곤 합니다.

일반개발자들이야 그보다 더 자주 더 많은 실수를 쏟아내곤 하지요.

하지만, 개발자 스스로가 자신이 실수를 인정하고,

자신의 실수로 파생된 문제에 대해 다른 개발자에게 사과하는 것은 거의 본 적이 없습니다.

자신으로 다른 사람이 피해를 봤는데 사과를 하지 않더라고요.

자신의 실수에 대해 용기있게 사과하는 것은 당연한 행동입니다.

결국 감정에 영향을 받는 인간사회이기 때문에,

서로간에 불필요한 감정소모는 최대한 줄여야 합니다.


- 버그유발자 색출금지

사람은 누구나 실수를 합니다.

실수를 한 사람을 찾아 책임을 묻고 비난을 하는 것은 별로 좋은 방법이 아닙니다.

문제를 찾으면 문제를 해결하기 위해 에너지를 쏟아야하지,

그 외의 불필요한 감정소모는 최대한 억제해야 합니다.

경험상 비난은 접고 문제만 올곧이 바라봐야 팀원간의 결속도 단단해집니다.


지극히 개인적인 생각의 나열이라,

애자일의 다른 중요한 요소가 빠졌을 수도 있습니다.

빠진 부분은 틈나는대로 보강하려 합니다.


그럼 좋은 하루 보내세요~

끝_