Skip to content

Latest commit

 

History

History
166 lines (115 loc) · 15.4 KB

README.ja.md

File metadata and controls

166 lines (115 loc) · 15.4 KB
Raw

Multi-team Software Delivery Assessment

Multi-team Software Delivery Assessmentは、組織内のさまざまなチームのソフトウェア・デリバリーを評価するためのシンプルで実行しやすい手法です。 　　　　

この評価手法は、よく知られ実績のあるSpotify Squad Health Check modelを基にしており、以下合計6つの観点をカバーしています。

  1. Team Health
  2. Deployment
  3. Flow
  4. Continuous Delivery
  5. Operability
  6. Testing and Testability

これら6つの観点は、最新のソフトウェア・デリバリーのすべての重要事項を網羅していて、チームがそれぞれの長所とプラクティスを自己評価できます。

🚀 概要: Continuous Delivery at scaleのスライド32〜38を参照してください。

Copyright © 2018-2019 Conflux Digital Ltd

Licenced under CC BY-SA 4.0 CC BY-SA 4.0

Permalink: SoftwareDeliveryAssessment.com

評価の目的

ソフトウェアシステムを構築および実行するためのポジティブな作業環境の促進、および維持することが評価の目的です。
ポジティブな作業環境では、以下の状況が発生します。

  • ソフトウェアの変更は、継続的デリバリーの手法を使用して、迅速かつ安全にビルドされ、テストされ、プロダクション環境にリリースされる。
  • プロセスとプラクティスは、リリースに向けたソフトウェアの変更フローに最適化される。
  • ソフトウェアは、1つ１つ分断されたシステムに対して独立、分離したリリースができるように設計および構築される。
  • ソフトウェアは、運用性、テスト容易性、およびリリース容易性を考慮して設計および構築される。
  • ソフトウェアプロダクト、ソフトウェア生産過程での問題が、顧客やユーザーが気付く前に常にチームによって検出される。
  • 開発者がソフトウェアの変更に対する責任と説明責任を持ち、開発者のエンパワーメントとオーナーシップに繋がる。
  • ソフトウェア開発が、やりがいのあり、楽しいものになる。
  • 悪い慣習と悪いアプローチに挑み、変えること に自信が持てるようになる。

基本的にMulti-team Software Delivery Assessmentはチームを解放して活性化し、チームが成功するのに役立ちます。この評価手法は、様々な改善点を特定することにより、チームがソフトウェアシステムの構築、テスト、およびリリースを改善するのを手助けします。
改善点には、以下があります。

1.チーム中心の改善点
2.製品中心およびサービス中心の改善点
3.組織全体の改善点

この評価手法は、チームにペナルティを科すために使用するべきではなく、プラクティスと品質の改善に向けて、共有される意欲を提供するために使用するべきです。

評価対象のチーム

アプリケーションソフトウェアまたはインフラストラクチャのコード、スクリプトの作成、またはそれらの設定を行うすべてのチームが評価対象となり、評価することでメリットがあります。
評価対象のチームは以下になります。

  • ユーザー向け-のWebサイトとサービス、顧客向けのWebサイトとサービスを構築するチーム
  • 内部サービスを構築するチーム
  • 他のシステムをサポートするインフラストラクチャを構築するチーム（プラットフォームチームを含む）
  • ビルド とデプロイメントツール、スクリプトを構築するチーム
  • ソフトウェアおよびインフラストラクチャの一部としてCOTS製品を構成およびテストするチーム
  • その他、ソフトウェアおよびインフラストラクチャの構築、構成、およびテスト に主眼をおくチーム

"チーム"とは、人材連携の度合いの大きい6-10人のグループを意味します。通常、Squad、Scrumチーム、Productチーム、または Stream-alignedチームと呼ばれます。

評価基準

各観点の評価基準は、既存の出版された書籍、およびオンラインソースから取得しています。

評価の実行方法

評価セッション自体は、チームのふりかえりのように実施する必要があります。通常のふりかえりとの主な違いは、評価セッションではファシリテーターが議論をよりしっかりと導くことです。議論する多くの質問があり、チームが利用可能な時間内にすべての評価基準を議論することが重要です。

評価セッションの終わりには、チームは議論に基づいて、プロセスとプラクティスを改善するためにどのようなアクションを実行するかの決定を促され、エンパワーメントされたと感じる必要があります。

評価の実行頻度

多くの組織では、評価セッションを3か月ごとに 実行すると、良い結果が得られることがわかっています。

評価のための準備

  1. 評価セッションのファシリテーターを見つけます。これは、チームのふりかえりに精通しているチーム外の人でなければなりません。
  2. 時間を2時間、チームに対して大きめのミーティングルームを確保します。
  3. 既製のA1 PDF（リリースを参照）を使用するか、可能であればA1サイズで、以下の個々の評価ページ（小さなマージンを使用）を使用して、各観点の評価シートを印刷します。
  4. 詳細ページをガイドとして印刷（またはページを画面上で開く）して、各評価基準のコンテキストと詳細を理解します。
    1. Team Health
    2. Deployment
    3. Flow
    4. Continuous Delivery
    5. Operability
    6. Testing and Testability
  5. マーカーまたはホワイトボードマーカーをたくさん用意してください。赤、青、緑が最適です。
  6. セッションにふりかえりのファシリテーションに精通している人（おそらくスクラムマスター）を含めます。 チームのファシリテーター以外の人は、セッション中にファシリテーターから学習し、後に他の評価セッションでファシリテートできるようになります。

ファシリテーター

ファシリテーターは、セッションを実行する前にSpotify Squad Health Checkのアプローチに慣れる必要があります。優れたレポートとして、How I Used the Spotify Squad Health Check Model、SkyBet Squad Health Checksで公開されており、また、SpotifyからSquad Health Checkの説明文書(PDF) がダウンロードできます。

評価セッション中に実施すること:

  • いくつか議題が長引く場合は、セッションの外でディスカッションを行うように依頼して、セッションがスケジュール通り進むようにします。
  • 印刷された評価シートにチームのスコアとメモを書き留めます。
  • 完成した評価シートの写真を撮ります。
  • エンジニアリング評価の意義と実施結果についてチームからフィードバックを受け取ります。 - 笑顔で十分です。

時間調整

チーム評価セッションは2時間で実行され、ファシリテーターは6つの観点の質問を通して、セッションをファシリテートします。

  1. Team health check - 35分
  2. Deployment health check - 10分
  3. Flow check - 10分
  4. Continuous Delivery check - 20分
  5. Operability check - 20分
  6. Test coverage check - 20分

これら6つの評価の間に5分の休憩を挟みます。

評価セッションの実行

各セクションにはいくつかのルールがあります。各質問には以下の記載事項を意識して回答する必要があります。

  • チームは、個人またはチームとして、Tired and Inspired ガイドラインに基づいて、SAD（1 OR 2）/MEH（3）/ YAY（4 OR 5） を使用して各評価基準を評価します。

    • Tired (しんどい) は評価が低く (1), Inspired (すばらしい) は評価が高い (5) です。　　　　

    • 個人ごとに評価した場合は、評価を集計し、1-5の単一のチームスコアを決定します。印刷されたシートに異なる色のペンを使用して、異なる評価を視覚的に示すと便利です。

  • 過去に評価を実施している場合は、前回のスコアに対するトレンド を決定します。(上がった, 変わらない, 下がった)

  • 今後数カ月にわたり、評価基準のスコア改善することに同意します。

  • メモ欄を使用して、評価のまとめ役が知る必要があると思われる詳細情報を示します。

  • 各シートの下部にある 日付/名前/ファシリテーター 欄に必ず情報を記入します。

  • 記入済みの各シートの写真を撮り、評価のまとめ役に送信します。

  • チームメンバーに次の観点から評価セッション自体を評価してもらいます： 価値、実行 （悪い、まあまあ、良い）

ファシリテーションを促進する

各チームの評価セッションには、ファシリテーターから学習している人物が参加しているため、今後のセッションをファシリテートすることができます。新しいファシリテーターはそれぞれ、少なくとも2つの他のチームとのセッションをファシリテーションする必要があります。このようにして、ファシリテーターの数は急速に拡大し、最初のファシリテーターの負担を最小限に抑えることができます。

結果の調整と解釈

各チームが評価セッションを実行して結果を送信した後、評価のまとめ役は異なるチームの結果を照合し、組織全体で改善が必要な領域を特定する必要があります。
改善が必要な領域を特定するには、次のような質問をします。

  • チームABCがテストカバレッジについて1と評価するのは何故ですか？ スコアの上昇を妨げているものは何ですか？

  • より多くのチームのリリースを支援するために、組織として何ができますか？

  • チームがよりよく、効率良く作業できるようにプラットフォーム側が改善するべき点はありますか？

チームを直接ランク付けまたは比較しようとしないでください。代わりに、チームからのシグナルを使用して組織のダイナミクスをより理解し、組織全体の改善に優先順位を付けます。