프로젝트 관리 방법론, Agile이 맞는걸까?

지난 글에서는 프로젝트 관리 방법론이 뭔지에 대해 다뤘었다. 이번 글에서는 Agile을 도입하기전에 Agile이 맞는지, 실패사례는 뭐가 있는지를 알아보았다.

 

 

https://wonillism.tistory.com/221

프로젝트 관리 방법론 (Agile 위주)

애자일을 좀 더 알아보자

 

Agile : 1. 날렵한, 민첩한 2.(생각이) 재빠른, 기민한

 

날렵하고 민첩하다는 의미에서 만들어진 용어이다. 짧은 주기의 개발 단위를 반복하여 하나의 큰 프로젝트를 완성해 나가는 방식이며, 애자일의 핵심은 협력과 피드백이다.

유연하게 일을 잘 진행하며, 변화에 잘 대응하여 업무를 하는 것이다.

 

애자일 4대 선언 및 12가지 원칙을 알아보자

4대 선언

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를

왼쪽도 가치가 있지만 오른쪽을 더 높은 가치를 둔다는 선언이다.

 

12가지 원칙

 

1. 가치 있는 소프트웨어를 조기에 지속적으로 제공함으로써 고객을 만족시키는 것을 최고 우선순위로 한다.
2. 개발 작업 후반부일지라도 요구사항 변경을 기꺼이 수용한다. 애자일 프로세스는 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
3. 2주에서 2개월 주기로 작동하는 소프트웨어를 자주 제공하되, 더 짧은 시간 단위를 선호한다.
4. 프로젝트 전반에 걸쳐 비즈니스 담당자들과 개발자들이 매일 함께 작업해야 한다.
5. 동기가 부여된 개인들을 중심으로 프로젝트를 구성한다. 구성원들이 필요로 하는 환경과 지원을 제공하고, 담당 업무를 완수할 것임을 신뢰한다.
6. 개발팀에 그리고 팀 내부에서 가장 효과적, 효율적으로 정보를 전달하는 방법은 대변 대화이다.
7. 작동하는 소프트웨어가 진척의 주된 척도이다.
8. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야한다.
9. 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
10. 단순성이 - 안 하는 일의 양을 최대화하는 기술이 - 필수적이다.
11. 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.
12. 팀은 정기적으로 어떻게 더 효과적이고 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.

위 12가지 원칙 중 위 세가지는 소프트웨어를 일찍 그리고 지속적으로 전달하며, 요구사항 변경을 적극적으로 받아들이고, 짧은 주기마다 작동하는 소프트웨어를 제공하는 것이다. 이렇게 하기 위해서 반복과 백로그와 같은 방법을 사용하여 관리한다.

 

• 협력
  • 스스로 느낀 좋은 통찰은 협력을 통해 다른 사람에게도 전해줄 수 있다. 예상치 못한 팀의 기대 효과를 가져온다.
  ex) 어떤 사람이 2배의 속도로 개발할 수 있는 방법을 발견함 협력이 약하면? → 혼자만 좋은 보상과 칭찬을 받음. 하지만 그 사람 코드와 다른 사람의 코드의 이질감이 생겨서 시스템 문제 발생 가능성 협력이 강하면? → 다른 사람과 공유해서 모두 같이 빠르게 개발하고 더 나은 발전점을 찾기에 용이함. 팀 전체 개선이 일어나는 긍정적 효과 발생
• 피드백
  • 학습의 가장 큰 전제조건이 ‘피드백'. 내가 어떻게 했는지 확인하면서 학습을 진행해야 한다. 소프트웨어의 불확실성이 높을 수록 학습의 중요도는 올라간다. 모르는게 많으면 더 빨리 배워나가야 하기 때문이다.
  • 내부적으로는 내가 만든 것이 어떻게 됐는지 확인하고, 외부적으로는 내가 만든 것을 고객이나 다른 부서가 사용해보고 나온 산출물을 통해 또 다른 길을 배워나가는 것
• 불확실성
  • 애자일에서는 소프트웨어 개발의 불확실성이 중요하다
  • 불확실성이 높으면, 우리가 생각한거랑 다르다 라는 상황에 직면한다.
  • 전통적인 방법론 vs 애자일 방법
    • 전통적인 방법론
    • 그때 계획 세울 때 좀 더 잘 세워둘껄… 이런 리스크도 생각했어야 했는데… 일단 계속 진행하자
    • 애자일 방법론
    • 이건 생각 못했네. 어쩔수 없지. 다시 빨리 수정해보자.

 

Scrum 스크럼

소프트웨어 측면에서 팀이라는 단어가 주는 의미를 적용시키고, 효율적인 성과를 얻기 위한 것

• 제품 기능 목록 작성
  • 개발할 제품에 대한 요구사항 목록 작성
  • 개발 중에 수정이 가능하기는 하지만, 일반적으로 한 주기가 끝날 때까지는 제품 기능 목록을 수정하지 않는 것이 원칙
• 스프린트 backlog
  1. 스프린트 각각의 목표에 도달하기 위해 필요한 작업 목록
     1. 세부적으로 어떤것을 구현해야 하는지
     2. 작업자
     3. 예상 작업 시간
  최종적으로 개발이 어떻게 진행되고 있는지 상황 파악 가능
• 스프린트
  1. 작은 단위의 개발 업무를 단기간 내에 전력질주하여 개발한다
  2. 한달동안의 큰 계획을 3~5일 단위로 반복 주기를 정했다면 이것이 스프린트에 해당
  3. 주기가 회의를 통해 결정되면 (보통 2~4주) 목표와 내용이 개발 도중에 바뀌지 않아야 하고, 팀원들 동의 없이 바꿀 수 없는 것이 원칙
• 일일 스크럼 회의
  1. 모든 팀원이 참석하여 매일하고, 짧게(15~30분)하고, 진행 상황 점검
  2. 한사람씩 어제 한 일, 오늘 할 일, 문제점 및 어려운 점을 이야기한다.
  3. 완료된 세부 작업 항목을 스프린트 현황판에서 업데이트 시킴
• 제품완성 및 스프린트 검토 회의
• 스프린트 회고
  • 팀의 단점보다는 강점과 장점을 찾아 더 극대화하는데 초점

 

애자일이 우리 회사에 맞는 걸까?

모든 프로젝트, 모든 회사에 애자일이 적합한 것은 아니다. 상황에 따라 폭포수 모델이 적합할 수도 있고, 하이브리드 모델이 적합할 때도 있다. 그런데 애자일을 도입한 많은 회사들이 이러한 환경을 무시하고 무분별하게 애자일을 도입한다.

디자인 가이드가 나오지 않은 상태에서 서브페이지 디자인을 하라고 한다거나, 기능 정의가 되지 않았는데 일단 만들고 보자는 식이다. 스프린트(Sprint)를 반복적인 재작업(Rework)이 가능하다는 것으로 잘못 해석한 결과물이다.

반복적인 작업에 지친 조직 구성원들의 사기가 저하되고 칸반 보드에서 병목현상이 발생하며 생산성은 폭포수 모델 시절보다 더 떨어진다.

결국은 사람의 문제

애자일 도입에는 많은 인내심이 필요하다. 교육이라던가 환경개선에 많은 돈이 필요하고 정착되는데도 최소 1년은 필요하다. 정착됐다고 해도 단시간에 생산성이 향상된다거나 직원들이 주인의식을 가지지는 않는다. 주인의식은 조직의 문제가 아니라 사람의 문제이기 때문이다.

 

 

 

 

 

 

https://yozm.wishket.com/magazine/detail/917/