조엘 온 소프트 웨어 리뷰 두번째(아담)
ada...@nate.com
조엘 온 소프트웨어 리뷰 두번째 입니다.
손쉬운 기능명세 작성법
명세서란...
「제조지시서」 또는 '작업 지시서'라고도 한다. 제품을 생산하기 위한 지시,주의사항을 기입한 것. 의류의 경우에는 재단사나 봉제
업자 등의 지시서가 있으며, 각각의 전문 분야에 따라 디자인, 천, 부속품, 색의 지시, 납기, 수량 등이 명기되어 있다.
네이버 지식사전 中...
안녕하세요 저는 아담입니다. 한 주간 잘들 보내 셨나요? ㅎㅎ
그럼 조엘 온 소프트 웨어 두번째 리뷰를 시작하겠습니다.
명세서...명세서의 종류는 많습니다. 급여 명세서, 거래 명세서 등등 그럼 우리가 사용하는 명세서는 어떤 것일까요?
바로 네이버 지식사전에 나와 있는 작업 지시서와 비슷한 역활을 하는 명세서가 아닐까합니다.
네이버 지식사전에 의하면 "제품을 생산하기 위한 지시,주의사항을 기입한 것" 그렇다면 명세서란 정확하면 정확할수록 우리 개발자들
이 작업하는데 많은 도움이 되겠군요.
그럼 현실에서는 어떨까요? 조엘님의 책에 의하면 개발자들은 명세서를 중요하게도 다루지 않을 뿐만 아니라 어떤이들은 필요 없는 작
업이라고 까지 말들을 합니다. 분명 이 책은 오래전에(약 6~7년전) 나온 책이긴 합니다. 그래서 지금은 그렇지 않을 것이다.
라고 생각 하시는 분들도 계실겁니다. 하지만 그럼에도 불구하고 명세서의 중요성을 잠시 놓아두셨거나 아니면 명세서가 뭥미? 라는
분들을 위해 리뷰를 할까 합니다.
잼있게 읽어 주세요~~
1. 명세서에 관한 고찰...
저자에 의하면 개발자들은 NASA나 큰 규모의 프로젝트에서만이 명세서가 필요다는 인식이 있다고 합니다. 오히려 바로 코드를 작성
하는 이들이 스스로를 더 잘난 개발자라고 착각하는 경우도 있다고 합니다.
하지만 방심은 금물!!
저자는 이런 개발자일수록 형편없는 코드를 작성하거나 조잡한 소프트 웨어를 양산하며 생산성 또한 떨어진다고 단언합니다.
명세서가 대체 뭐길래 저자는 이렇게 까지 말을 하는 걸까요?
그럼 명세서가 정확히 개발에 관해 어떠한 역활을 하는지 살펴 보겠습니다.
명세서는 인간의 언어로 작성된다.
우리 모두는 명세서를 코드로 작성하지는 않지요....즉 국어든 영어든 아랍어든 서로간의 커뮤니케이션이 쉬운 언어로 작성된다는 것
이 장점입니다.
대화가 쉽고 기록하기가 쉽다는 것은 수정하기가 쉽고 여러 가능성을 열어둔다는것(....)
윗글에 라임....은 그리 중요한 것은 아니고...우리가 처음에 요건 정의를 잘못했거나 정확하게 하지 않아 수정을 해야 할때 코
드를 수정하는것이 빠를까 아님 문서를 수정하는 것이 빠를까의 답이 아닐까 합니다. 즉 처음부터 요건을 세세하고 정확하게 정의하
려는 노력 즉 문서를 몇번이고 몇십번이고 수정하여 소스 코드 수정을 최대한 줄이자는 의도가 보입니다.
개발자 모두는 스스로가 짠 코드의 품질은 상관치 않고 자신이 짠 코드에 애착이 있음을 아실겁니다. 최고의 아키텍쳐를 구축하지 못
했음에도 불구하고 우리는 초기의 잘못된 설계와 이상적인 설계사이에서 타협점을 찾으려 하려는 경향이 있습니다.
이것이 첫번째 이유입니다. 첫 단추를 잘못꾀면 결국은 단추가 하나 남아 "병맛"처럼 보이지만 스스로 우리는 나름 개성이야 하며
그대로 돌아다닌다는 거죠... 설계와 아키텍쳐 구현을 잘해야 소스 코드가 잘나올꺼고 그러면 스스로가 "개성"으로 만족하는 것이
아닌 모두가 만족하는(클라이언트와 개발자 모두가) 프로그램이 나온다는 말입니다.
의사 소통 시간의 절약
명세서를 작성하면 오히려 의사소통시간이 절약 됩니다. 잘만들어진 명세서 하나로 함께 일할 팀원과 품질보즘팀, 마케팅팀원, 사업개
발팀 팀원, 기술집필가(메뉴얼만드는사람) , 그리고 고객(자신에게 필요한 프로그램인지) 등등으로 많은 사람들이 보고 사용 할 수
있습니다. 이런 것이 없다면 서로간에 필요할때마다 서로의 일을 방해하며 자신의 궁금중을 해결 하려고 하겠지요..
게다가 프로그래머는 올바른 대답을 하기 보다는 코드 결과에 따라 대답을 하려는 경향이 있습니다. 따라서 실제 품질보증팀에서는 좀
더 쓸모있어 보이는 설계를 기준으로 삼은 프로그램대신에 프로그램을 기준으로 삼은 프로그램을 테스트 하는 경우가 많습니다.
일정 계획하기
나중에 일정에 관하여 한번더 리뷰를 작성하겠지만 명세서가 있어야 일정을 잡기가 쉬워진다는 것입니다. 가격을 모른채 물건을 사지
않듯이 얼마나 오래 걸릴지 모른는 프로그램을 만들지는 않겠지요
명세서 작업은 명세서가 없다면 묻혀버릴 모든 짜증나는 결정 사항을 못박아 버리는 멋진 방법입니다. 예를 들어 회원관리가 필요한
웹사이트를 구축할때 유저가 자신의 암호를 잊어버려 이메일로 받는다고 할때 이메일 문구를 개발자가 직접 작성하지는 않지요 보통
업무 담장자가 작성할것입니다. 이러한 세부적인 것들을 명세서에서 다 잡아 낼수 있는것이 명세서의 힘이라고 저자는 말하고 있습니
다.
하지만 이렇게도 많은 장점들에도 불구하고 많은 개발자들이 명세서를 등한시하는 이유는 단 하나 귀찮아서 또는 글을 쓰는 일을 워
낙 싫어 하기 때문입니다.(그래서 저자는 개발서적이 아닌 따른 인문서적을 읽는것을 권하고 있습니다.)
하지만 우리는 명세서가 우리에게 가져다 주는 편리함을 살펴 보았으며 좋은 프로그램을 만들기 위해서 우리는 명세서가 꼭 필요하다
고 생각하게 되었습니다.(동의 못하시는 분들은 제가 아닌 Mr. 조엘 한테 직접 멜로 보내세요 아마 영어로 작성 해야 할겁니
다.^^)
그럼 이제 좋은 명세서란 어떤것인지 한번 살펴 보겠습니다.
2. 명세서 항목
저자는 기능 명세와 기술명세 두가지 용어를 사용하고 있습니다. 다만 아직 표준으로 정해진 용어는 아니지요
기능명세 - 완전히 사용자 관점에서 제품이 어떻게 동작할지를 기술 하는것, 내부적인 구현은 상관하지 않으며 화면, 메뉴, 대화
상자같은 인터페이스 부품을 명세한다.
기술 명세 - 프로그램의 내부 구현을 기술한다. 자료구조와 DB모델과 프로그래밍 언어와 도구 알고리즘 선택과 같은 항목을 다
룸
제품을 설계할때는 기술명세보다는 기능명세를 우선해야 하며 기술명세는 나중에 따로 생각해도 된다고 저자는 말합니다.
그럼 기능 명세에 관해 살펴 보겠습니다.
개괄(전체를 대충 추려냄)
이명세는 아무리 상상해도 완벽하지 않은 명세이며 최종결과물이 나오기까지 여러차례 수정된 것이다.
실제 외형은 사용자와 디자이너에 의해 천천히 드러난다.
시나리오
실제 사람들이 제품을 어떻게 사용하는지 현실감있는 이야기를 상상한다면 크게 도움이 될것이다.
회피 목표
이 버전에서 지원하지 않는 기능을 미리 정한다.
흐름도
세부사항은 나중에 생각하기로 하고 우선 서비스를 위한 간단한 흐름도를 그려 전체 숲을 확인한다.
화면 단위 명세
외형과 느낌은 일단 그래픽 디자이너에게 맡겨두고 이문서는 일단 외형과 배열보다는 기능과 상호대화 설계 측면에 집중한다.
시작화면
화면 처음 시작시 음아과 애니메이션의 설정 그리고 자주 방문 하는 사람들에게는 애니메이션을 처음 한번만 볼것인지 등의
편의성등을 명세한다.
저자가 명세마다 넣은 단골항목들의 정리
면책조항 : 순수하게 방어적인 내용, "이 명세는 완벽하지 안습니다."라고 넣는다면 따지러 오는 사람들의 수는 확연히
줄어든다고 합니다. 하지만 시간이 흘러 명세가 완벽해진다면 "제가 알기로는 이 명세는 거의 완벽합니다. 하지만 무언가 빠
뜨렸을때는 제게 말씀해 주세요" 라는 문구로 바꿉니다.
저자 : 저자는 반드시 한명이 써야 합니다. 공동저작으로 쓰게 된다면 여러 골치 아픈 일들이 생길 것입니다. 큰제품일 경우 여
러
부문으로 쪼갠다음에 각각을 개인에게 할당해서 독자적으로 명세 하게 합니다. 사람들은 자신이 명세한 사항에 대해 책임감과 소유의식
을 느껴야 합니다. 명세에서 무언가 잘못되면 이를 수정할 책임있는 명세서 소유자를 지정해야 하며, 이 사람 이름이 바로 명세서
에 찍혀 있어야 합니다.
시나리오 : 제품을 사용할 청중 범위를 정한 다음, 전형적인 방식으로 제품을 사용하는 청중에서 뽑아낸, 판에 박은 가공으로 만
든사용자를 상상하며 시나리오를 만듭니다.
회피목표 : 팀단위로 제품을 만들때 각 개발자들은 자신이 좋아하는 상큼한 기능들을 넣으려는 경향이 있습니다. 이 모든 기능들
을 허용한다면 시간도 무진장 걸리고 돈도 많이 들어갈 것입니다. 이런 이유 때문에 불필요한 기능을 버려야 하며 이러한 방법으로
는 회피 목표방법이 있습니다. 명세에 회피 목표 항목을 추가하여 하면 안되는 작업들을 적어 넣습니다. 물론 회피목표는 많은 논
쟁들을 가져오지만 최대한 빨리 도마에 올린다는 측면에서 중요합니다.
개괄 : 개괄은 명세를 위한 목차와 유사합니다. 개괄은 간단한 흐름도이거나 광범위한 아키텍처 관점에서 바라본 토론일 수도 있습니
다.
세부사항 : 마지막으로 세부사항으로 들어갑니다. 대부분은 마지막까지 세부사하을 파악하지 않습니다. 웹 서비스를 설계할 때 세부사
항을 정리하는 좋은 방법은 각 화면에 기준이 되는 이름을 붙인 다음에 너무나도 자세해 견디지 못할 만큼 세부사항을 화면마다 기술
해 놓는 것입니다.
미해결 문제 : 명세 첫 버전에 미해결 문제를 남겨 놓아도 나쁘지 않습니다. 프로그래머가 작업을 시작할 무렵에 이런 모든 미해
결 사항들을 짚어놔야 합니다. (단순히 쉬운문제부터 해결하고 나중에 미해결 문제를 해결하는 것도 하나의 방법이라 생각할 수 있지
만
미해결 문제를 해결하는 과정에서 다른 문제들이 발생 할 수 있으며 개발자들이 미리 알고 있었으면 끝냈을 미해결 문제 역시 그대
로 남아 있게 될 것입니다.
방주 : 명세를 작성하는 동안 프로그래머 , 테스터, 마케팅 팀원등의 다양한 청중이 있음을 고려하고 특정그룹에서만 유용한 활자
화한 자료들을 고려 하면 좋겠습니다. 예를들어 프로그래머를 위해 기술적으로 유용한 몇가지 기술노트 항목을 정하여 기록하면 이것
은 프로그래머만 탐독하면 됩니다. 이런식으로 테스팅노트 , 마케팅노트, 문서화 노트 와 같은 것들이 있으면 좋습니다.
명세는 지속적으로 개정 되어야 합니다. : 일부 프로그래머는 폭포수 사고방식으로 무장하고 있기 때문에 한번 설계하고 명세를 적
어 프로그래머에게 주고 갑니다. 이러한 접근 방식은 명세서를 쓸모 없게 만듭니다. 왜냐하면 현실이 반영되어 있지 않기 때문입니
다.
3. 좋은 명세서를 쓰기 위한 조건
명세서를 쓰는 팀원의 가장 큰 불만은 아무도 명세서를 읽지 않는다는 것입니다. 그렇기 때문에 명세서를 작성하는 이도 냉소적으로
작성하게 되며 더욱더 명세서를 보는이들이 줄어들게 됩니다. 그리고 업무 담당자나 고객은 이러한 명세서를 더욱 찾지 않을 것이기
에 나중에 가서 명세서와는 전혀 다른 소리를 하게 됩니다.
따라서 명세서는 모두 읽어야만 빛을 바라게 됩니다. 명세서 작성자는 개발자 또는 관련된 사람들에게 명세서를 읽도록 유도해야 할
필요가 있습니다.
읽고싶어지는 명세서를 만들기 위해 5가지 쉬운 규칙을 소개합니다.
1. 재미있게 쓴다.
많은 비유와 오버로 핵심에 양념을 칩니다
2. 명세서를 쓰는 작업은 머리가 돌아가도록 코드를 쓰는 작업과 유사하다.
같은 설명도 전혀 다르게 나타낼 수 있으며 프로그래머들은 학술 논문처럼 보이는 명세를 쓰려고 노력합니다.
올바른 명세를 기술적으로 올바르게 써야 한다고 생각하며 함정에 빠지는 것이지요 읽기는 편하고 쉽게 하며 기술적인 것들은
기술노트를 만들어 따로 포인트 부분만 정의 합니다.
3. 최대한 단순하게 정리하기
언어선택을 할때 가장 쉬운 언어를 선택해야 하며 호흡이 긴문장은 두문장으로 나눠 씁니다.
글자로 도배하는 방식은 피하며 다양한 콘텐츠를 이용합니다.
4. 여러차례에 걸쳐 검토하고 다시 읽기
5. 표준양식은 해롭다고 간주한다.
일정한 형식에 모든것을 마추지 마십시요 그건 중요한것이 아닙니다.
여기까지가 제가 읽은 조엘온 소프트 웨어 "명세서 작성법"에 관한 리뷰입니다.
읽어 주셔서 감사하고 담주에도 찾아 뵙겠습니다. ^^
즐거운 한 주 시작 하세요 ㅎ
