[소개원실] Project Sprints

기본적인 프로젝트 진행 방식과 document 작성 규칙, 방법들을 배웠다.

프로젝트 스프린트 과정

• 팀 구성
• 프로젝트 주제 제안
• 프로젝트 스프린트
  • Sprint 1: (Features + Setup) - requirements and specification
  • Sprint 2: design and planning document, starting development
  • Sprint 3
  • Sprint 4
  • Sprint 5
• Final demo poster session
• Final Report
• 스프린트 마다 문서들을 버저닝 하면서 업데이트 해야한다.

Project requirements and specification

• a living document
• github wiki 이용
• 간결하게 작성포함 되어야할 내용
• 프로젝트 요약(project abstract)
• Target customer: 타깃 고객, 좁은 범위와 넓은 범위 모두 생각하기.
• Competitive Landscape: 경쟁사 분석, 차별점 설명하기
• User stories: feature 설명
• User interface requirements (UI)

User Stories

• short description of the actors로 시작(기능 별로 생각?)
• 각 스토리마다 어떤 스프린트에서 계획했는지, 구현되었는지 표기하기
• 각 기능을 who => what => why로 설명하기

(예시)

기능 이름
As a [kind of actor (who)]
I want to [do some task (what)]
So that [I can achieve some goal (why)]

User Interface requirements

• 간단한 스케치나 mockup을 사용
• 해당 화면에서 전, 후(behavior)로 이동하는 것만을 고려해서 그린다. 하나의 path를 그린다는 느낌

Design and Planning Doc

From sprint 2

System architecture

• High-level-architecture of system을 표현함
• 가능한 글보다는 시각적인 요소 사용하기
• pipe-and-filter, client-server, event-based, model-view-controller와 같은 일반적인 아키텍처 요소를 사용하기
• major interfaces between components을 기술. 더욱 자세한 것은 Design details에 적어야함.

Design details

• 아키텍처 수준이 아닌 것들 중에서 중요한 것들을 기술하기
• 알고리즘, 프로토콜, key invariant와 같은 사항들
• 주요 컴포넌트 간의 API를 명시해야한다.
  • format, data, order 등을 문서를 통해 알 수 있어야함.
• 현재 스프린트의 범위해 해당하는 것은 더욱 다음어서 작성, 다음 스프린트의 내용은 간략히
• 만약 계획과 다른 선택을 했다면 그러한 선택을 한 이유를 적어야 함.

Implementation plan

• 요구사항 정의서에 작성한 유저 스토리를 실제 개발 태스크로 쪼개서 작성하기.
• 개발에 소요될 시간을 예측하기(일 단위?)
• 태스크간의 dependency를 결정하기
• 최근 스프린트에서 완료된 태스크 나열하기, 진행할 태스크를 팀원들이 대략적으로 분배한 내용, 태스크당 소요시간, 태스크간의 dependency, 스프린트별로 태스크 분배한 것들을 작성해야 한다.
• 프로젝트가 겪을 수 있는 일반적인, 특별한 리스크를 생각해보고, 각 리스크에 어떻게 대처, 예방할 것인지 생각할 것

Testing plan

• 시스템을 어떻게 테스트할 것인가에 대한 계획을 설명.
• 어떻게 하면 최대한 테스트를 자동화 할 수 있을지 고민할 것.
  • Unit testing: 어떤 모듈에 대한 테스트 코드를 작성하고, 유닛 테스트를 실행할 것인가, 어떤 프레임워크를 사용할 것인가 표기
  • Functional testing: 어떤 API를 테스트 할 것인가? 어떻게? 어떤 툴을 써서? mock을 쓸 것인가 같은 질문에 대한 답을 적을 것.
  • Acceptance & integration testing: UI와 유저 시나리오를 어떻게 테스트할 것인지.

Registering Github Issues

• 각 태스크를 깃헙 이슈에 등록하고, 스프린트와도 연동해야 함(milestone을 이용하거나 다른 툴(Jira) 활용)
• 보통 풀리퀘스트 하나가 하나의 이슈에 대응된다. 풀리퀘스트가 해당 이슈를 해결하는 경우, 이슈를 닫음.

Revised requirements/spec and design documents

• 구현, 테스팅 계획(design doc)에 이미 완료한 내용들을 최신화.
• 이번 스프린트에서 구현할 기능을 선별하기. Add user stories (to the requirements document), task breakdowns (design doc), and assignments (design doc). 지난 스프린트에 완료하지 못한 태스크도 다시 확인하고 최신화하기
• Flesh out your list of possible features for future sprints (requirements document). Ideally, you should have a rough outline in place for all sprints. You will change this as we do each sprint, but having a general plan in place will be helpful to everyone involved.
• requirements, system architecture and design details 문서에 변동사항이 있는지 확인하기
• design document is current for the set of features
• Discuss design decisions that affect testing and describe any test interfaces built into the system (in the testing plan section).
• You must mark clearly the parts of the document that were changed (use the Changes section at the start of the document).