Meeting Room
| Warning |
|---|
팀의 제품 관리자 인 Irwin은 모든 사람을 회의에 초대했으며 기분이 좋지 않습니다.
레이싱 게임의 리더 보드는 몇 가지 새로운 기능으로 업데이트되었으며 로컬 게임 그룹에서 이를 보여주었습니다.
플레이어의 반응은 가장 실망 스럽습니다.
그는 주요 문제의 목록을 읽습니다. - 일부 기능은 일부 게임 모드에서만 올바르게 작동합니다.
- 플레이어 수가 적더라도 리더 보드를 업데이트하는 데 시간이 너무 오래 걸립니다.
- 플레이어 당 여러 점수가 여러 플레이어로 표시됩니다.
- 새로운 순위 기능은 잘못된 결과를 반환합니다.
- 특정 날짜 나 게임 세션에 따라 점수를 그룹화 할 방법이 없습니다.
- 새 릴리스를 제작하는 데 몇 달이 걸렸습니다.
|
| 팀원 | 대화 내용 | 비고 |
|---|
 Image Modified
|
Irwin| "이러한 문제가 해결되기까지 얼마나 걸립니까?" |
|
Image Modified |
Andy | 그 코드를 작성하는 데 한 달이 걸릴 것입니다. |
Image RemovedAmita
|
Image Added | 이것을 테스트하는 데 적어도 일주일이 걸리며 Andy가 끝날 때까지 시작할 수 없으며, 그는 항상 |
새로운 즐기고 싶습니다| 들여오고 싶어합니다. |
|
Image Modified |
Tim환경을 설정하고 프로덕션 환경에 배포하는 데 최소 일주일이 걸립니다.
Amita가 끝날 때까지 시작할 수 없으며 그녀는 결코 릴리스 후보라고 부르지 않습니다. |
|
Image Modified |
Mara
Image RemovedAndy
|
Image Added | (주위를 둘러본다.)
"우리는 다시 연락 할 것입니다." |
Image Removed
|
Image Added |
IrwinImage RemovedAmita | "우리는 이러한 수정으로 인해 때 나도 몰라. 도움이 필요하지만 곧입니다 알고있다. 우리는 빠른 처리를 위해 설정되지 않은 것입니다. 또한 새로운 공간 게임 웹 사이트는이 문제가 해결 될 때까지 기다려야하며 게임이 빠르게 진행되고 있습니다." | |
|
DevOps 사례를 설정하는 첫 번째 단계는 현재 프로세스를 평가하는 것입니다. 이는 다음을 분석하는 것을 의미합니다. - 배포 패키지 및 NuGet과 같은 기존 아티팩트와 컨테이너 리포지토리.
- 기존 테스트 관리 도구.
- 기존 작업 관리 도구.
- 마이그레이션 및 통합 전략을 권장합니다.
Tailspin 팀과 함께 이를 수행하고 DevOps가 어떻게 도움이 될 수 있는지 살펴 보겠습니다. |
|
Image Added | "우리는 도움이 필요해요. 이 수정 사항이 언제 나올지는 모르겠지만 곧 예정되어 있습니다. 우리는 빠른 처리를 위해 준비되지 않았습니다. 또한 새로운 Space Game 웹 사이트는 이 문제가 해결 될 때까지 기다려야 할 것입니다. 그리고 그 게임은 빠르게 다가오고 있습니다." |
|
Image Added |
Image RemovedAndy | (Mara를 봐라 봅니다.) "이것은 처음 몇 주 동안 받아 들일 것이 많습니다." |
Image RemovedMara
|
Image Added | "어쩌면 여기서 어떻게 작동하는지 설명 할 |
수있을 개발자에서 프로덕션으로 Image Removed
|
 Image Added
|
Andy“좋은 질문입니다. 간단한 답변을 드릴 수 있을지 모르겠지만 시도해 보겠습니다. " "차한잔 할까요?" |
Image Removed
|
Image Added |
Andy Image Added
|
Image Removed
Irwin
Image Removed
Tim
 Image Added
 Image Added
|
Image RemovedMara
Cafeteria
Image Added
| Warning |
|---|
| title | 비공식 토론결과 다음과 같은 내용이 정리되었습니다. |
|---|
|
폭포 접근법을 - 폭포수 방법론을 사용합니다. 경영진이 우선 순위를 정합니다. 개발자는 코드를 작성하고 빌드를 QA에 전달합니다. 품질 보증팀은 배포를 위해 운영팀에 테스트를 진행합니다.
- 작은 팀에게는
폭포가 - 폭포수가 허용 될 수 있지만 여기서 목표는 명확하지 않으며 자주 변경되는 것 같습니다.
- 프로세스가 늦게까지 테스트가 지연됩니다. 즉, 버그를 수정하고 변경하는 것이 더 어렵고 비용이 많이 듭니다.
- "완료"의 의미에 대한 명확한 정의는 없습니다. 각 팀원은 각자의 아이디어를 가지고 있습니다. 모든 사람이 동의하는 전반적인 비즈니스 목표는 없습니다.
- 일부 코드는 중앙 집중식 버전 제어 시스템에 있습니다. 많은 도구와 스크립트는 네트워크 파일 공유에만 존재합니다.
- 많은 수동 프로세스가 있습니다.
- 커뮤니케이션은 우연히 일어날 수 있으며 전자 메일, Word 문서 및 스프레드 시트에 따라 다릅니다.
- 피드백도 드물고 일관성이 없습니다.
- 좋은 점은 팀이 잘
지내고있는 |
Image RemovedMaraImage Added
| (DevOps 접근 방식이 팀의 많은 문제를 해결할 것이라고 확신하지만 그녀의 사례를 팀에 제시 할 방법이 필요하다고 생각합니다.) "Value |
Steam Stream Mapping 연습을 수행 한 적이 있습니까?" |
Image Removed
|
Image Added |
AndyImage RemovedAmita
|
 Image Added
| (한숨을 쉽니다.) |
Image RemovedTim
|
Image Added | "더 많은 서류 작업이 필요하지 않습니다." |
Image RemovedMara
|
Image Added | "알겠습니다. |
제게 Image Removed
|
Image Added |
AndyImage Removed
Irwin
Image Added Image Added |
Image RemovedTim 처리하게되어 | 처리하게 되어 기쁘다. 모두가 일하러 돌아간다.) |
|