スポンサーサイト 

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

アジャイル開発モデルの臨界点はどのあたりだろう? 

アジャイル開発が導入されたプロジェクトに直接かかわったことのない人間の空想です。

 

ソフトウェア開発におけるアジャイル的な要素ではなくて、 XPやスクラムなどの開発現場におけるプラクティスが比較的明確なものについて考えてみました。私はアジャイル開発宣言自体はまっとうなものだと思いますし純粋なウォーターフールモデルなどは非現実的だとも思っています。 ただ、ウォーターフールモデルと比較されるべきはアジャイル開発宣言を基にした思想ではなく、 XPやスクラムの様な開発モデルだと考えています。

 

アジャイル開発モデルには様々なプラクティスが存在し、極端な言い方をすればその組み合わせの数だけ開発モデルが存在すると言えます。 ですのでアジャイル開発モデルの適用範囲はプラクティスによって規定されると言うことができるでしょう。

 

以下のプラクティスについて注目してみます。

  • 毎日15分のミーティングを行う
  • チーム内のコミュニケーションを円滑にするため、パーティション等は廃止する
  • コードは2人のプログラマにより一台のマシンで
  • 誰でもどのコードでも修正できる

これらのプラクティスが多く導入されるほどチームが同じ場所で業務を行うことを要請されるようになります。 大規模な組織においては目的ごとにチーム分けされるのが普通です。 そして分けられたチームはおそらく同じ職場で業務を行うことが多くなるでしょう。このチーム内においては適用が可能であると考えられます。 アジャイル開発モデルにおいては顧客とチームという関係が用いられています。

 

では2つ以上のチームにおいて一つの機能を実現しようとした場合、それぞれのチームに対応する顧客とは誰なのでしょう。 機能を提出した人でしょうか。それともチームの成果物の依存関係において顧客関係が構成されているのでしょうか。 XPでの顧客をフルタイムでチームに加えるというプラクティスを用いる場合、 フルタイムでチームに加われる人は論理的に存在しうるのでしょうか。スクラムマスターを経由する場合、 結局顧客とチームの関係はウォーターフールモデルを基にした組織の関係とどうちがうのでしょうか。現実としてウォーターフォールはこう使え (まとめ)でいわれている、

ウォーターフォールとスパイラルの役割分担について。プロジェクト全体を俯瞰し、 マスタースケジュールを粛々と実行するのはウォーターフォール、個々の「すべきこと」 を割り当てられたチーム内で実行するのはスパイラルが適している。

の形になってしまっていると思います。 ウォーターフォールモデルの強みは組織論への展開が容易であるということです。 それに対するためにアジャイル開発モデルは独自の組織論を展開していくのかウォーターフールモデル型の組織とのハイブリッドで落ち着くのか興味深いところです。

 

コメント

コメントの投稿















管理者にだけ表示を許可する

トラックバック

この記事のトラックバックURL
http://ochoo.blog48.fc2.com/tb.php/14-1795379a

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。