Dora_PaPa_san's_Pages

アクセスカウンタ

zoom RSS Scott W.Ambler「ディシプリンド・アジヤイル・デリバリー」は、素晴らしい本!

<<   作成日時 : 2013/09/25 07:23   >>

ブログ気持玉 0 / トラックバック 0 / コメント 0

ディシプリンド・アジャイル・デリバリー(DAD)プロセスフレームワークは、「IT Solution Deliveryのための、人を最も重視した学習指向のハイブリッド型アジャイルアプローチである。 このフレームワークは、”リスクと価値によるライフサイクル”に基づき、ゴール駆動型で、スケーラブルであり、企業の基幹を支えるソフトウェアにも対応する」という。

ハイブリッド型プロセスフレームワークの意味は、スクラムの管理プロセス、XPの技術的プラクティス、AMのモデリングと文書化プラクティス、ADのデータベースプラクティス、UPのガバナンスプラクティスなどをベースに、エンタプライズ対応を測り、それに、リーンアプローチを加えたということだろう。  なぜか。 エンタープライズ対応は、純粋アジャイルだけでは困難だからだ。

エンタープライズ対応は、チーム規模、地理上分散、組織分散、技術上複雑さなどのスケールの問題でもある。 アジャイル・スケーリング・モデルのひとつは、コアアジャイル→アジャイルデリバリー→Agility@Scale  というように、アジャイルを変化させる。 もっとも純粋なアジヤイリストが嫌うかもしれないものが、「フェーズ」だ。 方向付け、構築、移行という3つのフェーズに、さらに、Agileの3Cリズム(Cordinate調整、Collaborate協働、Conclude完成)を乗せてゆく。 それが、イテレーション(計画ワークショップ、実装作業、ふりかえり) であり、日々の活動 (調整ミーティング、協働作業、構築) でもある。 

ゴール駆動デリバリーライフサイクルとか、リスク価値駆動型とかいわれる。その詳細は私の理解を超えるが、趣旨は、ソフトウエアではなく使用可能なソリューションに注目し、イテレーションデモ、利害関係者の積極的参加を促すものだ

エンタープライズ対応のために、アジャイルマニフェストも変更追加されている。 アジャイルマニフェストは、筆者によると、信仰的な文書となってしまい、その先入観が企業での導入を妨げたという。
ディシプリンド・アジャイル・マニフェストとその更新版には、本質的な概念が記されている。それを更に敷衍してみる。

・文書を作るよりも、利害関係者の満足を最優先し、短い期間内に価値のある”ソリューション”を早く継続的に提供
・要求の変更は歓迎、イテレーションによって、欠陥が見つかればその場その場で修正してゆく
・意欲に満ちた、.利害関係者と開発者は、プロジェクトを通して日々一緒に働き、メールや長い会議や文書は不要
・シンプルさ(ムダなく作れる量を最大限にすること)が本質であって、変化への対応が必要。
・最良のアーキテクチャ・要求・設計は、自己組織的なチームから生まれる
・既存のアセットを活用するのがもっとも低コストになりやすい

アジャイルの経験ある人はもちろんすぐ理解できるが、経験ない人にも、たいへん解りやすい解説になっている。いろいろな選択に直面して、その取捨選択の考え方も示している。 アジャイル特有の用語や概念も説明が多い。 プロダクトバックログ(ワークアイテムリスト)、価値駆動ライフサイクル、デイリースクラム(調整ミーティング)、リリース計画、スプリント計画(イテレーション計画)、ユーザーストーリー駆動開発(ユーセージ駆動開発)、コーディング規約(開発ガイドライン)、継続的インテグレーション、顧客テスト(受け入れテスト駆動開発)、リファクタリング、ペアプログラミング(ノンソロ開発)、先行モデリング、モデルストーミング、テスト駆動開発(TDD)、アジャイルデータ、データベース・リファクタリング、アジャイル・データ・モデリング、IBMプラクティス、OpenUP(Open Unified Process)・・・・・などなど。

DADのアジャイルチームは、利害関係者、プロダクトオーナー、チームリーダー、アーキテクチャーオーナー、必要となりうる補助的役割を担う人、そしてメンバーがいる。 プロジェクトマネジャー専任の人はいないし、みな多能工として、複数の役割を兼任して、可能な限り実装もやりぬく。 ある意味、内製をする日本企業の日本的チームのような印象もある。 
スペシャリストも部分的に参加できるのは、DADの特徴なのかもしれない。 
DADチームは典型的には小(15人以下)〜中規模(10〜40人)、大規模は30人以上を目安にしているから、超大規模プロジェクトではない。 
この本の素晴らしいところは、たいへん現実的なところだ。 「殆どのアジャイルの書籍はベテランを前提にしているが、そんなことはほとんどない」と語っている。

短期的利益を減らすので、「アジャイリストの間で方向付けフェーズは物議を醸すかもしれない」が、長期的利益がある、この方向付けフェーズ、開発構想書は、プロジェクト憲章、ビジネスケースと、似通ってもいる。 予算確保のためには、どのみち必要なものだろう。

DADアジャイルの良さを痛感するのは、初期のスコープ、初期の技術戦略・・・というような、「初期の」があることだ。 確かに、いったんベンダーと開発契約してしまうと、わからないうちに最終形を決めないと契約がしづらい。 それが失敗のもとでもあるのだ。

初期のスコープ検討には、適切なモデルの選択もある。  利用モデル(Usage Model)、ユーザーストーリー、利用シナリオ、ユースケースモデリング、ドメインモデリング、プロセスモデリング、ユーザーインターフェースモデリング・・・・

また、ワークアイテムの管理戦略 (公式の変更管理、スクラム・プロダクト・バックログ、ワークアイテムスタック )や、非機能要求の戦略 ( テクニカルストーリー、受入基準、明示的なリスト ) などの選択も検討するのは、なかなか、アジャイルも立派なものだ。 

構築の一日がケーススタディのように描かれているのがわかりやすい。 ただ、どうかなあと思う点も少なくはない。
スクラム形式の日時調整ミーティング、リーンなカンバンの手法、などで朝始まる。 「バーンダウンチャートをスプレッドシートで作成したくなる誘惑に抵抗しよう。もしそれをネットワーク上のどこかに保存したら、誰もそれを見なくなるだろう」という注意は、まったくそのとおりだ。 

そのた、受入テスト駆動開発(ATDD)もしくは振る舞い駆動開発(BDD)と呼ばれている開発、モデル駆動開発(MDD)に言及しているが、「新郷重夫は、トヨタ生産方式についての著書の中で、欠陥を発見するプロセスにフォーカスを当てるより、欠陥を発生させないプロセスを設計すべきである」は、全く、その通りとおもう。 しかし、やってしまうんだなぁ。 

重要なアジャイルプラクティスについて、テスト駆動開発(TDD)、リファクタリング、継続的インテグレーション(CI)、継続的デプロイ(CD)、並行した独立テストのそれぞれを丁寧に解説している。


「なぜプロジェクトが失敗したかを長きにわたって実習後レビューを実施するよりも、イテレーションの間に改善した方がよほどよい」・・・ふりかえりのミーティングは人を苦しめるセッションを、決定について非難する機会ではないということをチームが理解することが重要

たとえ、アジャイルでも、いったん移行フェーズに入ったら、新しく提起されたものは次のリリース・・・と言うのは安心した。 主流のアジャイル手法は、顧客にシステムをリリースする工数を極端に小さくする傾向がある。 作ったらおしまいという傾向だろう。  そういうところがアジャイルに対する不信につながると思う。  

アジャイル開発はなんでも自由とという印象もあるが、しかし、実際にはガバナンスも必要だし、規律も必要だ。
フィードバックサイクルを短くするには、ノンソロ開発、利害関係者の積極的な参加、継続的インテグレーション、・継続的デプロイ、短いイテレーション、短いリリースサイクルという方法・規律が必要だ。
そして、アジャイル・プロジェクトチームは、アジャイルの作法でガバナンスされるべきであり、従来型のアプローチではプロジェクトリスクをたかめるだけ。 

効果的なガバナンスは、コマンド・アンド・コントロールでなく、モチベーションとイネーブルメントが基になるが、メトリクスは必要。 チームの測定、トレンド値、ゴール・質問・メトリクス・(GQM)アプローチ、メトリクスだけで管理せず、メトリクスは自動化し、会話でガバナンスする



Scott W.Ambler「ディプリンド・アジヤイル・デリバリー」<.エンタープライズ・アジャイル実践ガイド>(翔泳社 2013.6.21)☆☆☆☆
第T部 ディシプリンド・アジャイル・デリバリー(DAD)入門
第1章 ディシプリンド・アジャイル・デリバリー概要
第2章 アジャイルおよびリーン入門
第3章 ディプリンド・アジャイル・デリバリーの基礎

第U部 ピープルファースト
第4章 役割、権利、責務
第5章 ディシプリンド・アジャイル・デリバリーチームを組織する
第6章 方向付けフェーズ

第V部 ディシプリンド・アジャイル・デリバリーの開始
第7章 プロジェクトのビジョンを識別する
第8章 初期のスコープを識別する
第9章 初期の技術戦略を識別する
第10章 初期のリリース計画
第11章 作業領域の構築
第12章 ケーススタディ:方向付けフェーズ

第W部 使用可能なソリューションをインクリメンタルに構築する
第13章 構築フェーズ
第14章 構築フェーズのイテレーションを開始する
第15章 構築フェーズのある一日
第16章 構築イテレーションの終了
第17章 ケーススタディ:構築フェーズ

第X部 ソリューションをリリースする
第18章 移行フェーズ
第19章 ケーススタディ:移行フェーズ

第Y部 エンタープライズシステムにおけるディシプリンド・アジャイル・デリバリー
第20章 ディシプリンド・アジャイルチームのガバナンス
第21章 用意はいいかい?

テーマ

関連テーマ 一覧


月別リンク

ブログ気持玉

クリックして気持ちを伝えよう!
ログインしてクリックすれば、自分のブログへのリンクが付きます。
→ログインへ

トラックバック(0件)

タイトル (本文) ブログ名/日時

トラックバック用URL help


自分のブログにトラックバック記事作成(会員用) help

タイトル
本 文

コメント(0件)

内 容 ニックネーム/日時

コメントする help

ニックネーム
本 文
Scott W.Ambler「ディシプリンド・アジヤイル・デリバリー」は、素晴らしい本! Dora_PaPa_san's_Pages/BIGLOBEウェブリブログ
文字サイズ:       閉じる