[업무] 애자일이 도대체 무엇인가?

애자일 책을 살짝 읽어보고 검색하고 글을 읽어 봐도 애자일을 쉽게 정의하기가 참 어렵다.

 

다시 읽는 책 "애자일 & 스크럼 프로젝트 관리" 리디 북스에서 사놓아서 급하게 읽을 때는 편하다.

다시 휘리릭 읽어 본다.

 

애자일 선언문

1. 프로세스와 도구보다는 개인과 개인 간의 상호작용에 더 큰 가치를 둔다.

(Individuals and interactions over processes and tools.)

-> 애자일이라는 이름을 따로 걸지 않아도, Communication이 안되는 순간 프로젝트는 망테크를 탄다.(몇 번 타봤다. 이후에 수습이 정말 어렵다.) 다양한 사람들 틈 사이에서 커뮤니케이션이 중요하다. 

 

2. 포괄적 문서화보다는 동작하는 소프트웨어에 더 큰 가치를 둔다.
(Working software over comprehensive documentation.)

-> 결국은 결과물이다. 문서화가 아무리 잘되어 있어도 제대로 수행하지 않았다면, 의미 없는 데이터에 불과 할 것이다.

 

3. 계약 협상보다는 고객과 협력에 더 큰 가치를 둔다.
(Customer collaboration over contract negotiation.)

-> 프로젝트 중간 단계에서, 계약건으로 고객과 충돌이 있었는데, 협력에 더 큰 가치를 둔다면 일정에 양해가 있어야할텐데. 현실은 일정은 일정이고 고객은 일방적인 경우가 많다. 이런경우에는 회사 차원의 대응이 필요하다.

4. 계획을 따르기보다는 변화에 대응하는 것에 더 큰 가치를 둔다.
(Responding to change over following a plan.)

-> 사실 계획에 따르는 것을 중요시 하다보니, 변화에 대응하는 순간 조율할 것이 매우 많아져, 수정이 불가능한 일정을 가지고 있었다. 고객과 사전 협의, 합의가 매우 중요하다. 그것이 안되는 순간 변화고 뭐고 계획대로 안된것에 대한 컴플레인이 이어진다.

 

 

애자일 소프트웨어 개발의 12가지 원칙

 

1. 소프트웨어 개발을 수행하는 최우선 목표는 빠르고 지속적으로 가치 있는 소프트웨어를 전달하여 고객을 만족시키는 것이다.

(Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.)

-> 고객 만족, 이게 포인트다 고객이 원하는 것을 해결해주고 요구 사항을 맞추어 주는것이 최선의 방향이다.

가끔, 고객님아가 이상한(?) 요구 사항을 말할때도 잘 설명할 수 있으면 좋다. 사업/영업 부서의 힘을 빌어보자.

 

2. 애자일 프로세스는 고객의 경쟁력을 위해서라면 비록 개발 후반일지라도 요구사항의 변경을 환영한다.

(Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.)

-> 원칙은 그럴지언데, 하기는 참 어렵다.

-> 예전에 일주일만에 SW 모듈 하나를 갈아엎었는데, 정말 쉽지 않았다. 하루만에 뚝딱 코딩하고 코드 리뷰 다른 분께 맡기고 동시에 진행해서 일주일간 테스트 돌리고 최종 SW 출시를 한 적이 있었는데, 왠만하면 후반에 요구 사항 변경하면 망하기 쉽다. 원칙이 그렇다는 거니까. 그런 마음자세로 하는 것이라고 믿고 싶다.

 

3. 동작하는 소프트웨어를 2주일에서 2개월까지 짧은 간격으로 자주 전달하라.

(Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.)

-> 기존에 하던 제품군은 HW가 있는 제품이라 SW 출시는 최종 단계에서 고객과 마주 한다. 다만, SW Stage를 두어 짧은 간격으로 반복을 했었다.

-> 이번 과제는 서버 모듈 배포가 너무 늦어 자주 전달할 수 없었다. 짧은 개발 기간 + 잦은 요구 사항 변경 + 커뮤니케이션 부재, 3단 콤보를 맞으면서 SW 퀄리티를 잡을 수 없게 되었다. 

 

4. 요구사항을 내는 고객과 개발자는 전체 프로젝트에서 매일 함께 일해야 한다.

(Business people and developers must work together daily throughout the project.)

-> 고객과 개발자가 매일 함께 일하려면? 자주 보는 수 밖에 없다. 예전에는 같은 사무실 옆켠에서 개발을 하던 시절도 있었다. 그때는 엄청 무지 매우 힘들고 불편했지만, 요구 사항 전달이 누락되거나 하는 일이 없었다. 요즘은 별도 건물에서 여러 업체가 입주 해 있는 경우가 많은데 그 경우에는 소통이 매우 어렵고 불통이 되기 쉽다.

 

5. 동기가 부여된 개인들 중심으로 프로젝트를 구성하고, 그들에게 필요한 환경과 지원을 제공하고, 일을 잘 끝낼 수 있도록 신뢰하라.

(Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.)

-> 이게 제일 힘든일, 새로 들어간 회사에서 동기가 부여된 개인들을 찾기가 어렵다. 회사에 오래 다니거나 사교성이 좋으면 가능하다.

 

6. 개발팀 내부에서 정보를 전하는 가장 효율적인 방법은 서로가 얼굴을 마주 보면서 대화하는 것이다.

(The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.)

-> 매우 동의하는 것, 전 직장에서는 매일 커피를 같이 마셨다.

 

7. 작동하는 소프트웨어는 진척의 주된 척도다.

(Working software is the primary measure of progress.)

-> 매우 동의하는 것, 열마디 말보다 한번의 동작을 보는게 맞다.

 

8. 애자일 프로세스는 지속 가능한 개발을 장려하며 스폰서, 개발자, 사용자는 일정한 개발 속도를 계속 유지해야 한다.

(Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.)

-> PM 이라면 잘 생각해야할 것이다. 일정한 템포를 유지하는 것, 생각의 속도는 더 빨라지지 않는다.

 

9. 기술적 탁월성과 좋은 설계에 갖는 지속적 관심이 민첩성을 높인다.

(Continuous attention to technical excellence and good design enhances agility.)

-> 지속적인 학습과 노력이 필요하다, 팀워크에 필요한 내용이기도하다.

 

10. 간단함, 즉 하지 않은 수행되지 않은 일의 양을 최대화하는 기술이 필수적이다. 

(Simplicity- -the art of maximizing the amount of work not done- -is essential.)

-> 무슨말인지 이해가 안되어서, 찾아 보았는데 = 단순할 수록, 불량을 줄일 수록, 미사용 기능을 구현 안 할 수록 효과적 이라는 의미

 

11. 최고의 아키텍처, 요구사항, 설계는 자기 조직화된 팀에서 창발한다나타난다.

(The best architectures, requirements, and designs emerge from self-organizing teams.)

-> 자기 조직화가 무엇일까? 의사 결정권자가 팀 안에 있어야 한다는 의미

 

12. 정기적으로 어떤 방법이 팀에 더 효과적일지 숙고하며 이에 따라 팀의 행동을 조율하고 조정한다.

(At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.)

-> Scrum에서는 Sprint가 끝나는날마다 회고(Retrospective)를 수행합니다. 아직 해보지 않은 것. 제대로 해야할 것.

 

 

다들 막연히 알고 있던 것들을 원칙으로 정리한 것이라 생각한다.

팀웍, 전문성, 오너십, 책임감, 소통 여러가지 사람 살면서 해야하는 것들에 충실할때 일도 잘되는 것이라 생각된다.