«   2019/03   »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
Archives
Today
0
Total
214,032
관리 메뉴

아름프로의 Agile, DevOps, 그리고 일상 이야기

린(Lean) 소프트웨어 개발 - 낭비를 제거하라를 Jazz/RTC 접목 본문

추억의 책장/IBM Rational

린(Lean) 소프트웨어 개발 - 낭비를 제거하라를 Jazz/RTC 접목

아름프로 2008.05.08 03:22
제가 jazzlab.net 에 작성한 내용을 다시 제 블로그로 옮겨 온 내용입니다.
비몽사몽 정리하다보니 좀 횡성수설한 감이 없지않아 있지만, 이미지보시면 무엇을 이야기하려는
쉽게 이해하실 수 있을 것 같습니다. (차후 맨정신에 조금식 수정해 나가겠습니다.^^)
링크 : 원본1, 원본2
==============================================================================
"린(Lean) 소프트웨어 개발" 의 첫번째 내용인 "낭비를 제거하라" 는 내용을 Jazz/RTC를 가지고 접목 시켜보았습니다.
그중에서도 "도구1 : 낭비 찾아내기" 관련 7가지 항목(관리활동 포함 8개)에 촛점을 맞추어 적용사례 형태로 화면 캡춰야여
구성해 보았습니다. 업무에 도움 되길 기원하며 시작해봅니다

1. 미완성 작업(Partially Done Work)
1-5.jpg
  • 해당 Iterate Plan 기간내에 마무리되지 못한 작업 내역을 "Plan 관리 화면을 통해서 본 내용입니다.
  • 이를 토대로 해당 기간내에 미완성 된 내역에 대해 분석하여 낭비의 요소를 제거하는 작업을 진행합니다.
  • 우측의 조건을 이용하여 좀 더 다양한 결과도 도출 가능합니다.
@ 추가 내용 (개발팀원의 Working Day 등록 내역 확인)
1-1.jpg

1-2.jpg

    1주일간의 실제 작업 가능 시간을 사전에 정의해 놓을 수 있습니다. (예> 5일 : 40시간)

1-3.jpg

    자리를 비워야하는 경우에는 개발 가능 일정에서 빠져야 할 겁니다. 그것을 대비한 스케쥴 등록 화면입니다.

1-4.jpg

    해외출장으로 작업 가능 시간이 줄어든 것을 확인할 수 있습니다.

2. 가외 프로세스(Extra Processes)

요구사항이 문서화되어야 하고 개발된 코드가 추적 가능하다면, 이 일은 가치를 부가하는 활동으로 간주된다는 점에서
다음과 같은 내용이 가능할 것 같다.

1-6.jpg

    요구사항이 반영된 Work Item 에 관련 소스, 연관 Work Item 등과 같은 관련 정보가 링크되어 연동되어 있어 변경내역등을
    쉽게 알 수 있다.

1-7.jpg

    해당 work item의 연계된 소스의 Change-set 정보를 통해 해당 요청에 따른 변경 소스 내역을 바로 확인 가능하다.

1-8.jpg

    이렇게 연관된 소스는 소스 변경의 내역까지 상세히 비교하여 확인해 볼 수 있다.

1-9.jpg
    해당 Work Item은 위와 같이 변경 내역에 대한 히스토리를 확인할 수 있다.

3. 가외 기능(Extra Features)


    새로운 기능을 넣고 싶은 것의 유혹에서 벗어나는 것이 그 핵심이지만, 시스템의 수정에 따른 추적, 컴파일, 통합, 테스트가
    가능한 환경이라면 어느정도의 가외 기능 추가에 따른 걱정은 덜 수 있을 것이다.
    1-20.jpg  
    하나의 개발환경에서 이 모든 것이 가능하며, 추적이 가능하다면 언급된 가외 기능도 어느정도 허용해줄 만 하지 않을까 싶다.

4. 직무 전환

    팀의 이동 및 업무의 전환에 따른 기존 업무가 방해 된다면 이러한 것 자체를 하지 말라/자제하라는 내용이다.
    하지만, 다른 프로젝트의 일원으로써 작업할 수 있는 여건이 좀 더 개선이 된다면, 아예 하지말라보다는
    현실적인 접근해서는(현실적으로 여러 일을 해야만 하는경우가 많기에..) 개선의 여지가 있을 것 같다.
  1-10.jpg
   즉, 어느 팀에 소속되어 있으며, 무슨 일을 하고 있으며, 그러한 일의 업무량이 얼마나 되는지 체크가 가능하다면 ...
    직무 전환에 따른 리스크를 좀 더 줄일 수 있을 것이다. (물론, 이렇게 안하는 것이 좋다고 이야기하지만... )

5. 대기
  
    결국 대기라는 상태인 것을 팀원들이 공유하고 있는 자체가 가장 중요할 것 같다.
    현실적으로 대기를 함에 있어서도 그것이 대기 상태인지 조차 인지 못하는 것이 가장 큰 문제라면 문제일 것이다.
    1-11.jpg
   앞서 잠시 나왔던 내용이지만, 이러한 것을 통해 대기상태에 대한 관리가 가능해지며, 업무의 치우침 현상도 막을 수 있다.

6. 이동
  
    문서화되어 전달되고, 공유하는 것에 따른 시간적 낭비, 업무 조율을 위해 움직이는 실제 움직이는 시간들의 낭비를 지적하고 있다.
    1-12.jpg
   이 문제는 Web2.0 시대의 산물중 하나인 챗팅기능을 통해 어느정도 해소 할 수 있다.
    실시간 업무 조율 자체를 채팅으로 진행할 수 있으며, 문서 역할을 하는 작업내역이나 소스내역서, 빌드내역서 등을 해당 채팅창에
    가볍게 드래그앤드랍 만 시켜도 링크가 될 수 있도록하면 놀라운 협업 가능 메커니즘이 탄생하게 된다.
    (링크 된 내용은 클릭하면 하면 해당 내역서를 바로 띄워준다.)

7. 결함
  
    긴말이 필요없는 내용인듯 싶다. 테스트와 통합, 릴리즈를 빠르고 효율적으로 할 수 있게 해주는 내용이다.
    1-13.jpg
   빌드 관련 내역 중심으로만 설명했지만, "3.가외기능" 설명에 있는 모든 내용이 이러한 결함 관리의 중요 내용이다.

8. 관리활동
   
    프로젝트와 팀에서 일어나는 일들을 한눈에 볼 수 있는 환경을 얼마나 제공하는지가 중요한 요건이 될 것이다.
    즉, 투명성의 확보다. 이를 통해 팀원 모두가 일관된 팀 작업이 가능토록 해주는 원동력이 된다.
    1-14.jpg

    팀 아티펙트라는 윈도우를 통해 팀에서 일어나는 모든 일들을 다양한 형태로 볼 수가 있다. (변경도 얼마든지 가능하다)
    또한 유사한 형태로 My Work 를 관리해주는 윈도우 또한 가지고 있어 나 자신의 관점에서도 관리가 가능하다.

1-15.jpg

       eclipse 개발환경 뿐만이 아닌, 웹 Ui형태로도 모든 작업이 가능하다. 더욱이 중요한 것은 DashBoard 기능을 통해
       프로젝트의 내역을 한눈에 볼 수가 있다. (보고자하는 내용을 자유롭게 변경하여 구성도 가능하다.)

1-16.jpg
   
    리포트(차트) 형태로 한눈에 알기 쉽게 현 상황을 모니터링 해준다. (이 역시도 변경이 가능하며 결과를 위한 쿼리 역시 쉽게
    생성 가능하다)

1-17.jpg

    좋은 프로젝트 결과에 있어서 가장 중요한 요소로 뽑히고 있는 Feed 도 한눈에 볼 수 있도록 제공 가능하다.

================================================( 끝 )==============================================
4 Comments
댓글쓰기 폼