3.Agile, 소프트웨어 개발의 낭비 요소에 대해서 간단하게 알아보고 고민도 해보자.

블로그 목적

• 소프트웨어 개발 시 낭비요소에 대해서 알아본다.

개발과정에서 낭비란 무엇일까?

• 소프트웨어 개발을 의뢰한 고객에게 가치를 더하지 못하는 활동으로 정의해볼 수 있음.
• 10년 이상의 개발자로 살아오고 여러 프로젝트를 진행해오면서 여러가지 부분에서 개발과정의 낭비를 경험하게됨.

그럼, 애자일 개발 전문가들이 말하는 일곱가지의 개발과정의 낭비요소를 알아보자.

• 애자일 개발 전문가
  • 메리 포펜딕(Mary Poppendieck)
  • 톰 포펜딕(Tom Poppendieck)
  • 참고의 아래 책의 저자이기도 함.
  • http://www.yes24.com/Product/Goods/2687010

• 암튼, 위의 언급한 애자일 개발 전문가가 제시한 낭비의 일곱가지 요소는 아래와 같음.
  • 하나, 미완성 작업
  • 둘, 추가 프로세스
  • 셋, 추가 기능
  • 넷, 멀티태스킹
  • 다섯, 대기시간
  • 여섯, 문서전달
  • 일곱, 결함

우선, 미완성 작업에 대해서 알아보자.

• 개발과정에서 만드는 중간 산출물은 고객관점에서 실질적인 가치를 제공하지 못함.
  • but, 개발과정에서는 필요함
    • 예를들면, 
      • 분석/설계 문서
      • 테스트하지 않은 코드 
      • 기타등등
• 결론적으로, 프로젝트에서 미완성상태 중간산출물을 최소화할 수 있도록 관리가 필요함.

그럼, 추가 프로세스에 대해서 알아보자.

• 보통기업에서 제품을 개발할 때 사용하는 표준 프로세스가 존재함.
  • 아래와 같이 장단점이 발생함.
    • 장점
      • 제품을 잘 개발 할 수 있게 도와줌.
    • 단점
      • 프로젝트에 따라서 업무로드가 될 수 도 있음.
• 결론적으로, 개발팀에서 가치를 주지 못하는 프로세스는 반드시 주기적으로 검토 후 개선을 해야함.

그럼, 추가 기능에 대해서 알아보자

• 개발자가 판단해서 향후 사용에 대비를 위한 기능을 집어넣을때가 있음.
  • 전통적 프로젝트에서는 
    • "금 도금(gold-plating)" 이라고 이야기 함.
      • 즉, 불빌요한 일을 하지 말라는 의미임.
• 결론적으로, 빈번하게 사용되지 않는 기능을 계속 추가하게되면, 그만큼 유지보수노력이 많이 들게 되므로 주의하자.

그럼, 멀티태스킹에 대해서 알아보자

• 한사람이 많은 프로젝트에 관여할때가 생길때도 있음.
  • 즉, 멀티태스킹....-_-;
• 기업 입장에서는, 한사람에게 많은일을 맡겨 업무 효율성을 높이려는 암묵적인(?) 목적이 존재함.
  • 보통, 4~5개의 프로젝트 참여하기도 함.
    • 과거의 경험을 풀어보자면,
      • 전, 최대 3개의프로젝트를 동시에 진행했던 기억이 있음. -_-; 
        • 주말도 회사나가서 제안서쓰고 그랬던 기억이...제안서 쓰는날은 날새는 날...OTL
• 물론, 멀티태스킹도 마냥 안좋은 것은 아님.
  • 즉, 업무 특성상 비슷한 일이면, 괜찮음.
  • but, 만약 다르다면.. OTL
    • 특정 프로젝트를 진행하다가 또 다른 프로젝트로 바로 업무 전환하기는 많이 어려움.
• 결론적으로, 멀티태스킹을 위한 업무전환 시간은 바로 낭비의요소가 되므로 주의해야함.
  • 항상, 적당한게 좋은것 같음. 그래서 과유불급이란 말이 있지않은가... ^^;
• 참고로...
  • "몰입" 의 저자 미하이 칙센트미하이는 아래와 같은 한마디를 남기는데...
    • 주의력은 제한되어 있으며 한순간에 극히 제한적인 정보밖에 처리할 수 없다.
    • 까다로운 문제에 주의를 집중해서 적절한 해결책을 마련할 여건을 조성하려면 15분에서 1시간이 걸린다.
    • 짦은 시간 안에 이 업무, 저 업무로 넘어가는 것보다는 오히려 한 가지 업무에 집중하다가 더 이상 진전이 없는 시점에 도달할 때 다른 문제로 넘어가는 것이 바람직하다.
    • 새로운 과제가 다시 지루해져 기존의 문제로 돌아갈 때 아이디어가 떠오른다.

그럼, 대기시간에 대해서 알아보자

• 보통 개발업무시 고객과 여러 분야의 기술자들이 모여서 빠르게 의사결정을 해야할 일들이 생기곤한다.
  • 만약, 고객/팀원등등 모두 한공간에 존재한다면 바로 의사결정을 하면되지만,
    • 그렇지 않다면,
      • 약속시간 / 장소를 별도로 시간을 내서 잡아야함.
• 즉, 대기하는 시간이 발생하게 되고, 해당 대기시간을 낭비없이 효율적으로 해소하는 것이 주요 포인트.

그럼, 문서 전달에 대해서 알아보자.

• 전통적인 프로젝트에는 분석 / 설계 / 구현 / 테스트와 같은 순차적 공정 단계를 거쳐 제품이 생산됨.
  • 즉, 각 단계마다 분석가 / 프로그래머 등등 해당 전문가들이 투입되서 업무 효율성을 높이려고 하는 것이 일반적임.
• 이를테면, 우리는 위의 방식을 폭포수 개발방식이라고 말하는데, 
  • 폭포수 개발방식은 문서에 모든 정보가 담겨 있다는 것을 전제로 함.
    • but, 고객은 생각하는 것을 모두 말로 표현하지 못하고 말로 표현한 것이라도 모두 문서의 담지 못한다.
• 그리고, 실제 문서로 담기는 것은 고객이 구상한 것의 50%도 되지 않는다고 함.
  • 그래서, 많은 커뮤니케이션없이 오직 정리된 문서만을 보고 개발하면 고객의 기대와는 상당히 거리가 먼 시스템(?)이 생성될지도.....
• 즉, 문서를 작성하면, 정보를 공유하는 데 많은 도움은 되지만, 전적으로 문서에만 의존해서는 안됨.
• 결론적으로, 올바른 요구사항을 도출해서 완성도 높은 제품을 설계하기 위해서는 고객과 자주 커뮤니케이션을 통해서 의사교환을 해야함.

마지막으로, 결함에 대해서 알아보자.

• 개발자로서 돌아볼때, (잠시....)
  • 아무리 노력을 하더라도 인간이 만든것이기 때문에 결함은 반드시 발생하기 마련인것 같다.
• 즉, 결함이 발생했을 때, 결함에 대해서 시기 적절한 대응을 해야하는데,
  • 결함을 늦게 발견할수록 그것을 바로 잡는데는 더 큰 노력이 필요하기 마련이다.
  • 즉, 결함이 발생했다는 것이 낭비의 요소가 됨.
• 그럼, 어떻게 대응해야 할까?
  • 결함은 꾸준한 모니터링으로 조기에 발견해서 빠르게 수정하거나 아예 결함이 발생하지 않도록 하는 것이 최선의 대응 방법임.
• 애자일의 특징은,
  • 결함이 발생하지 않도록 예방하는데 초점을 맞춤.
    • 즉, 전통적 프로젝트는 구현/테스트를 분리하여 진행하지만, 애자일 개발은 구현/테스트를 일체화하여 공정의 하나로 진행하고 코딩단계부터 결함을 예방하는데 힘을 쏟음.
    • 예를들면,
      • TDD(Test Driven Development) 를 예로 들어볼 수 있음.
        • TDD란?
          • 제품 구현 / 코딩을 시작하기 전에 테스트케이스를 먼저 작성하고 해당 테스트를 통과하는 코드를 구현함으로써 처음부터 발생될 수 있는 결함을 줄이려고 노력하는 방법
• 결론적으로,
  • 애자일을 통해서 결함이 발생되지 않게 예방 하는것이 목적임.

결론

•  애자일 개발 전문가가 말하는 일곱가지의 개발과정의 낭비요소는 아래와 같음.
  • 하나, 미완성 작업
  • 둘, 추가 프로세스
  • 셋, 추가 기능
  • 넷, 멀티태스킹
  • 다섯, 대기시간
  • 여섯, 문서전달
  • 일곱, 결함
• 오늘도 소프트웨어 개발의 낭비요소에 대한 지식 한가지 획득완료! 감사합니다.