20-09-02
안녕하세요 JetBrains 한국 총판 단군소프트입니다.
하지만 이제 다른 방식도 있습니다. 사용 방법을 확인해 볼까요? 제품 요구 사항 문서는 왜 필요 할까요? 제품 요구 사항은 제품 자체가 실제화 구체화 되기 전, 프로젝트 초반부터 제품의 일반적 목적, 동작, 기능 및 기능적 특성을 명시하고 정의합니다. 하지만 이러한 내용을 그저 기술하는 것만으로는 부족합니다. 많은 경우 제품의 비전은 시간이 흐르며 변화하고 제품 요구 사항도 여러 번의 조정과 수정을 거치게 됩니다. 또한 제품에 최신 요구 사항이 반영되도록 확인하는 데는 상당한 시간이 소요될 수도 있습니다. 그렇기에 적절히 구성된 요구 사항 관리 프로세스가 중요한 것입니다. 제품 요구 사항이 체계적으로 정리되어 있으면, 핵심 포인트를 추적하고 변화하는 요건을 지속적으로 통제할 수 있습니다. 미래 요구 사항과 관련한 모든 정보 수집 처음부터 프로젝트를 시작하는 일은 상당히 까다로운 작업입니다. 연구조사, 잠재적 사용자의 피드백, 이미 완료한 기획이나 브레인스토밍 자료 등의 향후 제품과 관련한 모든 정보를 수집하세요. 이 단계에서는 떠오르는 모든 정보를 최대한 모으는 것이 좋습니다. 나중에 쓸모없는 것들은 추려내고 중요한 정보만 보관할 수 있습니다. *프로세스에 따라 다음과 같은 요구 사항 소스를 살펴보세요. - 비즈니스 전략 및 제품 목표와 관련된 최신 자료. 이 단계의 핵심 목표는 한 곳에 모든 정보를 수집하는 것입니다. 이제 최대한 많은 정보가 수집되었다면 요구 사항을 조사하고 손쉽게 관리할 수 있도록 정리해야 합니다.
초안을 작성하세요 제품 요구 사항을 확립하는 과정에 기준이나 규칙은 없습니다. 하지만 JetBrains 팀에서 효과가 있었으며, 공동의 이해를 구축하는 데 도움이 되었던 몇 가지 방법을 소개해 드리겠습니다. - 제품 또는 기능의 일반적 목표를 간략히 기술합니다. 아이디어를 간단하고 직관적으로 유지하세요. 누구라도 한눈에 이해할 수 있어야 합니다. 표나 정렬된 목록을 활용하면 이와 같은 정보를 적절히 구성하는 데 도움이 됩니다. 구조 활용 명확한 트리 뷰 구조는 중복되거나 모순되는 요구사항을 방지하는 데 유용합니다. 또한 자료를 읽을 때 관련 자료를 빠르게 검색할 수도 있습니다. 이 단계에서는 일반적으로 단일 수준의 구조만이 존재할 것입니다. 제품 요구 사항 문서와 전략 자료가 포함된 관련 문서 정도겠지요. 하지만 제품 개발이 진행될수록 고객 인터뷰를 통한 인사이트, 팀 회의 결과 정리 등의 새로운 자료가 결합되면서 이 구조도 함께 성장하고 훨씬 더 방대하게 확장하게 됩니다. 이 단계에서 실행하기 좋은 방법은 비록 초반에는 필요성을 실감하지 못할 수 있지만 그럼에도 명확한 구조를 유지하는 것입니다. 예를 들어 구조 통합을 위해 향후 추가할 예정인 문서에 하위 자료로 더미 데이터를 생성할 수 있습니다. 다음으로 요구 사항 문서를 다음 페이지 트리간에 이동을 할 수 있고 조직에서 요구하는 사항에 부합하는 계층 구조를 협업 시작 댓글에서 이름을 언급하여 팀원들과 관계자의 참여를 유도하고 의견을 활발히 교류하세요. 기여자에게 편집 권한을 부여하면 기여자도 즉시 제안을 추가할 수 있습니다. 또한 댓글을 활용해 대화를 이어가면 논의 내용이 투명하게 공개되고, 모든 문서의 변경 사항에 대해 하나도 빠짐없이 알림을 받을 수 있습니다. 적절한 타이밍에 적절한 사람들을 참여시키는 것은 중요합니다. 예를 들어 모든 관계자가 요구 사항을 검토하고 잠재적 우려 사항을 직접 논의하는 회의를 주관하려는 상황을 가정해보겠습니다. 이때“우수함”으로 평가받기 위해 요구 사항이 충족해야 할 몇 가지 기준이 있을 것입니다. 이러한 기준은 간결하고, 이해하기 쉽고, 검증 및 실행이 가능하며 일관적이어야 합니다. 자료를 훑어보고 필요한 경우 요구 사항을 업데이트하세요. 검토 및 승인이 완료된 각 요구 사항을 표시하는 정형화된 방식을 구축하는 것도 좋은 방법입니다. 가령 대응하는 댓글을 남기거나 필수 사항 표에 메모를 추가할 수 있겠죠. 또한 회의에서 도출된 모든 결론 및 회의 시간까지 별도의 하위 자료로 기록하시길 추천해 드립니다. 이러한 방식을 활용하면 논의된 주제, 도출된 결론 및 미뤄둔 질문 등을 기억하는 데 도움이 됩니다. 스토리 완결 요구 사항을 실제 기능과 이슈로 변환하는 것은 제품 개발에서 무척 중요한 단계입니다. 이때 일부 요구 사항에 검토 및 조정이 다시 필요하다는 점을 깨닫게 될 수도 있습니다. 물론 그래도 괜찮습니다. 요구 사항이 현실에 최대한 부합하는지 확인하려면 여러 번 반복적으로 검토를 수행하길 추천해 드립니다. 폭포수 프로세스를 사용한다면 다른 YouTrack 계획 기능인 ‘간트 차트’를 주의 깊게 살펴보세요. 애자일 프로세스를 따른다면, 화면에 모든 에픽과 세분화된 작업이 표시되어 전반적인 흐름을 확인할 수 있는 YouTrack 애자일 보드 기능을 활용하세요. 에픽이 전체 기능을 나타내는 한편, 작업은 1-3일 내에 완수 가능한 작은 일이어야 합니다. 작업의 우선순위를 정하고,작업 간 종속성을 설정하고 보드에서 바로 진행 상황을 추적하세요. JetBrains는 이 방법이 제품과 완전히 동시적으로 개발을 진행하는 가장 효율적인 방법의 하나라고 생각합니다. 작업의 백로그를 구성하고(필요하다면 중요도 순서에 따라 수동으로 우선순위를 정합니다) 요구 사항 페이지에 삽입합니다. 여기까지 YouTrack의 다양한 활용 방법을 설명드렸습니다. 긴 글 읽어주셔서 감사합니다. |