일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 31 |
- write by GPT-4
- Java
- 자바
- 역학
- oracle
- chatGPT's answer
- 소프트웨어공학
- kotlin
- python
- lombok
- 고전역학
- 유닉스
- 자바암호
- Database
- 자바네트워크
- GPT-4's answer
- Spring Batch
- 웹 크롤링
- android
- JVM
- 파이썬
- 인프라
- Spring boot
- write by chatGPT
- NIO
- GIT
- 시스템
- 뉴턴역학
- 리눅스
- 코틀린
- Today
- Total
목록소프트웨어공학 (62)
Akashic Records
이터레이션을 계획하기 위해서는 팀 전체가 이터레이션 계획 회의에 참석해야 한다. 모든 개발자 뿐만 아니라 고객도 회의에 참석해야 한다. 회의에서는 스토리들을 좀더 세부적으로 살펴볼 것이므로 여러 가지 의문이 생길 것이다. 이러한 물음에 답할 수 있는 고객이 곡 참석해야 한다...
대부분의 소프트웨어 프로젝트에서는 두 달에서 여섯 달마다 새로운 릴리즈를 내놓는 것이 가장 좋다. 웹사이트 프로젝트 같은 경우는 이보다 더 자주 릴리즈하는 경우도 있다. 향후 몇 차례의 릴리즈에 포함될 주용 내용을 정리한 제품 개발 로드맵이 있다면 그것을 바탕으로 릴리즈 계..
목적 스토리로 시작하라 대규모 프로젝트, 특히 사용자 역할이 많고 다양한 프로젝트는 스토리 식별에 있어 막막한 경우가 있다. 이럴 때는 한번에 하나씩 사용자 역할을 선택하여 그 사용자가 새 시스템을 사용하는 주 목적을 식별하는 것이 가장 효과적이다. 케이크 자르듯 나누어라 큰..
인수 테스트를 작성하는 이유 중 하나는 고객과 개발자가 대화를 나누는 과정에서 언급된 세부사항들을 나타내기 위함이다. 사용자 스토리에서는 세부사항을 테스트로 표현한다. 나중에 무엇을 테스트할지에 관한 짧은 메모를 스토리 카드 뒷면에 짧게 적어 놓는다. 향후 만들어지는 테..
사용자가 소프트웨어에 원하는 바를 다른 사람이 짐작할 수도 있지만, 실제 사용자만이 정확히 알 수 있다. 하지만 제품에 대해 다양한 의견을 내줄 실제 사용자를 확보하지 못한다면, “대리 사용자(User Proxy)”에 의존해야 할 것이다. 대리 사용자는 실제 사용자는 아니지만, 프로젝트상..
요구사항 그물질(trawling) 스토리 수집을 위한 요구사항 도출은 어부들의 그물질에 비유된다. 처음 그물질은 요구사항의 바다에서 성긴 그물을 이용해 큰 것(비즈니스 가치가 큰 것)들을 잡는다. 다음 단계에서 조금 촘촘한 그물을 이용해 보다 작은 것들을 잡는다. 이를 반복한다. 요구사..
많은 프로젝트에서 오직 한 유형의 사용자만 존재하는 것처럼 스토리를 작성하는 경우가 많다.모든 스토리가 그 사용자 유형의 관점에서만 작성된다. 그러나 이런 식으로 단순화하는 것은 잘못된 생각이며, 자칫 시스템 주요 사용자 유형에 포함되지 않는 사용자들에게 필요한 스토리를 ..