출처: 스프링5와 Vue.js 2로 시작하는 모던 웹 애플리케이션 개발
Application Requirements
- 애자일 방식으로 요구사항 관리하기
- 효율적인 사용자 스토리 작성하기
- 와이어프레임 작성하기
- 애자일 이해하기
- 어떤 프레임워크를 쓸 것인가?
Managing requirements like Agile
폭포수 프로젝트(waterfall project)
순차적으로 소프트웨어 개발 프로세스를 진행하는 것. 따라서 안정적으로 개발에 임할 수 있다.
애자일 프로젝트(agile project)
변화하는 상황에 맞게 유연하게 소프트웨어 개발 프로세스를 진행하는 것. 따라서 버그를 더 빨리 발견할 수 있고 서비스도 빨리 출시할 수 있다.
요구사항단계
Software Requirements. 3판. Karl Wiegers and Joy Beatty
소프트웨어 요구사항은 비즈니스, 사용자, 기능으로 나누어진다
- 비즈니스 요구사항: 조직의 상위 수준의 비즈니스 목표, 조직이 해당 시스템을 구축해야 하는 이유, 비즈니스에 어떤 이점이 있는지 등.
- 사용자 요구사항: 사용자가 시스템으로 수행할 수 있는 작업을 정의한다. 유스케이스나 사용자 스토리로 작성이 가능하다.
- 기능 요구사항: 사용자 요구 사항에 정의된 작업을 사용자가 수행할 수 있는 방법에 관한 시스템 동작을 명시한다.
Writing an effective user story
Tips
- 작성법: <사용자 유형>으로서, 나는 <어떤 가치 얻기>를 할 수 있도록, <어떤 것 하기>를 원한다.
example) 등록된 사용자로서, 나는 애플리케이션에 로그인할 수 있도록, 나의 사용자 이름 또는 이메일 주소와 비밀번호를 활용할 수 있다. - End-To-End checking: 사용자에게 끝을 잇는 서비스를 제공할 수 있는지 확인한다.
example) 하나의 사용자 스토리는 가입 폼을 작성하는 것에 관한 것이고 또 다른 사용자 스토리는 첫 번째 사용자 스토리를 완료했을 때 가입 폼에 제공된 세부사항으로 사용자 계정을 생성하는 것과 관련된 것이라면 사용자는 사실상 가입 액션을 수행할 수 없다. 이러한 사용자 스토리 사용자가 어떤 것을 성취할 수 있는 기능을 제공하지 않는다. - 사용자 스토리는 최대한 작고 실행 가능하게 유지한다.
bad example) 보드 멤버로서, 나는 카드를 관리할 수 있다.
good example) 보드 멤버로서, 나는 카드를 생성할 수 있다. 보드 멤버로서, 나는 카드를 보관할 수 있다. - 사용자 스토리에 허용기준을 추가한다.
example) 이메일 주소가 시스템에 이미 존재해서는 안된다. - 사용자 스토리에 인터페이스를 포함하는 것을 피해야 한다.
- 사용자 스토리를 그룹화하기 위해 테마를 사용한다.
- 사용자 스토리를 참조하기 위해 숫자 대신 짧은 제목을 사용한다.
Writing a wire frame
사용자 스토리는 논의의 시작점일 뿐이다. 예를 들어 로그인하기 스토리를 볼 때 각 입력 필드에 플레이스홀더를 추가해야 할지, 라벨을 달아야 할지, 라벨을 왼쪽에 둘지 오른쪽에 둘지 결정해야 한다. 따라서 와이어프레임을 작성해 모든 사람이 어떻게 구축해야 할지 이해하는데 도움을 주어야 한다.
Understanding agile
scrum, extreme programming, lean, kanban 등이 애자일에 대한 개념이다. 여기서는 생략한다.
애자일 선언문
- 공정과 도구보다 개인과 상호작용을
집단지성을 통해 팀원과의 생각을 공정과 도구보다 중요하게 여긴다. - 포괄적인 문서보다 작동하는 소프트웨어를
애자일에 문서가 없어야 한다는 것이 아니라 포괄적일 필요가 없는 문서를 작성하여 중요한 부분만을 검증한다. - 계약 협상보다 고객과의 협력을
계약에 얽매이는 것이 아닌 고객과 함께 같은 목표를 향해 나아가는 것. - 계획을 따르기보다 변화에 대응하기를
계획을 위한 노력은 실패시 리스크가 크다. 체계적으로 유지하는 것도 힘이 든다. 하지만 변화는 필연적이다.
code plan - planing considering stablility and scalability
agile code plan
Robert C. Martin. clean software: agile principles and pattern, and ways to practice
소프트웨어 프로젝트의 설계는 추상적인 개념으로, 각 모듈, 클래스, 메소드의 구체적인 형태와 구조뿐만 아니라 프로그램의 전체 형태와 구조와도 관련돼 있다. 이것은 다양한 매체로 표현될 수 있지만, 최종적인 구현은 소스 코드가 된다. 결국 소스 코드가 바로 설계다.
The stage of code plan
- architecture
시스템이 멀티 레이어 설계를 사용하는가?
모놀리식 서비스인가, 아니면 마이크로 서비스를 사용하는가?
서브 시스템은 무엇이며 SOAP이나 REST, AMQP를 사용해 어떻게 통신하는가?
서드파티 시스템과의 상호작용이 있는가? 서드파티 시스템과는 어떻게 통신하는가? - abstarct
설계는 서브 시스템의 패키지와 주요 컴포넌트에 중점을 두고 상위 수준의 설계로 유지해야 한다. 추상화 설계를 보고 서브 시스템의 구조와 주요 로직을 이해할 수 있어야 한다. - Realization
구현 단계에서는 클래스, 주로 필드와 메소드의 구현에 중점을 둔다. 구체적이고 하위 수준의 세부사항을 채운다.
집의 설계와 비교해보면 아키텍처는 뼈대와 같다. 일단 짓고나면 변하지 않는다. 추상화는 그 집의 벽과 같다. 때로는 큰 방을 2개의 방으로 나누기 위해 벽을 추가하거나 더 많은 공간을 만들기 위해 벽을 무너뜨릴 수 있다. 구현은 가구, 카페트, 벽지 등 작고 이동가능한 모든 항목과 같다.
