SEMATカーネル アルファ状態カードゲーム

鷲崎 弘宜 SEMAT Japan Chapter Chair

Twitter: @Hiro_Washi washizaki@waseda.jp

http://www.washi.cs.waseda.ac.jp/

2013年10月29日 第3回SEMATカーネル勉強会

（ベース資料） Ivar Jacobson International (IJI): Alpha State Card Games

http://www.ivarjacobson.com/alphastatecards/

ゲームの進め方

• 4-5名のチーム

• 各チームで1名がストーリーテラー役

–自身の現在（あるいはある時点）の開発状況を説明する。

– カードは扱わない。指示もしない。聞かれたら答える。

• 他のメンバはプレイヤ役（大抵は開発者）

2

進捗ポーカー（Progress poker）

• 開発における各アルファの状態の認識について、チーム内で効率的に同意する。

1. 各プレイヤは検討対象のアルファの状態カードを選択する。

2. 選択カードを一斉に提示 or 指さす。

3. 全プレイヤが

– 同一カードを選択しなかった場合、最も進んでいない状態と最も進んでいる状態を選択した参加者がそれぞれ理由を説明する。1に戻る。

– 同一カードを選択した場合は終了する。 3

状態の追跡（Chase the state）

1. 各アルファのカードを横一列に。左端に最初の状態

2. チームにおいて当該状態に達しているかどうかを問いかけ（不明な場合は「進捗ポーカー」の実施）

3. ある状態に達している場合は当該状態のカードを左側に

4. 未到達・未検討の状態のカードを右側に

4

図5. チームは現在地の特定にアルファを使用する

構想

1/6

・新しいシステムのニーズが明確である・ユーザが識別されている・最初の出資者が識別されている

要求

スコープ定義

2/6

・システムの目的とスコープが同意され ている・成功の判断基準が明確である・要求管理の仕組みが同意されている・制約と前提が識別されている

要求

一貫性・体系化

3/6

・明確な全体像が関係者に共有されている・重要な利用シナリオが共有されている・要求の優先度が明確である・認識の不一致が対応されている・要求がもたらす影響力が理解されている

要求

受理可能

4/6

・関係者が受理可能な解決策が示されて いる・同意された要求が変更される確度は低い・価値が明確である

要求

実装

5/6

・システムの受理に必要十分な要求が 実装されている・システムが稼働させる価値のある状態に あることにステークホルダが同意してい る

要求

満足

6/6

・システムは要求とニーズを満足している・完成を妨げる未解決の要求が存在しない

要求

アーキテクチャ決定

1/6

・重要な技術リスクに対応可能な アーキテクチャが採用されている・アーキテクチャの選択基準が同意され ている・使用するプラットフォーム、技術、 言語が選択されている・購入、構築、再利用の方針が決定して いる

ソフトウェアシステム

論証完了

2/6

・重要なアーキテクチャの特性が論証 できている・アーキテクチャが適切であることを ステークホルダが同意している・重要なインタフェースとシステム構成 が論証できている

ソフトウェアシステム

使用可能

3/6

・システムは使用可能であり、要求された 品質特性を達成できている・ユーザがシステムを操作可能である・機能と性能がテストされており、 検収済みである・欠陥レベルが許容されている・リリース内容が周知されている

ソフトウェアシステム

準備完了

4/6

・ユーザドキュメントが利用できる・ステークホルダがシステムを受理して いる・ステークホルダがシステムの運用方法 を準備しようとしている

ソフトウェアシステム

運用

5/6

・運用環境でシステムが使用されている・想定されたユーザに利用されている・システムの全機能を運用した事例が 少なくとも一つある。・システム保守のサービスレベルが同意 されている

ソフトウェアシステム

退役

6/6

・システムは保守されていない・システム更新によるリリースはない・システムは置き換えられるか開発が 中止されている

ソフトウェアシステム

原則決定

1/6

・原則と制約が決定されている・原則と制約が宣言されている・プラクティスとツールが同意されている・チームは扱い方を理解している

仕事の仕方

準備完了

2/6

・重要なプラクティスとツールが準備され ている・プラクティスとツール間のギャップが 分析され、理解されている・能力のギャップが分析され、理解され ている・プラクティスとツールが統合されている

仕事の仕方

使用

3/6

・チームの一部メンバーが利用している・使用するプラクティスとツールが定期的 に監査されている・プラクティスとツールがチームによって 改善されている・フィードバックの手続きが整っている

仕事の仕方

定着

4/6

・チームメンバー全員が利用している・全てのメンバーが仕事を進めるために プラクティスとツールを入手できる・チーム全体が仕事の仕方の監査と改善に 取り組んでいる

仕事の仕方

活用

5/6

・仕事の仕方がチームで最適な形で活用 されている・チームメンバーが計画通り進歩している・プラクティスが当たり前に適用される チーム風土が整っている・プラクティスを実践する上でのツールの 課題が解消されている

仕事の仕方

廃止

6/6

・チームに利用されていない・次の利用時のために教訓が共有されて いる

仕事の仕方

• 最上位の7つのアルファに対する状態識別に意味はあるか。 – アルファを捉えるスコープで最初に合意すべき。全体、部分。 – 組織、プロジェクト固有のアルファを持つことの大切さ。背景知識重要。

• チームA – 要求: 構想で合意

• 当初ばらついていたが、最終的に低い方で収束

– 仕事の仕方: 合意せず • 個人開発のため人によって捉え方が異なった • 減速の決定有無をまずは意識合わせすると良さそう

• チームB – 機会: 課題解決で合意

• チェックリストの確認により合意

– ステークホルダ: 時間切れ • ステークホルダの種類によって異なる • 質問の仕方が大事

• チームC – ソフトウェアシステム: 合意せず

• 対象とするシステム範囲が異なっていた • 範囲を合意したのちも、使用可能から運用までばらついた

• チームD（アジャイル開発） – 要求: 合意せず

• アジャイル開発における要求の満足について捉え方に食い違い。未完なのか、当該時点において満足と判断するのか。

5