【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 AjaxとAgileを間違えるなよ wwwwwwwwwww ,;:⌒:;,
8(･ω･)8 一歩間違えればグダグダになりかねん >>1
こんなんじゃ下請けに丸投げできないじゃないか 日本じゃ無理だけどね。
なんちゃってアジャイルならたくさんあるけども。
アジャイルの手法は真似ても、肝心の「お客さんもマネージャーも開発者も円卓をかこって平等に話し合おう」というアジャイルの目指すべきゴールが共有されていない。
身分制度が大好きで プロパー 派遣 契約 SI プログラマ に分かれて
更に
2次受け、3次受け、4次受け、5次受けと細かくわけられているから。
現場はマネージャーに意見せず、マネージャーは現場に無茶を押し付け、
マネージャーは売上を上げるため客からボッタクリを初め、
客はぼったくり見越してマネージャーに無茶苦茶言い、
現場は客の事なんか嫌いだから顧客に貢献度外視でただ怒られないように日々のタスクをこなすだけ >>1
アジャイルかガンダーラかというくらい遠い国の話だよ。 実際にやったら、アジャーってのもあるんじゃないの？ プロジェクトメンバーに宍戸江利花がいればいいんだろ？ Test Driven Development これにつきる、バグがこれでかなり減る ガチな質問で申し訳ないけど、スクラップアンドビルドとどう違いますか？
52の爺の疑問です。ググればでてくるのかな。 客としては
・システム全てがいつまでにできるかわかりません
・お金もトータルでどれぐらいかかるかわかりません
っていうのは社長の決裁も通りづらかろうｗ
あと、影響が大きすぎる仕様変更は小さなイテレーションでは捌ききれないんだよなぁ 毎週金曜日が納品日とか言う地獄
製造が終わってないのに月曜日から納品準備とか言う地獄 >>20
>・システム全てがいつまでにできるかわかりません
>・お金もトータルでどれぐらいかかるかわかりません
・システム全てをいつまでに本稼働させます
・開発予算はxx億円です
と言えばそれが実現できるわけじゃないからなー
結局ずるずると開発期間とコストは膨らんでいくんなら
はじめからアジャイルでもいいんじゃね？ >>24
ウォーターフォールでも、どうせ検収通るまで毎週評価版出すことになるし。
その間ずっと80h/weekで働くよりかは楽かな。 >>15
ソロでやるときは git の類が大活躍だよな 一人スパイラルやってた頃、工程ごとの検出障害数を出せって御触れが出て参ったっけ 「とりあえず作ってみてよw アジャイルって言うんでしょ、そういうの」 >>30
それがアジャイルのメリットだろ
最初の時点で仕様を決めるなんて無理なんだよ
客は素人なんだから F-2開発の時に日本の技術をパクッて作ろうとしてた
アジャイル・ファルコン計画ってのがあったな スクラップアンドビルドだと
つくって気に入らなかったら壊して
また最初からつくり直しみたいなニュアンスを感じる
アジャイルだと
最終的な形を最初に決めてしまうのではなく
第一バージョンをつくってみて
気に入らない点を整理して
第二バージョンに改造して
・・・
みたいな感じがする。
もちろん各段階で、さらに改造することを想定したつくりにしておいて 業務の根本が分かってないと、逆に
ぐだぐだな仕様になりそう。 >>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系に優秀なプログラマがいるとは思えないな。 ■ このスレッドは過去ログ倉庫に格納されています
