아이디어 구체화하기 (feat. 스크럼)

Lee Sanghyun·2024년 1월 25일

SQLI

목록 보기

2/7

프로젝트 구현 목표? WHAT

개발자의 DB 개념 학습을 위한 SQL Interpreter 안드로이드 어플리케이션입니다.

프로젝트를 진행할 때 초기에 아이디어를 구체화시켜놓은 것은 굉장히 중요합니다. 이 과정 없이 무턱대고 코드부터 짜게 된다면 어느 순간 길을 잃어버린 자신을 발견하게 될 것입니다. 아무리 작은 규모라도 프로젝트를 관통하는 컨셉만큼은 명확하게 문서로 정리해놓도록 합시다. 구체적으로 누군가를 위한 어떤 의도를 가진 어떤 기능의 프로그램인지 정리하는 걸 추천합니다. 아래는 포스팅을 위해서 SQLI 프로젝트의 주요 기능을 간단하게 정리해보았습니다. 실제 요구사항 문서가 궁금하다면 SQLI SRS를 참고해주세요.

SQL 문 해석 및 실행 기능: 사용자가 입력한 SQL 쿼리를 해석하고 실행하여 결과를 반환하는 기능을 구현합니다.
사용자 인터페이스(UI) 개발: 사용자가 쿼리를 입력할 수 있는 인터페이스를 구현하여 사용자 편의성을 높입니다.
에러 핸들링 및 안정성: 잘못된 쿼리 입력이나 예상치 못한 상황에 대비하여 적절한 에러 핸들링을 구현하여 안정성을 확보합니다.

스크럼을 이용하자 HOW

상황에 맞는 프로세스 모델은 개발 효율을 높여줍니다.

소프트웨어 프로세스 모델을 사용하면 개발 활동 관리 추적, 일정 및 예산 관리, 의사소통 관리 등 다양한 이점이 있습니다. 대표적인 모델은 폭포수, 반복진화형, 에자일이 있습니다. 필자는 여러 프로젝트를 진행하면서 폭포수와 스크럼 모델을 경험해봤고 이번 프로젝트에서는 에자일 모델 중 하나인 스크럼(scrum) 프레임워크를 사용하기로 했습니다.

물론 스크럼 마스터, 프로덕트 오너, 개발팀의 역할을 한명이서 하는만큼 어느정도 수정이 필요합니다. 개발 규모를 감안하여 진행 방식을 아래와 같이 수정하기로 했습니다. 수정한 프로세스 모델을 그림으로 표현해봤습니다.

느슨한 회의 주기: 개발 진도와 일정을 고려하여 스크럼 회의(그림에서는 셀프 피드백)를 주 2회로 변경합니다.
보다 엄격한 변경: 개발자의 역량을 고려하여 요구사항 변경 및 추가에 있어 기존 애자일 원칙보다 엄격하게 판단하도록 합니다.
1인 3역: 셀프 피드백 및 스프린트 회고시 개발자 관점에서 개발자의 역량, 스크럼 마스터 관점에서의 장애 요소 확인, 프로덕트 오너 관점에서 서비스 사용자의 니즈 분석을 시간과 역할을 분배하여 진행합니다.

스크럼을 선택한 이유 WHY

스크럼은 잠재파워를 썼다! 효과는 굉장했다!

학부 프로젝트에서 Scrum 여러번 경험해봤습니다. 특히 교내 공모전 프로젝트에서는 스크럼 마스터, 프로덕트 오너, 개발팀, 스탠드업 미팅 등 꽤 높은 수준으로 스크럼을 진행했습니다. 초반에는 새로운 프로세스 모델과 잦은 회의에 피로를 느꼈지만 적응을 하니 주기적인 소통과 피드백, 유연한 접근 방식이 주는 이점을 크게 느꼈습니다. 물론 이름만 스크럼이고 사실상 주먹구구식 (Build and fix)인 프로젝트도 있었습니다. (과정도 결과물도 최악이었습니다...) 따라서 성공담과 경험당 그리고 현재의 상황을 염두에 두고 스크럼을 고쳐쓰면 효율적일 것이라는 판단을 내렸습니다.

확장 및 변화 가능성: 1인 프로젝트인만큼 요구사항 변동이 빈번할 것으로 예상됩니다. 내 요구사항이 곧 프로젝트의 요구사항입니다.
동기부여: 고정된 짧은 주기로 스프린트를 반복함으로써 지속적으로 성취감을 줍니다. 1인 개발자의 의욕이 감소하는 상황을 방지합니다.
스크럼 경험 유무: 스크럼을 이미 경험해봤고, 장점을 뚜렷하게 느꼈습니다.