소프트웨어 개발 및 관리를 공식화하기 위한 권장 사항

  • 아티클

이 Azure Well-Architected Framework 운영 우수성 검사 목록 권장 사항에 적용됩니다.

OE:03 소프트웨어 아이디어 및 계획 프로세스를 공식화합니다. 기존 산업 및 조직 표준에서 가져옵니다. 우선 순위가 지정된 공통 백로그와 충분히 자세한 사양을 사용합니다. 결과에 따라 계획 프로세스의 지속적인 개선을 추진합니다.

이 가이드에서는 설정된 표준에 따라 소프트웨어 개발 사례를 관리하기 위한 권장 사항을 설명합니다. 고품질 소프트웨어를 생산하는 팀의 능력은 개발 계획에 대한 구조적이고 협력적인 접근 방식에 의존합니다. 제품 소유자와 관리자는 개발자가 개발 주기에서 언제든지 수행하는 작업을 이해 관계자에게 명확하게 이해하고 명확하게 설명할 수 있어야 합니다. 반대로 개발자는 잘 작성된 기능, 사용자 스토리 및 수용 기준을 통해 개발 주기의 목표를 이해해야 합니다. 확립된 표준은 개발 사례를 수행하는 방법을 정의하고 워크로드 팀이 효과적으로 협업할 수 있도록 하여 목표와 기대에 대한 혼란의 위험을 줄입니다.

주요 디자인 전략

소프트웨어 개발 사례를 공식화하여 제품 소유자, 프로젝트 관리자 및 개발자가 각 스프린트의 목표를 이해하고 관련자에게 일관된 품질을 제공할 수 있도록 합니다. 개발 사례에 대한 지침을 검토하려면 연속 통합 가이드를 참조하세요.

개발 계획 표준

  • 공동 작업: 워크로드에 대해 제안된 변경 내용을 정의하는 프로세스는 공동 작업이어야 합니다. 워크로드에 대한 대부분의 변경 내용은 여러 함수 및/또는 구성 요소에 영향을 주므로 가능한 한 많은 워크로드 팀 구성원이 참여하면 중요한 고려 사항을 놓치지 않고 모든 사람이 특정 도메인에 미치는 영향을 인식하는 데 도움이 됩니다. 또한 협업은 변경의 scope 명확하게 정의하고 변경 내용을 수행하는 데 필요한 작업을 잘 정의된 작업 항목으로 나누는 방법을 명확하게 정의하는 데 도움이 되며, 도메인 간에 전문 지식을 갖춘 더 큰 그룹은 필요한 작업에 대한 경험 지원 예상을 제공할 수 있습니다.

  • 도구: Agile, 스크럼 및 Kanban 보드와 같이 업계에서 검증된 확립된 도구와 프로세스를 사용합니다. 고유한 도구와 프로세스를 개발하는 것은 워크로드에 소요될 수 있는 시간과 개발 주기를 수행하는 중요한 작업입니다. 대부분의 숙련된 DevOps 엔지니어와 제품 소유자는 이러한 유형의 도구와 프로세스에 익숙하므로 채택의 학습 곡선을 최소화해야 합니다. 마찬가지로, 신입 사원을 위한 온보딩 프로세스는 이미 동일한 도구와 프로세스에 어느 정도 노출될 가능성이 높기 때문에 표준 도구와 프로세스를 사용하는 이점을 누릴 수 있습니다.

절충: 지나치게 규범적인 경우 Agile 방법론이 너무 엄격해질 수 있습니다. 잘 정의된 표준과 혁신 간의 균형을 맞추기 위해 노력합니다.

  • 배포: 자주 사용되지 않는 대규모 배포 대신 자주 작고 반복적인 배포를 사용하도록 계획합니다. 이 방법을 사용하면 프로젝트 관리 관점에서 사용자 스토리 및 작업 항목을 관리하기 쉽게 유지하고 배포가 실패할 때 대규모 문제의 위험을 줄이는 데 도움이 됩니다.

  • 용어: 테스트, 설명서 및 접근성 기능을 비롯한 지원 기능이 성공적으로 완료되도록 완성 된 개발 주기에 대한 정의를 표준화합니다.

  • 통신: 제품 소유자 및 프로젝트 관리자를 위한 표준 프로토콜을 정의하여 향후 릴리스를 내부 및 외부적으로 홍보합니다. 예를 들어 향후 릴리스에 대한 외부 당사자와 통신하기 위한 표준을 설정할 수 있습니다. 표준은 릴리스 2주 전에 통신을 보내야 하며 릴리스 24시간 전에 미리 알림을 보내야 한다고 지시할 수 있습니다.

  • 사용자 스토리: 사용자 스토리에 대한 템플릿을 표준화합니다. 각 사용자 스토리가 최종 사용자의 관점에서 작성된 개별 작업 단위인지 확인합니다. 잘 작성된 사용자 스토리에는 다음과 같은 특성이 있어야 합니다.

    • 각 사용자 스토리는 서로 완전히 독립적이어야 합니다. 사용자 스토리를 서로 독립적으로 유지하면 겹치는 작업과의 혼동을 방지하고 팀이 지정된 사용자 스토리에 대한 작업이 다른 사용자 스토리의 작업에 의존하는지 여부를 이해하는 데 도움이 되며, 이는 예약 및 우선 순위 지정에 도움이 됩니다.

    • 각 사용자 스토리는 협상할 수 있습니다. 최종 사용자 및 워크로드 팀 구성원의 관점은 짧은 시간 동안 수행할 수 있는 현실적인 사용자 스토리를 캡처하는 데 필수적입니다.

    • 사용자 스토리는 최종 사용자에게 중요합니다. 최종 사용자의 관점에서 사용자 스토리를 작성할 때 사용자가 보고자 하는 변경 내용을 캡처하여 환경에 가치를 더합니다. 사용자 스토리가 작업 항목으로 세분화될 때 이 초점을 유지하면 각 배포가 향상된 환경을 제공하는 데 도움이 됩니다.

    • 사용자 스토리에 필요한 노력은 높은 신뢰도로 수집할 수 있습니다. 지정된 사용자 스토리에 필요한 시간을 근사화할 수 없으면 계획이 어렵고 마감일 누락 가능성이 증가하여 잠재적으로 다른 계획된 작업에 연속적인 영향을 미칠 수 있습니다.

    • 잘 작성된 사용자 스토리는 작으므로 몇 주 내에 완료할 수 있습니다. 범위가 작은 스토리는 수집 가능하고 관리하기 쉬운 상태로 유지하고 작업 항목을 달성 가능하게 유지하는 데 도움이 됩니다.

    • 사용자 스토리는 테스트할 수 있어야 합니다. 기능이 제공되었는지 테스트할 수 없으면 최종 사용자는 목표가 달성되었다는 확신을 가질 수 없습니다. 지정된 사용자 스토리에 대해 테스트가 아직 작성되지 않은 경우에도 기능 제공을 증명하기 위해 테스트를 개발하는 방법을 명확하게 이해해야 합니다.

  • 수락 조건: 수락 조건에 대한 템플릿을 표준화합니다. 수락 기준이 특히 사용자 스토리와 관련이 있고 하나 이상의 수용 테스트를 사용하여 명확하게 입증될 수 있는지 확인합니다.

  • 추적: 개발 프로세스를 추적할 수 있는지 확인합니다. 프로덕션 워크로드의 상태와 관련 코드를 품질 보증 테스트, 수용 기준, 사용자 스토리 및 기능으로 명확하게 추적해야 합니다. 자세한 추적은 예를 들어 의료와 같은 경우에 규정 요구 사항일 수도 있습니다.

  • 검토: 개발 주기 회고 및 사후 평가를 통해 개발 사례에 대한 내부 감사를 정기적으로 수행합니다. 프로세스 리플렉션은 흠이 없어야 하며 개선 사항으로 적용할 수 있는 학습에 집중해야 합니다. 팀이 필요한 작업을 정의하는 데 사용자 스토리 및 태스크가 얼마나 효과적인지, 그리고 시간 예측의 정확도를 반영했는지 확인합니다.

  • 보고서: 변경에 초점을 맞춘 유용한 메트릭을 제공하는 관련자를 위한 보고서를 표준화합니다. 변경에 집중하면 제품 가속 및 감속을 추적할 수 있습니다. 유용한 메트릭에는 다음의 변경 내용이 포함될 수 있습니다.

    • 채택의 월별 증가율입니다.

    • 성능.

    • 학습 시간.

    • 인시던트 빈도입니다.

    보고는 개인의 작업을 평가하는 도구로 사용해서는 안 되므로 각 엔지니어의 스토리 포인트 또는 코드 줄과 같은 메트릭을 피하십시오.

Azure 촉진

Azure Boards 팀이 전체 개발 프로세스에서 작업을 계획, 추적 및 논의할 수 있는 웹 기반 서비스입니다. Agile 기반 개발 사례에 적합합니다.

GitHub Projects는 GitHub 에서 문제 및 끌어오기 요청을 사용하여 프로젝트를 구성하고 통합할 수 있는 사용자 지정 가능한 프로젝트 관리 도구입니다.

운영 우수성 검사 목록

전체 권장 사항 집합을 참조하세요.

운영 우수성 검사 목록