生成的開発プロセス・パターンランゲージ
６月に完了した”なんちゃってアジャイル”プロジェクトのノウハウをどうにか形式知にしたい。
でも、SCRUMやらXPやらUPやら、いろんな手法を散文的に組み合わせただけなので、
原則というにはおこがましく、プロセスというには手順が無さすぎる。
結局、あるパターンの１セットとして表現できないか、と考え、ヒントを探してWebを漁ると…
- 『Scrum: 超生産的ソフトウェア開発のための拡張パターン言語』
- 『XPとパターン Ralph Johnson'sの見解』
- 『第4回 ソフトウェアパターン勉強会「組織パターンの紹介」』
ああ、そう。アジャイルとパターンは元々近しいものですか。
その中でもCoplienの組織パターンとプロセスパターンはかなり影響力を持ってるようだ。
組織パターンはかなり前からあったものだけど、日本じゃ翻訳本出てないからかあまり浸透してないかも（俺が知らないだけ）。
温故知新ということでお勉強。
元ネタはこちら↓
組織パターン
- 組織の規模を決める
デフォルトとして10人を選びなさい。適切に選ばれた教育を受けた人の小さなチームは、31ケ月で1,500KSLOC、15ケ月で200KLOC、8ケ月で60KSLOCのソフトウエアを開発できることが経験上わかっている。開発の後の方の工程で人を増やしてはならない。最終期限を、完成日から計算しなおした日に合わせるように試みなさい。
未だに生産量が工数や工期に正比例だと思っちゃってる（思いたい？）人がいるからなぁ…。
- 自己選抜チーム
経歴と幅広い知識を基本として厳しくふるいにかけ、自己選抜チームを作りなさい。
- ソロ名音楽家
すべての設計と実装を１人か２人の人にやらせなさい。（※25KSLOC以下になりそうなら）
- 形式は機能にしたがう
密接に関連のある活動をグルーピングしなさい（すなわち、実装においてお互いに関わり合いを持つもの、同一の成果物を操作するようなもの、あるいは意味論的にいって同一の分野に関連するものなどを）。グルーピングした活動から起因する抽象化した名前をつけ、それを役割にしなさい。関連する活動は、その役割の責任（職務分掌）となる。
- 役割に合ったその分野での専門知識
根拠のある経歴を持つ分野に合った専門家を雇いなさい。ある人は複数の役割を担当できるかもしれない。多くの場合、１つの役割のためには複数の人を必要とする。プロセスについてよりも分野についての訓練のほうがより重要である。アプリケーション専門知識から手法や言語の専門知識にいたるあらゆる分野において、職場のグル(guru：宗教教師)がいるといい。
これが一番難しかったりする。
- 段階的な補充
採用計画を段階的にしなさい。専門家を最初に雇い、プロジェクトが成長するにしたがって人を増やしなさい。
- 見習い
見習い方式にしたがって新たに集めた人を専門家達の中に配置しなさい（役割に合ったその分野での専門知識のパターン参照）。ほとんどの場合、見習い期間は６ヶ月から１年間は必要である。パラダイムシフトを起こすのに必要となる時間だけ必要とする。
- 組織は場所にしたがう
組織構成の分割は、地理的な分割を反映すべきである。逆も同様である。組織構成上の責任は、決定が（地理的に）ローカルに行えるように割り当てられるべきである。
- 組織は市場にしたがう
いくつかの異なった市場をカバーするように考えられた組織においては、市場構造を開発組織に反映することが重要である。すべての市場分野をまたがって共通な部分のみをサポートするような、“核”となる組織を意識的に作るという強力なパターンは、しばしば見落とされる。Ralph Johnsonは、これをフレームワークチームと呼んでいる。この組織を前面に置くことが重要である。
- 開発者はプロセスを統制する
ある機能に対して、開発担当をプロセスの中心におきなさい。機能とは、別々に市場に出すことができ、顧客が喜んで買うような製品単位（主としてソフトウエアとして実装されたもの）である。開発者は、プロセス情報についての手形交換所である。開発者の責任には、要求仕様を理解すること、解決策となるソフトウエア構成とアルゴリズムを仲間と一緒にレビューすること、実装を組み合わせること、単体テストを含む。他にも中心があってもかまわない。
プロジェクトの要因を擁護してくれる明らかに高レベルのマネージャーにプロジェクト参加してもらいなさい。パトロンはプロジェクトにおける判断の最終調停者になり得るし、その判断は組織が迅速に判断するための加速力となる。パトロンは進捗を妨げるようなプロジェクトレベルでの障壁を取り除く責任があり、組織の“戦意”（うまくいっているという感じ）維持の責任を持つ。
- アーキテクチャ設計者は製品を統制する
アーキテクチャ設計担当者をアサインしなさい。アーキテクチャ設計担当者は開発者達にアドバイスし彼らを統制し、そして彼と密接に情報交換しなければならない。アーキテクチャ設計担当者は、顧客とも密接な関係でなければならない。
- Conwayの法則
組織を製品のアーキテクチャに当てはまるようにしなさい。このパターンランゲージにおいて、ここでは、組織がアーキテクチャに影響をおよぼすべきであるというよりも、アーキテクチャが組織に影響をおよぼすべきであるといえるだろう。
- アーキテクチャ設計者もソフトウエア実装に参加する
- コード所有者
システムの中のそれぞれのモジュールを一人の開発者に所有させるようにする。例外的あるいは明確な状況である場合を除き、コードはその所有者によってのみ修正してよい。
これはアジャイル的ではないかもしれない。ただし、Coplienも反論が存在することは認めてるし、逆にアジャイルサイドは”コードの共有には段取りがある”なんてことも言ってる。バランスが必要ということだろう。
- QAの参加
QAに中心的な役割をさせなさい。何かテストできるようなものが出来次第、QAと開発とを強い関わり合いを持つようにしなさい。テスト計画の作成はコーディングと平行して進めることができるが、開発者はテストを開始していいかどうかを宣言しなければならない。QA組織はプロジェクトの外側に位置づけるべきである。すなわち、テストの計画と報告の責任は開発組織にあってはならない。
- 顧客の参加
QAだけでなく開発者やアーキテクチャ設計者にも密接な関わり合いを持つような役割を顧客に与えなさい。
- 雇われ分析者
必要とする分野で熟練しており、設計そのものには利害関係のないテクニカルライターを雇いなさい。この人は、適切な表記法で設計を把握し、設計ドキュメントを定型化し発行してくれる。そして、その設計ドキュメントはレビューなどによりその組織で利用される。ドキュメントそのものは、できるかぎりオンラインで管理されるべきである。そして、常に最新の状態に保たれていなければならない（したがって雇われ分析者はフルタイムとなる）し、顧客のシナリオに関連付けられていなければならない（シナリオは問題を明らかにするのパターン参照）。
- ファイアーウオール
開発している人達に対しての外部からの干渉を防ぐような役割として、マネージャーを割り付けなさい。この役割の責任は“病原菌を遠ざける”ことである。
A型の性格を持つプロジェクトメンバーがゲートキーパーの役割として立ち上がる。この人は、外部からの最新の情報や雑多な情報をプロジェクトに関連する言葉に翻訳してプロジェクトメンバーに広める。そのゲートキーパーは、プロジェクト情報を関連する外部の人に漏らしてもよい。この役割は、開発とマーケティングや全社管理組織とのインタフェースを管理することもできる。
- 回覧の範囲を決める
好ましい分類法を反映するような構成を持つ階層構成あるいは照査順を創り出すような肩書きを与えなさい。役割の間での適切な相互作用が思い浮かぶような仕事上の責任を与えなさい（責任を移動も参照のこと）。あなたが緊密な情報交換が必要であると望んでいる人達を物理的に同じ場所に配置しなさい（これは、組織は場所にしたがうのパターンと対をなす）。皆に、何をすべきかと、誰と相互作用すべきかを話しなさい。もしあなたが彼らの権限と力の範囲内で理にかなった何かをしてもらうようにお願いすれば、ほとんどの場合、彼らはあなたの意志を尊重しようとするであろう。
- 責任を移動
最も好ましくない関わり合いを作り出している役割から、他のプロセスでその好ましくない関わり合いに関係している役割に、責任を移動させなさい。簡単にいえば、これは負荷バランスをとることである。責任は任意に移動されるべきではない。チーフプログラマーチーム組織はこのパターンを実現するためのよい方法である（開発者としての責任という意味で）。
- バッファローの山
サブパターン１：プロジェクトに関するいかなる重要な相互関係においても、２つの協力関係にある役割の組織の中心からの距離の和は、組織の全体をカバーするのに必要な最短の距離以下でなければならない。
サブパターン２：もし組織の仕事に50％程度しか関与していない離れた立場にあるのなら、隣の位置にいる人（あなた自身のようにプロセスの中心から等距離にある人達、すなわち、全体としてあなたと同程度にプロセスに関わり合いを持つ人達）との関わりを避けなさい。
サブパターン３：いかなる相互関係の強さも、それぞれの役割のプロセスの中心からの距離の差の合計に逆比例すべきである。
手段A:上記の３つのサブパターンを効果的にするために、関連する協力関係が移動するように、役割の間で責任を入れ替えなさい（責任を移動のパターン参照）。これはRobert Laiのアイデアである。単純ではあるが大いに効果がある。
手段B:情報交換の機会を増すような物理的な位置に人々を配置しなさい（仕事は内向きに流れるパターン参照）。
手段C:プロジェクトにおける役割の統制の範囲を広げなさい（複数の役割を1つの役割に集めるということに似ている）。類似した責任を持つ役割を一緒にするというのは多分一番いいであろう。あるいは、類似した協力関係にある役割をいっしょにするのもよりよい方法であろう。そうだ、これらもパターンだ。
- 仕事は内向きに流れる
仕事は顧客によって作られ、支援的な役割によってフィルタリングされ、そして中心の実装専門家によって開発されるべきである。マネージャーを相互作用グリッドダイアグラムの中心においてはならない。彼らは、過負荷になり、よく考えられていないような決定を下し、最後には日々の活動を考慮しないというような決定をするであろう。
- １つの役割に３人から７人の援助者
各々の役割に対して、３人から７人の援助者になるようにしなさい。
- 分割統治
お互いに関わり合いの強い役割のあつまりで、組織の他の部分とは緩い関わり合いを持つような役割の集合を見つけなさい。そして、それらの役割のあつまりを囲むように別の組織とプロセスを形成しなさい。
- ハブ・スポーク・リム
個々のプロセス活動を指揮できるように、それらのプロセスの役割と中心にいる役割をリンクしなさい。もし、中心にいる役割が活動をコントロールすれば、平行処理はさらに活発になる。
- 芸術的パターン
そのプロジェクトが市場を維持し、生き残り、成長するにつれて、それぞれの部分が１つの部門に成長できるように、その組織を分割しなさい。
- 関わり合いは遅延を少なくする
役割当たりの関わり合いの比率を全般的に上げるように、役割の間でのオープンな情報交換の経路を確立しなさい。特にプロセスの中心にある役割との間での情報交換の経路が重要である。役割の間での情報交換は、仕事は内向きに流れるや責任を移動のパターンを用いて形成することができる。
- ペアで開発
気の合った設計者をペアにし、一緒に仕事をさせなさい。一緒に仕事をすると、２人の能力の和以上の能力を発揮できる。
CoplienってXPが嫌いじゃなかったっけｗ
- 成功を補償する
成功裏にプロジェクトを立ち上げたり終了させたりしたことに貢献した個々人のために、気前のいい報奨を用意しなさい。チーム全体（公的な単位）がそれなりの報奨を受けるべきである。さもなければ、自分の給与と仲間の給与と比較することによって自分の価値を判断してしまい、動機を失ってしまうかもしれないからである。“特別な”人は、チームのパフォーマンスにはあまり関係なく、例外的な報奨をもらってもよい。祝福は、特別に効果がある褒美である[Zuckerman and Hatala]。
プロセスパターン
- スケジュールの期間を決める
スケジュールが守れた時には金銭的なボーナス（あるいはリスク保証で；成功を補償するのパターンを参照）あるいは余分な休暇で開発者に報いなさい。２つのスケジュールを用意しなさい。１つは市場に対するもので、もう１つは開発者向けである。外部のスケジュールは顧客と交渉でき、内部のスケジュールは開発者と交渉できる。普通のプロジェクトであれば、内部スケジュールは外部スケジュールよりも２〜３週間短くなければならない（この数字はソフトウエアコンサルティング会社のシニアスタッフによるものである）。もし２つのスケジュールが調停できない時は、顧客の要求あるいは組織のリソース（あるいはスケジュールそのもの）が再交渉されなければならない。
- アプリケーション設計はテスト設計の制約を受ける
要求仕様のシナリオが顧客に合意された時点で、シナリオに基づくテスト設計が始まる。テスト設計はソフトウエア設計と同時進行するが、顧客のシナリオにのみ対応すればよい。テスト者には、ソフトウエア自身を使用することはできないからである。アーキテクチャ上のインタフェースが安定したと開発者が決定した時に低レベルのテスト設計とテスト項目決定を進めることができる。
- アーキテクチャをレビューしなさい
すべてのアーキテクチャ上の決定は、すべてのアーキテクチャ設計者によってレビューされるべきである。アーキテクチャ設計者は、お互いにコードをレビューし合うべきである。レビューは、たとえ毎日であろうと、プロジェクトの初期に頻繁に行われるべきである。レビューは、最低限の資料で非公式に行うべきである。
- グループによる妥当性確認
QAが参加する前であっても、開発チーム（顧客を含む）は設計の妥当性を確認することができる。CRC設計技法のような技法やグループによるデバッグは、問題を顕在化し解決するのに役に立つ。妥当性確認チームのメンバーは、共通なソフトウエア欠陥の分類に帰因するような根本原因を解決するためにQAと協力することもできる。
- シナリオは問題を明らかにする
Jacobson式に、システム要求仕様をユースケースとして取り込みなさい。
- 名前が付けられた安定したバージョン
変更が１週間に１回を超えないように、システムインタフェース（アーキテクチャ）を安定させなさい。システムインタフェース以外の部分についてはそれより頻繁に変更があってもいいし、結合されてもよい。
- 工程の分割
よく知られた成熟した分野では、ステップをシリアルに並べなさい。ステップ間の境界は、よく知られたインタフェースにしたがわなければならない。このことにより、１つあるいはいくつかのステップを自動化することができるし、未熟なスタッフでもステップを遂行できるような形態を作り出すことができる。
- 割り込みは閉塞状況を解除する
もし、あるクリティカルなリソースのためにある仕事が停滞しそうな時は、そのリソースを与えようとしている仕事に割り込みなさい。そうすれば、あなたは停滞から解法されるでしょう。もしオーバーヘッドが十分小さいのなら、スループットには影響しない。常に局所的な遅延を改善する。
この”割り込み”に関する２つのパターンはもっとエンジニアに常識化してほしいところ。そして、トップの方々にはこれを理解してほしい…”完璧で博識のある洞察とスケジューリングはできるわけがない”。
- 割り込みをやめるな
もし、誰かが割り込みは閉塞状況を解除するのパターンによって引き起こされた仕事をしているのなら、その人は、その仕事が終わるまでは、さらなる割り込みのために仕事を中断してはならない。
- プロトタイプ
要求仕様を理解するためのプロトタイプを作りなさい。プロトタイプは外部インタフェースにとっては非常に有用である。プロトタイプは使い終わったら捨てなさい。
- 小さなスケジュール変更をするな
「我々は、“人月の神話”から、「小さなスケジュール変更をするな」によってうまくやっていく方法を見つけた。毎週、クリティカルパス（最低限）の実績が、計画にどれだけ近いかどうかを計測しなさい。もし３日間の遅れなら、３日間の“幻の索引”を追跡しなさい。もし幻の索引がばかばかしすぎるようになったら、スケジュールをずらしなさい。これは、スケジュールをかき回すのを避けるのに役立つ。」･･･ 1994年６月のPaul Chisholmとの個人的なディスカスから。
ちとイミフ。ブルックスの言葉どおりだとすると、”「小さな挿し木はするな」。新しいスケジュールではたっぷり時間をとって仕事が慎重にそして完全にできるようにして、今後スケジュールのし直しをしなくても済むようにする”ことだと思う。
