プログラミング学習 Day 11：Agile Scrum

Scrumはアジャイルのフレームワークの一部です。以下にメモを追加します。

■目的（概要）

- Scrum はアジャイル開発の軽量フレームワーク。短い期間で価値あるインクリメント（動く成果物）を継続的に届け、変化に適応することを目的とする。

役割（アカウンタビリティ）

- Product Owner（プロダクトオーナー）
  - プロダクトの価値最大化に責任を持つ。プロダクトバックログの作成・優先順位付け・ステークホルダー調整を行う。
- Scrum Master（スクラムマスター）
  - チームと組織が Scrum を正しく実践できるよう支援する。障害除去やファシリテーション、コーチングを行う。
- Developers（開発者／開発チーム）
  - クロスファンクショナル（設計・実装・テスト等を担える）で自己組織化されたチーム。スプリント中にインクリメントを作り上げる。

イベント（目的と性質）

- Sprint（スプリント）
  - 固定長の期間（通常 1〜4 週間）。スプリントは計画・実行・レビュー・振り返りのサイクルを1回まわす期間で、常に「完了した」インクリメントを生むことが期待される。
- Sprint Planning（スプリント計画）
  - スプリントで何を達成するか（スプリントゴール）と、どのバックログアイテムを取り組むか、そしてそれをどう遂行するかを決める会議（時間制限あり）。
- Daily Scrum（デイリースクラム）
  - 毎日最大15分。チームが前日の進捗と当日の計画、障害を共有し、必要な調整を行う短い同期の場。
- Sprint Review（スプリントレビュー）
  - スプリントで完成したインクリメントをステークホルダーにデモし、フィードバックを得てプロダクトバックログを更新する機会。
- Sprint Retrospective（スプリント振り返り）
  - チームがプロセスや協働の改善点を話し合い、次のスプリントで実行する改善策を決める場。

（各イベントは時間枠＝タイムボックスが定められる。例：1ヶ月スプリントなら Sprint Planning ≤ 8時間、Daily ≤ 15分、Sprint Review ≤ 4時間、Retrospective ≤ 3時間）

アーティファクトとその約束（Commitments）

- Product Backlog（プロダクトバックログ）
  - プロダクトに必要な要件や改善の優先リスト。Product Goal（プロダクト目標）がバックログのコミットメントとなる。
- Sprint Backlog（スプリントバックログ）
  - そのスプリントでチームが取り組むアイテムと作業計画。Sprint Goal（スプリントゴール）がコミットメントとなる。
- Increment（インクリメント）
  - スプリントの成果物の合計。Definition of Done（完了の定義）がインクリメントの品質基準の役割となる。

 Definition of Done（DoD）

- 「完了」と見なすための明確な基準（テスト、レビュー、ドキュメントなど）。DoD に合致して初めてインクリメントはリリース可能とみなされる。

スクラムの価値

 Commitment（コミットメント）、Courage（勇気）、Focus（集中）、Openness（開放性）、Respect（敬意）。これらの価値観がチームの行動を導く。

基本原理・実践指針

- 透明性（Transparency）：作業やプロセスを可視化する。
- 検査（Inspect）：定期的に実態をチェックする。
- 適応（Adapt）：問題があれば速やかに改善する。
- チームは自己組織化し、外部から作業を割り振られない。チームは責任を持って成果を出す。

スクラムの範囲と制約

- スプリント中はスプリントゴールを達成することが最優先。スプリントのスコープは原則として固定され、PO とチームの合意なしに軽々しく変更してはいけない。
- Scrum はフレームワークであり、見積もり手法や実務的なツール（ストーリーポイント、バックログの表現方法など）はチームが選ぶ。

成功のための実務的な指針

- スプリント長は短め（2週間が多い）にしてフィードバックを早める。
- PO は常にバックログの優先度を明確に保つ。
- 振り返り（Retrospective）で必ず改善を決め、次スプリントで実行する。
- DoD を全員で合意して守ることで品質を維持する。

CI/CD とテストフローを入れた DevOps 図

この DOT ファイルは、CI/CD パイプラインにテストとゲート（静的解析、単体テスト、カバレッジチェック、SAST、E2E）を組み込み、テストデータ管理、Manual QA、Canary 展開、監視→インシデント対応までを含む DevOps の全体像を表します。
dot -Tsvg devops_cicd_with_tests.dot -o devops_cicd_with_tests.svg
ファイル: `devops_cicd_with_tests.dot`

何を表現しているか

• 開発: リポジトリ、Issue、PR の発行 → PR 作成で CI が起動
• CI: Build → Static Analysis → Unit Test → Coverage → SAST → Artifact 発行（各ステップはゲート）
• CD/Test: Artifact を Integration/ステージング環境へ展開し、E2E 自動テストと Manual QA（必要時）を実行 → Canary 展開で本番へ段階的に昇格
• Monitor: 本番監視とアラート、インシデント対応、必要ならロールバックや Feature Flag による制御
• Traceability: Issue と PR の紐付け、モニタリング結果をバックログ化して改善に結びつける流れ

「CIでテスト・デプロイしやすい」小さな FastAPI サンプルアプリ

• devops_cicd_with_tests.dot のワークフロー（ビルド -> 静的解析 -> 単体テスト -> カバレッジゲート -> SAST -> アーティファクト発行 -> 結合テスト -> ステージングデプロイ -> E2E -> Manual QA -> Canary -> 本番昇格）を、GitHub Actions / GitLab CI / Jenkinsfile のテンプレートに落とし込みました。
• 各テンプレートにはゲート（失敗時の巻き戻し／PR へのフィードバック）、アーティファクトの受け渡し、手動承認（デプロイ前）などの実装例を含めています。
• カバレッジ判定や CodeQL/SAST のフック、テストデータプロビジョニングのプレースホルダを入れています。

ファイルごとに用途を短く説明

• app/main.py — FastAPI アプリ本体（/, /health, POST /max）
• requirements.txt — 開発・CI 用依存
• Dockerfile — 本番向けコンテナイメージ
• .dockerignore — Docker の除外
• tests/test_main.py — pytest による単体テスト
• pytest.ini — pytest 設定
• .github/workflows/ci.yml — GitHub Actions（テスト → イメージビルド → スモークテスト）
• README.md — 実行手順と CI の説明

ファイル

App/main.py
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from typing import List

class Numbers(BaseModel):
    numbers: List[int]

app = FastAPI(title="Sample FastAPI App", version="0.1.0")

@app.get("/")
def read_root():
    return {"message": "Hello from FastAPI sample app"}

@app.get("/health")
def health():
    return {"status": "ok"}

@app.post("/max")
def compute_max(payload: Numbers):
    """
    リクエスト例:
    { "numbers": [1, 5, 3] }
    レスポンス:
    { "max": 5 }
    """
    if not payload.numbers:
        raise HTTPException(status_code=400, detail="numbers must not be empty")
    return {"max": max(payload.numbers)}


requirements.txt
fastapi==0.95.2
uvicorn[standard]==0.22.0
pytest==7.4.2
httpx==0.25.0
coverage==7.2.6

Dockefile
# ベースイメージ
FROM python:3.11-slim

# 作業ディレクトリ
WORKDIR /app

# システム依存パッケージ（必要に応じて追加）
RUN apt-get update && apt-get install -y --no-install-recommends \
    build-essential \
  && rm -rf /var/lib/apt/lists/*

# 依存関係を先にコピーしてキャッシュを活かす
COPY requirements.txt /app/
RUN pip install --no-cache-dir -r requirements.txt

# アプリをコピー
COPY app /app/app
COPY . /app

# ポート
EXPOSE 8000

# 実行コマンド（本番は uvicorn をプロセスマネージャや ASGI サーバでラップ推奨）
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

.dockerignore
__pycache__
*.pyc
.env
.git
*.log
venv/

tests/test_main.py
from fastapi.testclient import TestClient
from app.main import app

client = TestClient(app)

def test_read_root():
    r = client.get("/")
    assert r.status_code == 200
    assert "message" in r.json()

def test_health():
    r = client.get("/health")
    assert r.status_code == 200
    assert r.json() == {"status": "ok"}

def test_compute_max():
    r = client.post("/max", json={"numbers": [1, 5, 3]})
    assert r.status_code == 200
    assert r.json()["max"] == 5

def test_compute_max_empty():
    r = client.post("/max", json={"numbers": []})
    assert r.status_code == 400

pytest.ini
[pytest]
minversion = 6.0
addopts = --maxfail=1 -q
testpaths = tests

.github/workflows/ci.yml
name: CI / Build / Test

on:
  push:
    branches: [ "main", "develop" ]
  pull_request:
    branches: [ "main", "develop" ]
  workflow_dispatch:

jobs:
  test:
    name: Run tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'

      - name: Cache pip
        uses: actions/cache@v4
        with:
          path: ~/.cache/pip
          key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}
          restore-keys: |
            ${{ runner.os }}-pip-

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

      - name: Run pytest
        run: |
          pytest

  build-and-smoke:
    name: Build Docker image and smoke test
    runs-on: ubuntu-latest
    needs: test
    steps:
      - uses: actions/checkout@v4

      - name: Build Docker image
        run: |
          IMAGE="sample-app:${{ github.sha }}"
          docker build -t $IMAGE .

      - name: Run container (background)
        run: |
          IMAGE="sample-app:${{ github.sha }}"
          CONTAINER_ID=$(docker run -d -p 8000:8000 $IMAGE)
          echo "::set-output name=container::$CONTAINER_ID"
          # wait for startup
          for i in {1..15}; do
            if curl -sSf http://localhost:8000/health >/dev/null 2>&1; then
              echo "app is up"
              break
            fi
            echo "waiting..."
            sleep 1
          done

      - name: Smoke test root endpoint
        run: |
          curl -sSf http://localhost:8000/ | jq

      - name: Stop container
        if: always()
        run: |
          docker ps -q --filter ancestor=sample-app:${{ github.sha }} | xargs -r docker stop

REAME.md
# Sample FastAPI アプリ（CI/CDフレンドリー）

このリポジトリは、CIでテスト／ビルド／Docker化しやすいサンプルの FastAPI アプリです。
主な内容:
- / : 確認用エンドポイント
- /health : ヘルスチェック
- POST /max : 数値リストを受け取り最大値を返す（例: `{ "numbers": [1,5,3] }` -> `{ "max": 5 }`）

使い方

1. ローカル実行（開発）
   ```bash
   python -m venv .venv
   source .venv/bin/activate
   pip install -r requirements.txt
   uvicorn app.main:app --reload --host 0.0.0.0 --port 8000
   ```

2. テスト実行
   ```bash
   pip install -r requirements.txt
   pytest
   ```

3. Docker イメージをビルドして実行
   ```bash
   docker build -t sample-app:local .
   docker run -p 8000:8000 sample-app:local
   ```

参考

- 公式 Scrum Guide（英語、最新）: https://scrumguides.org/
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

著者：松尾正信
株式会社京都テキストラボ代表取締役