「アジャイル」と「ウォーターフォール」 - Digital Romanticism

アジャイルがダメだと思う7つの理由へのだいぶ遅い反応 導入 もうだいぶ前の話になってしまいましたが、アジャイルに関するブログエントリ「アジャイルがダメだと思う7つの理由」は予想以上に波紋を呼び、それに呼応していくつものエントリが公開されました。発端となったエントリに関していうと、通常であれば必要となる数々の留保事項や前提事項を書かずに切り込んでいるという点において、間違いなく「煽り」であると言えます。ただ、「アジャイル」という言葉をとりまく数々の事象をかなり的確に指摘することによって、「アジャイル」という言葉をパブリックな場所で語っている少なからぬ人たちに対して、（意識的か無意識的かは問わず）ある種のポジショニングを強いたという意味で、実にいい釣り針なのではないでしょうか。 個別の論点に関する「アジャイルでは全体スケジュールにコミットできない」「いや、アジャイルだって全体スケジュールにコミ

[atsushifx]

アジャイルマニフェストを読まないでいるとこういう議論になる。問題は開発手法ではなく契約。要求を期間内にすべて実現させるという日本のSIer方式が問題。本来のアジャイルはPragmaticで期間内でできないなら捨てる

[kappaseijin]

WBS、RFP、要件定義書を知らない人が話題にしているから話が噛み合わないのでは。API仕様書とかJavaDocこそ本当は要らない。

[uhe_uhe_uhe]

「アジャイル」という言葉を超えてかなり本質的な話。素晴らしい良記事だと思います。単能工と多能工、プッシュからプル、筆者の仕事に対するスタンスにとても好感を持ちました。

[seikoudoku2000]

この言葉かっこいい。いつか使ってみよう。/ GOOSではソースコードは「育てる」ものだとされていますが、そのソースコードが育つ方向性を事前に規定するのがアーキテクチャなのです。

[teppeis]

「単能工とコマンドコントロール」から「多能工と自己組織化」へ。

[tak4hir0]

「アジャイル」と「ウォーターフォール」 - Digital Romanticism Development, Essayアジャイルがダメだと思う7つの理由へのだいぶ遅い反応 導入もうだいぶ前の話になってしまいましたが、アジャイルに関するブログエントリ「アジ

[k-holy]

関連記事 http://jibun.atmarkit.co.jp/ljibun01/rensai/tabecho/05/01.html

[int128]

チームマネジメントの話（アジャイルは関係ない）

[onionskin]

「「分解されたタスクの指示書」がWBSの姿をしていることこそが、この構造が「ウォーターフォール」と呼ばれてしまう原因」

[yoshikogahaku]

アジャイルとウォーターフォールの良いところを合体させたアジャフォール！とか出てくるとアジャコングみたいでイイ。

[BooNoButa]

メモ

[kimihito]

「アジャイル」と「ウォーターフォール」 - Digital Romanticism

[hiroomi]

「フィードバックが届かない多重階層構造によって人が病み、サイロ構造によって成果物の品質も下がる」

[thesecret3]

自分の語りたい内容にひきよせちゃってる。

[masutaka26]

最近ウォーターフォールとアジャイルの違いが分からなくなってきた。いずれにせよ思考停止はイクナイ。

[kei_kei]

やり方じゃなくて組織構造の問題、ということか。

[mentum]

総じて先のことを予め考え、読んでおくことは常に必要／「指示を出す人／従う人」という構造に無理がある／「どう作るか」は手段／専門性を高めることと守備範囲を広げること

[tsuyok]

ふむ。チームのレベルにもよるよなー。経験的にも技術的にも考え方的にも。

[coolstyle]

自分が思ってた世間のもやもやを全て書いてくれた感じ。

[kyon_mm]

素晴らしいです。とても大切な視点だと思いました。

[ledsun]

読みながら「アジャイルができるようになったのは多能工が一定数以上育ったからかもなぁ・・・」などと考えていた。

[mickn]

「考えてわかることは、考える。考えてもわからないことは、どうすればわかるかを考えたうえで、そこまで手を進めてみる」