スポンサーサイト

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

1時間1イテレーションは可能か?

 昨今は既に1日1イテレーションの時代に突入しています。私はおよそ10年前(2002年頃)にはすでにしていましたが(フリーになるのと同時に実施している)、世間一般でもそれが常識になりつつある感がします。そこで、1時間1イテレーションにするとどうなるのかを書くことにしました。時間1イテレーションのアジャイル開発を何度かしてみましたが、非常に難しくあまり良い結果をもたらしませんでした。その理由はいろいろありますからこれから説明します。
 第1に文化的な問題です。実現可能性から言えば、開発者である私には可能でしたが、お客様側が対応できませんでした。日本の意思決定システムでは、1時間単位で変化する開発スピードについていけません。よく言われますが、日本は慎重に和をもって事をなす民族です。その文化がある限り、時間単位で意思決定を下すのは不可能です。従って、そのまま開発するのではなく、お客様の受け入れ態勢を考慮して、開発以外の工夫をせねばなりません。純粋な開発スピードでは可能ですが、お客様を助けるコストを加味すると、非常に難しいと言わざるを得ません。
 第2にコミュニケーションコストの問題です。私が1時間1イテレーションのペースで開発をできる理由は、全ての開発要素を並列的に処理できるからです。お客様と会話しながら、分析・設計・実装・運用・テスト・ネットワーク・データベース・セキュリティなどの全ての事柄を頭の中でします。そして、お客様との会話が終わった時点で、ほとんどの事が終わっており、後は実際に作業するだけの状態になっています。それぐらいしないと1時間1イテレーションは実現できません。しかしながら、開発チームで仕事をするとなると、コミュニケーションコストが発生しますから、そのスピードで物事を処理するのはほぼ不可能です。成功するには、開発チームの全ての人間が阿吽の呼吸で意思疎通ができる、熟練のプロである必要があります。実際問題それだけの人材を集められないでしょう。
 第3にビジネス面の問題があります。開発はビジネスでもあります。ビジネス面で考えたとき、契約と信頼関係が1時間1イテレーション実現の障壁となります。事が速く進むのは良いのですが、ビジネスに契約はつきものです。契約をどうやってするのかを考えねばなりません。契約にもコストが発生しますから、いちいち契約をするのは不可能です。従って、高い信頼関係がないと成り立ちません。その他にも、ビジネスとして考えねばならないことが沢山あります。
 最後に利益が問題となります。3つの問題を解決して得られる利益に疑問が生じます。開発側とお客様側の双方に、それだけの負担を伴う開発が利益を出すのか、それが大いに疑問です。1時間1イテレーションで開発するのは非常に疲れます。同時に複数の仕事を引き受ける場合も想定すると、私の感覚からいえば、プロジェクト3件が限界だと思います。技術力向上により、限界は少し増えるでしょうが、開発チームとなるとそれが可能だとは思えません。
 纏めます。1時間1イテレーションは一応可能ですが、いくつもの条件を満たさないと、プロジェクトは失敗します。それだけのリスクとコストをかけるのですから、大きな利益が得られる状況でのみ行うべきだと思います。しかしながら、お客様側に1日1イテレーションを提示しておき、開発チーム内で作業を細かく分け、1時間1イテレーションで管理することは一般的に可能だと思います。すなわち、外部イテレーションと内部イテレーションを設定するのです。そうすればより高度な開発体制が整います。むろんこれにも高度な開発体制が要求されます。
 これらの結果を踏まえると、イテレーションの単位はプロジェクトに適したものを選ぶという原則が成り立つと思います。アジャイル開発はもともと柔軟性が必要な開発手法です。イテレーションの設定も柔軟に行いましょう。
スポンサーサイト

テーマ : ソフトウェア開発
ジャンル : コンピュータ

コメントの投稿

非公開コメント

プロフィール

インドリ

Author:インドリ
みなさん、はじめまして、
コンニチハ。

ボクは、無限の夢(infinity dream)を持つネタ好きな虹色の鳥インドリ(in dre)です。
色々な情報処理技術を啄ばむから楽しみにしてね。

http://twitter.com/indori
は別人による嫌がらせ行為です。
私とは関係ないので注意して下さい。
次はなりすましブログなどをするかもしれませんが、ここ以外でブログをするつもりがないので、ここ以外にインドリのブログがあったとしても無視してください。


何度言っても分からない人がいるので、ここにコメント欄へ書き込むときの注意事項を書きます。


一、社会人としてのマナーをわきまえましょう。
一、妄想に基づく書き込みを止めてください。
一、暴言の類は書かないで下さい。
一、某誹謗中傷サイトの書き込みは彼らの妄想に基づく書き込みですから無視して、ここへ書き込まないで下さい。
一、コメント書く前に他のコメントよく読んでから行って下さい。
一、言いがかかり等の行為を禁止します。
一、その他常識的に考えて迷惑なコメントはしないで下さい。


以上のルールを守れない人のコメントは削除します。



利用上の注意
ここに紹介してある文章およびプログラムコードは正確であるように心がけておりますが、内容を保証するものではありません。当サイトの内容によって生じた損害については、一切の責任を負いませんので御了承ください。


執筆したCodeZineの記事


【VB.NETで仮想CPUを作ろう】

  1. VB.NETで仮想CPUを作ろう
  2. レジスタの実装
  3. 仮想CPUのGUI化
  4. テストドライバの改良
  5. CPUの基礎動作の実装
  6. MOV命令の実装
  7. ADD命令実装
  8. SUB命令実装
  9. INC命令&DEC命令の実装と命令長
  10. MLU命令の実装とModR/Mについて
  11. DIV命令の実装とイベント設計について
  12. 機械語駆動式 関数電卓を作ろう!
  13. 機械語駆動式 関数電卓を作ろう! 解答編(前半)
  14. 機械語駆動式 関数電卓を作ろう! 解答編(後半)


【仮想ネットワーク実装でTCP/IPを学ぼう】
  1. TCP/IPの基礎と勘所
  2. ネットワークアクセス層の勘所
  3. インターネット層の勘所
  4. トランスポート層の勘所
  5. アプリケーション層の勘所
  6. セキュリティの基礎と仮想ネットワークの仕様
  7. GDI+と独自プロトコルの定義



【並列化】
インテル Parallel Studioを使って並列化プログラミングを試してみた
並列プログラミングの効率的なデバッグを実現する「Parallel Inspector」


【TBBシリーズ】
  1. インテル スレッディング・ビルディング・ブロックの概要
  2. インテルTBBから学ぶループの並列化
  3. スレッドセーフとインテルTBBのコンテナ
  4. インテルTBBのスレッドクラス


【OpenMPシリーズ】
  1. OpenMPの基礎構文
  2. OpenMPの実行時ライブラリと並列ループ
  3. OpenMPのメモリモデルとfork- joinモデル

最近の記事
最近のコメント
月別アーカイブ
カテゴリ
Ada (9)
COBOL (5)
C (9)
C++ (11)
C# (370)
D (25)
Java (8)
Perl (1)
Ruby (14)
PHP (2)
Boo (2)
Cobra (2)
LISP (6)
F# (33)
HTML (0)
XHTML (0)
CSS (0)
XML (0)
XSLT (0)
Scala (4)
WPF (0)
WF (2)
WCF (0)
LINQ (4)
MONO (5)
Linux (0)
MySQL (0)
ブログ内検索
リンク
最近のトラックバック
RSSフィード
ブロとも申請フォーム

この人とブロともになる

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