大崎的 Delivery #15

@ShinyaOzawa

15.1 導入

• 現場で実際に作業する人向け

• 継続的デリバリーを組織内でうまく機能されるための指針

– 構成管理、リリース管理

– リリースまで含めたライフサイクル

– リスク管理手法

– リスク、アンチパターンに役立つ手法

15.2 構成管理およびリリース管理の成熟度モデル

• モデル作ったぜ

– 図 15-1

15.2.1 成熟度モデルの使い方

• モデルを使う下記成果が得られる– 成熟度の判定

– 改善する分野の発見、改善

– 変更を実行し、計画することで劇的な変化

– 実行したら、ふりかえりで改善の余地を確認

– 上記ステップを繰り返し、経験を重ね広める

• 組織の改革は大変

– インクリメンタルに進め効果を測定することが大事

15.3 プロジェクトのライフサイクル

• チーム

– 形成期、争乱期、規範期、実行期、散会・再形成期

• ソフトウェア

– 発見期、開始期、構築期、開発・デプロイ期、運用期

15.3.1 発見期

• 戦略目標を立てるフェーズ

• 要件を取りまとめ、順位付けする投資対効果検討書が必要

• プロダクトオーナーが必要

15.3.2 開始期

• コードを書き始める前のフェーズ• 要件のとりまとめや分析• 作業の範囲、計画の概要を決める

– 投資対効果検討書– 概要レベルの機能、非機能要件– リリース計画– テスト戦略– リリース戦略– アーキテクチャ– リスク、問題点のトラッキング– 開発のライフサイクル– 全体スケジュール

• 全員の顔合わせが最重要

15.3.3 構築期

• 基本的なプロジェクトの基盤を確率するフェーズ

• 1-2 週間で実施

– PC、メール、リポジトリ

– バックログ作成

– ビルド、テストを含めたシンプルなプロジェクト作成

15.3.4 開発・リリース期

• イテレーティブでインクリメンタルな手順での開発、リリースをするフェーズ

• UAT 受け入れ試験

• スクラム失敗例

– コミットメントの欠落

– よい開発手法の虫

– イテレーティブをやる前に調整する

15.3.5 運用期

• いままでのフェーズが全部入り

• イテレーティブに開発、リリースする

15.4 リスク管理プロセス

• 主要なリスクの認識

• リスク削減戦略と管理

• 継続的なリスクの認識と管理

• 特性

– チームが状況報告する標準化された仕組み

– チームの進捗状況の定期的な更新と標準準拠

– マネージャーが現状を把握できる仕組み

– 外部からの定期的なリスクの監査

15.4.1 リスク管理入門

• リスク管理の一般的なモデル

– すべてのリスクを影響と可能性で分類

– 組み合わせで深刻度を判断する

15.4.2 リスク管理のタイムライン

• 開始、構築、開発フェーズを通して定期的に再考する

• 開始期の最後– リリース戦略

– 構築期の計画

• 構築期の最後– チームが開発を確実に始められること

• 開発・リリースのリスクの軽減– 開発計画を見る

– ふりかえりする

– 朝会する

リスク管理の実践法

• イテレーティブな開発最高！

• 問いかけリスト

– 進捗状況の管理方法は？

– 不具合を出さない方法は？

– などなど

• 危険な兆候を見つけることができる

15.5 デリバリーによくある問題 –その症状と原因

• ビルド・デプロイ・テスト・リリースの際に発生するありがちな問題

– 問題、症状、原因の tips

• なぜ？を 5 回繰り返す (TOYOTA?)

15.5.1 頻度の低いデプロイメント・バグのあるデプロイメント

• デプロイメント作業に長い時間がかかり、かつその手順が安定しない

• 症状・・・

• 原因

– 自動化されていない

– ハードウェアが不足している

– OS の設定が正しく管理されていない

– などなど

15.5.2 貧弱な品質のアプリケーション

• デリバリーチームが効率的なテスト戦略を実践できない

• 症状・・・

• 原因

– テスターとチームの連携ができていない

– 自動テストが不十分

15.5.3 管理が貧弱な継続的インテグレーションプロセス

• ビルドプロセスが適切に管理されていない

• 症状・・・

• 原因

– 自動テスト、コミットステージに時間がかかりすぎる

– CI プロセスを理解している人がいない

15.5.4 貧弱な構成管理

• 環境をうまく運用できず、自動プロセスによるアプリケーションのインストールを確実に行えない

• 症状・・・

• 原因

– 環境が異なっている

– 変更管理のプロセスが機能していない

– などなど

15.6 コンプライアンスと監査

• 規制に従う一般的な戦略

– 特権環境へのアクセス制御

– 変更管理、およびそのプロセス

– 管理職の許可

– 文書化の必須

– などなど

• めんどくなりがちだが、次のセクションでうまくいく原則と習慣を説明

15.6.1 文書化よりも自動化を

• デプロイの自動化をしよう

15.6.2 トレーサビリティを確保する

• バイナリ作成を一回だけにする

– 作成されたものを使い回す

• デプロイのテスト・リリースプロセスを完全に自動化する

15.6.3 サイロで作業する

• 部署間のコミュニケーションを密にする方法

– リリースワーキンググループ

– 定期的にふりかえり、改善策の検討、実施(PDCA)

– 頻繁にデモ環境にリリースする

– 現状の可視化

15.6.4 変更管理

• 変更の承認手続きを管理する手順– 変更諮問委員会– 変更管理プロセス下に置く環境– 変更リクエストを必ず通す– 変更後の問題と対策を立てる– 変更が成功したかどうか判断する基準を作成する– 変更適用するプロセスを自動化する

• 三つの原則– メトリクスを記録し、可視化する

– システムがうまく進んでいるかどうかを計測し、可視化する

– ふりかえりを定期的に開催し、システムを改善する

15.7 まとめ

• 管理作業はプロジェクトを成功させる上で不可欠

• イテレーティブでインクリメンタルなプロセス最高！

• 最後にひとこと

– デプロイメントパイプラインいいぜ

– P. 158