모든 사람들이 명세서 작업을 해야한다고 생각은 하지만, 아무도 명세서 작업을 하지 않습니다.
왜 명세서 작업을 하지 않을까요?
명세서 작업단계를 건너뛰면 시간을 절약할 수 있다고 말합니다.
이런 사람들은 명세서 작성 작업이 NASA에서 우주 왕복선을 만드는 공학도나 큰 규모의 보험회사 직원에게나 필요한 사치쯤으로 치부합니다.
명세서 작업을 하지 않는 관례는 소프트웨어 프로젝트에서 가장 크고 불필요한 위험 요인을 짊어지는 행동입니다. 이는 등에 옷가지만을 걸친 다음에 날기를 기대하며 모하비 사막을 건너려고 출발하는 것만큼이나 바보스럽습니다.
명세서 작업을 생략하고 바로 코드 작성으로 뛰어드는 프로그래머나 소프트웨어 개발자는 스스로를 허리춤에서 순식간에 총을 뽑는 멋진 총잡이라고 생각하는 경향이 있습니다.
하지만 결코 그렇지 않으며, 이런 개발자일수록 놀라 자빠질 정도로 생산성이 낮습니다.
즉, 형편 없는 코드를 작성하거나 조잡한 소프트웨어를 양산하며, 결국 전혀 쓸데없는 거대한 위험을 자초해 프로젝트를 위협합니다.
기능 명세 – FUNCTIONAL SPECIFICATION
완전히 사용자 관점에서 제품이 어떻게 동작할지를 기술합니다. 어떻게 구현했는지는 신경도 쓰지 않습니다. 기능에 대해 이야기하고, 화면, 메뉴, 대화상자와 같은 사용자 인터페이스 부품을 명세합니다.
기술 명세 – TECHNICAL SPECIFICATION
프로그램 내부 구현을 기술합니다. 자료구조와 관계형 데이터베이스 모델과 프로그래밍 언어, 도구, 알고리즘 선택과 같은 항목을 다룹니다.
* 좋은 기능 명세에 대한 아이디어!
1. 면책 조항
방어적인 내용 “이 명세는 완벽하지 않습니다.” 시간이 흘러 명세가 완벽하게 되면 다음과 같이 면책 조항을 바꿀 수 있다. “제가 알기로는 이 명세는 거의 완벽합니다. 하지만 무언가 빠뜨렸을 경우에는 제게 말씀해주세요”
2. 저자
명세는 1명이 전담해서 작성해야만 합니다. 큰 제품일 경우라면, 여러 부문으로 쪼갠 다음에 각각을 개인에게 할당해서 독자적으로 명세하게 합니다. 어떤 회사는 명세에 이름을 넣어서 개인의 공로를 인정하는 관례를 이기적인 행동이나 팀워크를 해치는 일이라고 생각합니다.
하지만 이는 허튼 소리입니다. 사람들은 자신이 명세한 사항에 대해 책임감과 소유의식을 느껴야 합니다. 명세에서 무언가 잘못되면, 이를 수정할 책임이 있는 명세서 소유자를 지정해야 하며 이 사람 이름이 바로 명세서에 찍혀 있어야 합니다.
3. 시나리오
생생하고 현실적인 시나리오를 만들수록, 실 사용자나 가상으로 창조한 사용자 모두를 위한 제품을 더 잘 만들 수 있습니다.
4. 회피목표
팀 단위로 제품을 만들 때 없으면 못살겠다는 이유만으로 실제든 상상이든 간에 각자 좋아하는 상큼한 기능을 넣으려는 경향이 있습니다. 이렇게 불필요한 기능을 쳐내는 가장 좋은 방법으로 명세에 회피목표 항목을 추가합니다.
5. 개괄
개괄은 명세를 위한 목차와 유사합니다. 개괄은 간단한 흐름도이거나 광범위한 아키텍쳐 관점에서 본 토론일 수도 있습니다. 모든 사람이 숲을 보기 위해 목차를 읽습니다. 이렇게 해야 나무도 의미가 있을 것입니다.
6. 세부사항
웹 타입 서비스를 설계할 때 세부사항을 정리하는 좋은 방법은, 모든 가능한 화면에 기준이 되는 이름을 붙인 다음, 너무나도 자세해 못 견딜 만큼 따분한 세부사항을 매 화면마다 기술하는 장을 제공하는 겁니다.
세부사항은 기능 명세에서 가장 중요한 핵심입니다.
7. 미해결 문제
명세 첫 버전에 미해결 문제를 남겨놓아도 나쁘지 않습니다. 문제점을 쉽게 찾을 수 있도록 특별한 스타일을 적용해서 표시를 하고, 적당한 대안이 있으면 이를 논의합니다. 프로그래머가 작업을 시작할 무렵에 이런 모든 미해결 사항들을 짚어놔야 합니다.
단순히 프로그래머가 모든 쉬운 작업부터 시작하도록 내 버려두고, 나중에 미 해결 문제를 푸는 방법이 옳다고 생각할지도 모르겠습니다. 하지만, 이는 잘못된 생각입니다. 프로그래머가 코드를 구현하려고 시도할 무렵에 나타나는 새로운 문제점과 씨름하는 과정에서 또 다른 문제점이 나타날 것이며, 당신이 미리 알고 있었으며, 예전에 끝냇어야 하는 미해결 문제 역시 그대로 남아 있을 것입니다. 설상 가상으로 난이도 높은 문제를 해결하는 과정이 코드를 작성하는 방법에도 상당한 영향을 미칠지도 모르겠습니다.
8. 방주 (SIDE NOTE)
명세를 작성하는 동안에 프로그래머, 테스터 , 마케팅팀원, 기술집필가와 같은 다양한 청중이 있음을 기억해야 합니다. 명세를 작성할 때 단지 특정 그룹에만 유용한 활자화한 사실을 고려하면 좋겠습니다. 예를 들어 프로그래머를 위해 기술적으로 유용한 몇가지 세부 사항을 기술하는 메시지를 ‘기술노트’항목으로 구분해서 기록할 수 있습니다. 마케팅 팀원은 이런 메시지를 무시하지만 프로그래머는 이런 메시지를 탐독합니다.
9. 명세는 지속적으로 개정해야 합니다.
주기적으로 개정하여 현실을 반영합니다. 명세는 항상 제품이 동작하는 원리를 최대로 반영하는 그림자 입니다. 명세는 단지 제품이 코드완료시점에서 굳어질 따름입니다.
* 명세서 작성 팁
1. 재미있게 씁시다.
여러분이 작성한 명세가 유쾌하며 재미있고 읽기 쉽다는 이유로 당신을 얕보는 회사에 근무한다면, 어서 다른 회사를 찾는 게 낫습니다.
2. 명세를 쓰는 작업은 머리가 돌아가도록 코드를 쓰는 작업과 유사하다.
문서를 소개하려는 대상층을 감안하고, 단계마다 그 사람이 무엇을 이해하길 바라는지 먼저 상각해보세요. 문장마다 독자가 내용을 깊이 이해했을지, 문맥의 의미는 파악했는지 스스로 되물어보십시오. 그래야 명세를 읽는 높으신 분께서 수많은 기술 용어에 압도당해 처음부터 문서 읽기를 포기하거나 멈추지 않게 될 겁니다.
3. 최대한 단순하게 작성하라.
쉬운 문장으로 작성하는 방식은 왠지 프로답지 않다는 생각에, 형식적이며 현학적인 언어를 남발하지는 마세요. 가능한 가장 쉬운 언어를 사용해야 합니다. 실제화면 보다 명세서를 더 효과적으로 개선하는 방법은 없습니다. 그림은 천마디 말보다 낫습니다.
4. 여러차례에 걸쳐 검토하고 다시 읽어라.
5. 표준양식은 해롭다고 간주한다.
모든 명세는 일정한 형식을 갖춰야 한다라는 생각은 버리십시오.
출처: http://elky.tistory.com/598 [엘키의 주절 주절]
