【IT】「開発手法」だったアジャイルはここまで進化した
■ このスレッドは過去ログ倉庫に格納されています
アジャイル開発宣言は2001年に発表された。「アジャイル」という言葉が登場すると、それ以前からあった「スクラム」や「XP（Extreme Programming）」をはじめとする軽量開発手法を総称する新しい呼び名として、大きなムーブメントとなった（ただし、注目を集めたのはソフトウエア開発の文脈においてであり、ムーブメントはソフトウエア開発者のコミュニティ内に限られていた）。アジャイルは、ソフトウエアエンジニアの草の根活動から始まったと言える。
以下に、有名なアジャイル開発宣言を引用する。
http://jbpress.ismcdn.jp/mwimgs/b/e/670mn/img_beac23ba7fda659ca8c81c4921c1832c82100.jpg
この宣言は今でも色褪せないが、読んでみて分かるようにウォーターフォール型開発へのアンチテーゼとしての色彩を帯びている。
左に書かれていることを重要としながらも、右側がより価値をもつ、という宣言になっており、よく見ると左側に書かれていることは、ウォーターフォール型のプロジェクトマネジメントではまさに最重要項目とされてきたことだ。
もう1つのポイントは、これ自体が「アジャイルソフトウエア開発宣言」という名称をもつことからも分かるように、「ソフトウエア」を「つくる」側に力点が置かれており、ソフトウエア開発者側からのメッセージだったことだ。1990年代後半から2000年前半のアジャイルは、このように開発者の視点に立って、ビジネスにいかに貢献するかを目標に掲げていた。
アジャイル開発手法の1つであるスクラムを開発したジェフ・サザーランドは、その動機を次のように述べている。
私は全く新しいオブジェト指向型4GLの開発リーダーをつとめていた。開発チームはいつでもプレッシャーをかけられ、管理者たちはいつも機嫌が悪く、そして顧客はいつも不満足。（中略）なぜこうなるのか、どうやったらこの仕事に携わる人たちの生活をよくできるか、というようなことをいつも話していた。そして行き着いたのは、「問題は仕事をするための組織構造にある」という結論だった。通常マネジメントは階層的であり、コマンド・コントロール型のプレッシャーによって管理しようとするものだ。コンウェイの法則によれば「ソフトウエアの構造はそれを作り出した組織構造に従う」という。私たちのソフトウエアはオブジェクト指向だったので、官僚的な組織構造とミスマッチが起きていたのだ。それならば、オブジェクト指向的な組織構造を作ったらどうだろう、と考えたというわけだ。
（ジェフ・サザーランドへのインタビューより。出所：『アジャイル開発とスクラム』平鍋健児・野中郁次郎著）
つまり、核心にある動機は、
いつも不満を抱えている顧客
いつも不機嫌なマネジャ
疲れ果てた開発者
という状況認識であり、その原因を、
官僚的な組織構造
コマンド・コントロール型のマネジメント
にあると捉えている。
以下ソース
http://jbpress.ismedia.jp/articles/-/51870 業務の根本が分かってないと、逆に
ぐだぐだな仕様になりそう。 >>9
Azure のことだな。そうなんだな？
「あじゅーる」って、マイクロソフト公認の「日本語」だからなw >>34
ありきたりだが警察は事前には動かない。
今じゃどこの家庭もSECOMが当たり前の時代なんだから
襲われるのが嫌なら隣にボディーガードを付けとけばいいんだよ。
格安ボディガードのガードドッグなんか時給2500円で付いてくれるから相手が確実に来るときに付けとくだけでもかなりの抑止効果になるよ。 ステークホルダからサルを排除する
オサルレス開発の方が重要 >>45
そして誰もいなくなった。
一番最初にいなくなるのはキミだ！ >>45
ほんとこれ
無能が上にいる時のインパクトは絶大 日本は、下請け構造のせいでウォーターフォールしか適用できない
アジャイルは、顧客もベンダーもフラットな構造の場合にしか使えない >>40
そのための書き方をする作法が求められるよね。
グローバル関数殺さないと無理。 アジャイルは方便
初心者はこんな言葉に惑わされずに実践的なプラクティスを学び経験するのが一番 アジャイルは自社サービスやパッケージソフトを作ってるところだったら日本でもやってるとこあるでしょ >>48
それもそうだしもっと言うとそもそも開発を外注してるようなプロジェクトでアジャイルは無理 >>17
アジャイルは部分的に変更して行く。
スクラップ&ビルドは全面変更。
ただ、アジャイルも最初のデザインではやって行けなくなるとスクラップ&ビルドする。 日本のITは製品製造より奴隷売買の効率化優先だから縁のない話やね >>62
確かに。運用テスト後に要件が出てくるからな。 開発手法なんかで
利益なんかそんな変わらん
バカはこういうのを真顔で信じてるんだな >>65
利益しか見ない人にとってはどうでもいい話だろうねー そもそも開発メンバー全員の技術レベルがある程度にないとアジャイルなんて無理
つまり土方しかいない日本人には無理 >>65
投資かパーになったら大損なので関係大有りだわ >>72
顧客が無能の場合こそ、アジャイル開発になりやすいんだよ アジャイルは簡単に言えば短いサイクルでの仕様変更を可能として製品の改善スピードを上げる為の方法論で
上で言及されてるように土方で回してるところではやれない で、たいていのモノは既存のものを社内体制を変えて使えば開発の必要すらないものだったりするんで >>76,77
開発体制はどうあれ、短期間の仕様変更を繰り返すと間違いなくプログラム品質は悪化する アメリカやヨーロッパでは、銀行のシステムですら、１日20回リリースという状態らしい。
Windowsほどの巨大プロジェクトもアジャイル開発だし、日本が取り残されているのは明らか。 >>79
影響の局所化を図っていかないと品質は悪化する
まず、アジャイルはテストファーストが前提
そのうえで小規模改修とテストとリリースを細かく繰り返す
品質悪化のリスクを早いスピードでのバージョンアップでカバーするという考え方
品質悪化をいかに防ぎつつ仕様変更していくかという課題は
製品を絶え間なく改善していかないとビジネスで負けるWEBサービス企業では死活問題
アメリカのそういう企業では、アジャイルでやっているところが多いと思う
絶え間ない製品のバージョンアップを繰り返してAWSのような化け物まで出来上がった >>81
品質悪化のリスクが大きいなら、リリースする必要がないでしょ >>82
考え方が逆
品質が安定するまでリリース出来ない作りや体制でやるよりも
修正しやすいように予め仕組みを作ってから細かくリリースしていくのが趣旨
リリース規模が大きいとそれだけ影響範囲も大きいし時間も掛かる
しかも下手するとリリース時点ではすでに役に立たないおそれがある >>84
いや、小さい規模のリリースでもきちんと作ってからリリースしろよ、という意味なんだが
リリースのたびに致命的な不具合があるなら信用無くなるよ >>85
別にアジャイルは品質を犠牲にはしない
でも短い期間での仕様変更の連発には対応する
これをどうやって実現するかというと、
- 機能の変更に強い良質なコードを書ける優秀なエンジニア「だけ」で構成されたチームを用意する
- 開発体制の面でもコードレビュー等のコードの品質も担保する仕組みを用意する
- テストコードを書いてデグレがないことをデプロイやコードのアップデートの度に検証できるようにする
- テストコードで各機能が壊れていないことをいつでも確認出来るので、リファクタし放題
まあつまり、海外の企業か国内なら一部のWeb系じゃないと、アジャイルはムリムリカタツムリ >>56
自分もそう思う。
アジャイルは自分たちの空き時間でシステムを作る場合に有効な方法だと思う。 >>88
わざわざ下請けにいてピンハネされるメリットが無い。 >>88
海外に下請けに出してる。
国内はSEの単金が高すぎてペイ出来ない。 スクリプト書きのドカタしかいないWeb系に優秀なプログラマがいるとは思えないな。 ■ このスレッドは過去ログ倉庫に格納されています
