회고를 통해 성장형 사고방식 구축

회고는 실험, 테스트, 학습, 공유, 성장 및 역량 강화와 같은 성장 사고 방식의 원칙을 강화합니다. 또한 팀 구성원이 현재 프로젝트에서 직면한 과제를 공유하고 팀이 지속 가능한 성장을 창출할 수 있는 권한을 부여할 수 있는 안전한 장소를 제공합니다.

회고 구조

마이그레이션 프로젝트에 대한 회고 회의 중에 팀의 각 구성원은 세 가지 기본 질문에 대한 자신의 생각을 공유할 것으로 예상됩니다.

회고는 릴리스 또는 반복의 끝을 표시합니다. 팀은 경험을 얻고 교훈을 배우면서 릴리스 및 반복 백로그를 조정하여 테스트할 새로운 프로세스와 실험을 반영합니다. 마이그레이션 프로세스를 통해 다음 반복을 시작합니다.

다음 마이그레이션 웨이브를 관리하는 팀은 마이그레이션을 지속적으로 개선하기 위해 배운 교훈을 적용해야 합니다.

마이그레이션 회고를 시작하려면 몇 가지 사항이 필요합니다.

이끌이: 프로세스 전체에서 이끌이 또는 코치 역할을 하는 팀 구성원입니다. 이 팀 구성원은 회고 과정을 통해 팀을 안내하는 데 중점을 두고 모든 아이디어를 듣고 캡처하도록 합니다.
추적하고 구성하는 방법: 시각적으로 아이디어를 추적하고 구성하는 방법입니다. 스티커 메모, 가상 화이트보드 또는 DevOps 도구가 있는 실제 화이트보드일 수 있습니다.
범위가 지정된 질문: 다음 세 가지 질문으로 추적 시스템을 구성하려고 합니다.
- 잘 진행되었나요?
- 무엇이 더 좋았을까요?
- 어떤 점을 학습했나요?

이전 단계를 완료한 후 팀과 함께 다음 단계를 수행합니다.

개별 답변: 각 팀 구성원이 "무엇이 잘 되었나요?"라는 질문에 대답하고 답변을 문서화해야 합니다.
- 실제 보드를 사용하는 경우 각 팀 구성원이 보드의 답변을 채우도록 합니다.
- 디지털 보드를 사용하는 경우 각 구성원이 도구를 통해 답변을 채우도록 합니다.
이끌이 읽기: 각 팀 구성원이 자신의 생각을 문서화한 후 이끌이는 피드백을 검토한 다음 팀에게 소리내어 읽어야 합니다.
- 동시 추세를 인식할 수 있도록 유사한 아이디어를 발견할 때 그룹화해야 합니다.
- 이러한 생각을 구성하는 데 도움이 되도록 필요에 따라 레이블 또는 부모 항목을 만듭니다.
- 다른 영역에 속한 위치가 잘못된 항목을 찾으면 현재 해당 항목 위로 이동합니다.
"무엇이 더 좋았을까요?"에 대해 이 프로세스를 반복합니다.
- 이 과정에서는 사람들이 사람, 프로세스 및 기술과 관련된 특정 과제에 대해 논의하도록 장려합니다. 이는 열린 공간이어야 합니다.
- 마이그레이션으로 인해 지연이 생성되었거나, 릴리스에 영향을 주거나, 워크로드가 이 스프린트에서 푸시되는 원인을 확인해 보세요.
- "우리가 무엇을 배웠는가?"라는 질문에 대해 논의할 때 이러한 문제를 어떻게 방지할 수 있는지 생각해 보십시오.

이러한 질문에서 아이디어를 캡처하고 그룹화한 후 팀에 "무엇을 배웠습니까?"라고 묻습니다. 그런 다음 다음 스프린트에 적용할 수 있는 개선을 위한 아이디어를 브레인스토밍합니다.

다음 예제 회고 출력을 고려합니다.

잘 진행되었나요?	무엇이 더 좋았을까요?	어떤 점을 학습했나요?
Application X 및 Application Y에 대한 비즈니스 사용자와의 통신(5표)	Application X 및 Application Z에 대한 네트워크 아키텍처의 유효성을 검사하는 개발자의 참여(3표)	특수 규칙이 없다고 생각되더라도 마이그레이션 전에 워크로드의 모든 방화벽 트래픽을 검토해야 합니다. (4표)
Application Y용 개발 팀은 매우 참여했습니다. (2표)	Application X에 대한 네트워킹 요구 사항 이해(2표)	개발 팀이 마이그레이션 프로세스의 일부로 예상한 내용을 알 수 있도록 해야 합니다. (4표)
마이그레이션 프로세스의 일부로 Azure Backup을 사용하도록 설정합니다.	애플리케이션 Y에 대한 네트워킹 요구 사항 이해(1표)	대규모 SQL 데이터베이스에 대한 추가 시간을 계획해야 합니다. (3표)

Azure에서 워크로드를 지속적으로 기본 확보하고 최적화할 수 있도록 Azure의 관리 방법론에 대한 클라우드 채택 프레임워크 계속 구현해야 합니다.