최근 좋은 책 하나를 번역하고 있습니다. 이 책의 내용중에 Big Visible Charts라는 내용이 나옵니다.
Big Visible Charts는 http://www.xprogramming.com/으로 유명하신 Ron Jeffries님의 글인 http://www.xprogramming.com/xpmag/BigVisibleCharts.htm에 자세하게 설명이 나옵니다.
우선 이해를 돕기 위해서 Big Visual Charts에 대하여 간략하게 요약하면 다음과 같습니다.
이상 간략한 요약이었습니다. Ron Jeffries님이 제시한 차트의 종류는 http://www.xprogramming.com/xpmag/BigVisibleCharts.htm 에서 확인하실 수 있습니다.
그냥~ 큰 백지위에 잘 그리면 될듯 합니다. 자알요~ ;-)
사실 저의 근본적인 고민은 The "Big Visual Charts"를 정말 "큰 시각화 차트"로 번역을 할 것인가? 였습니다.
뭔가 어색하시지 않습니까?
그래서 XP 책을 번역하셨던 유명하신 박현철 아키텍트님께 질문을 드렸습니다. 과연 Big Visual Charts를 어떻게 번역하는것이 좋을지에 관해서요~
역시 좋은 해결책을 주셨는데~ 바로 간판이었습니다.
Kenji Hiranabe님이 InfoQ에 올리신 "간판을 이용하여 Agile 프로젝트를 시각화하기(Visualizing Agile Projects using Kanban Boards)" 이었습니다. 원문은 http://www.infoq.com/articles/agile-kanban-boards에서 보실 수 있습니다.
일본 도요타 자동차에서 사용하는 Lean 시스템 역시 Agile 프로젝트와 같이 Big Visual Charts와 같은 것을 사용하여 프로젝트의 상태를 시작화한다는 내용이었습니다.
즉 Kanban Boards와 Big Visual Charts는 의미상이나 목적상에서 같은 것이라는 점입니다.
물론 약간씩은 차이가 있지만 프로젝트의 진행상태를 나타낸다는 점에서는 같으며, Big Visual Charts가 더 자유분방하고 Agile적인 요소를 기반으로 시각화를 한다면, Kanban Boards는 도요타에서 일정 수준의 체계화한 것들을 바탕으로 시각화를 하여 더 구체적이고 명확한 관점이나 요소나 항목을 가진다는 점이 다릅니다.
작업현황판(Task Kanban Board)의 경우 할일(To Do), 진행하는 일(Doing), 마친 일(Done)으로 구분되어 있습니다.
시각화를 위하여 이 글에서는 간판(Kangan Boards)와 Burndown Charts와 Parking lot Chart 및 달력(Calendar)를 사용하고 있습니다.
정리하면 하면 다음과 같습니다.
그래서 결론은 The Big Visual Chart를 간판이라고 번역하기로 결정했습니다.
그래도 약간 어색하긴 합니다면, 큰 시각화 차트보다는 명확하게 다가올것 같습니다.
혹시 더 좋은 의견 있으시면~ 댓글 많이 많이 부탁드립니다. :-)
감사합니다.
Big Visible Charts는 http://www.xprogramming.com/으로 유명하신 Ron Jeffries님의 글인 http://www.xprogramming.com/xpmag/BigVisibleCharts.htm에 자세하게 설명이 나옵니다.
우선 이해를 돕기 위해서 Big Visual Charts에 대하여 간략하게 요약하면 다음과 같습니다.
사람들이 알아야 할 것들(People Need to Know)
XP의 가치중에 하나가 의사소통(Communication)입니다.
팀간에 의사소통을 하는 여러가지 방법이 있습니다. 가장 일반적인 방법이 대화이지만, 기록이 필요하거나 민감한 주제이거나 트렌드가 변경되는 경우 XP에서는 "큰 시각화 차트(Big Visible Charts)"라고 부르는 것을 이용하는 것을 좋은 접근방법입니다.
간단한 차트를 벽에 붙여 놓음으로써 팀 전체가 주목하게 되어 정치적으로 민감한 정보까지 쉽게 전달할 수 있습니다.
벽에(On the Wall)
차트는 웹 사이트나 예쁘장한 슬라이드 쇼보다 많은 경우 벽위에 있는게 효과적입니다. 차트가 벽에 있으면 눈길이 벽에 머물며, 가까이에서 쉽게 바라보고 인식할 수 있기 때문입니다.
간편한게 더 좋다(Casula is Better)
차트를 그릴때 엑셀이나 비지오 등의 수 많은 전문적인 프로그램을 이용하는 것은 약간 재미있을 수 있지만, 대부분 자동화해줌에도 불구하고 전문적인 차트들은 작성하는데 많은 시간을 소비하게 됩니다.
따라서 더욱 간편한 대안을 찾아야 합니다.
포스트잇을 가지고 쉽게 붙이고, 굵은 펜으로 간단하게 그리면 매일 갱신하는 시간을 줄일 수 있습니다.
그냥 손으로 그리면 간편하여 더 좋습니다.
어떤 차트를 사용해야만 하는가?(What Should We Chart?)
차트는 여러분이 무었인가 관리하고 걱정하고, 다른 사람들이 알아야하는 것들을 나타내야합니다. 대부분 모든 XP 사례들은 차트를 위한 자료들을 제공합니다. 문제, 근본적으로 재발하는 것들 들이 가치있는 차트입니다.
명심해야 할 것은 스토리 구현(stories implemented)과 같이 차트가 좋은 역활을 하려면 결함들을 고쳐야합니다. 또는 상사가 언제 마지막으로 피자나 도넛을 사왔는지와 같은 나쁜 것들도 고쳐야 합니다. :-)
이상 간략한 요약이었습니다. Ron Jeffries님이 제시한 차트의 종류는 http://www.xprogramming.com/xpmag/BigVisibleCharts.htm 에서 확인하실 수 있습니다.
그냥~ 큰 백지위에 잘 그리면 될듯 합니다. 자알요~ ;-)
사실 저의 근본적인 고민은 The "Big Visual Charts"를 정말 "큰 시각화 차트"로 번역을 할 것인가? 였습니다.
뭔가 어색하시지 않습니까?
그래서 XP 책을 번역하셨던 유명하신 박현철 아키텍트님께 질문을 드렸습니다. 과연 Big Visual Charts를 어떻게 번역하는것이 좋을지에 관해서요~
역시 좋은 해결책을 주셨는데~ 바로 간판이었습니다.
Kenji Hiranabe님이 InfoQ에 올리신 "간판을 이용하여 Agile 프로젝트를 시각화하기(Visualizing Agile Projects using Kanban Boards)" 이었습니다. 원문은 http://www.infoq.com/articles/agile-kanban-boards에서 보실 수 있습니다.
일본 도요타 자동차에서 사용하는 Lean 시스템 역시 Agile 프로젝트와 같이 Big Visual Charts와 같은 것을 사용하여 프로젝트의 상태를 시작화한다는 내용이었습니다.
즉 Kanban Boards와 Big Visual Charts는 의미상이나 목적상에서 같은 것이라는 점입니다.
물론 약간씩은 차이가 있지만 프로젝트의 진행상태를 나타낸다는 점에서는 같으며, Big Visual Charts가 더 자유분방하고 Agile적인 요소를 기반으로 시각화를 한다면, Kanban Boards는 도요타에서 일정 수준의 체계화한 것들을 바탕으로 시각화를 하여 더 구체적이고 명확한 관점이나 요소나 항목을 가진다는 점이 다릅니다.
작업현황판(Task Kanban Board)의 경우 할일(To Do), 진행하는 일(Doing), 마친 일(Done)으로 구분되어 있습니다.
시각화를 위하여 이 글에서는 간판(Kangan Boards)와 Burndown Charts와 Parking lot Chart 및 달력(Calendar)를 사용하고 있습니다.
정리하면 하면 다음과 같습니다.
그래서 결론은 The Big Visual Chart를 간판이라고 번역하기로 결정했습니다.
그래도 약간 어색하긴 합니다면, 큰 시각화 차트보다는 명확하게 다가올것 같습니다.
혹시 더 좋은 의견 있으시면~ 댓글 많이 많이 부탁드립니다. :-)
감사합니다.
'Architecture for Software > Architecture' 카테고리의 다른 글
Software Configuration Management(SCM)에 관하여 (0) | 2009.09.11 |
---|---|
공개 소프트웨어에 대한 간략한 이해 (8) | 2009.07.28 |
소프트웨어와 서비스(Software and Service) (4) | 2009.04.19 |
프로젝트에서 스테이징(Staging)의 의미에 대하여 (4) | 2009.04.12 |
Convention over Configuration(CoC)에 관하여 (7) | 2009.04.04 |