ここ
アジャイルを過大評価してる奴wwwwwwwwww
http://blog.livedoor.jp/itsoku/archives/48315925.html
に「アジャイルってつまるところ・・・内製じゃね?」ってあるけど、
内製ではなく、中抜き。
アジャイルは、アジャイルソフトウェア開発宣言に沿っているものを言う。これを現代風に書き換えれば、中抜きだとわかる。
銀行のソフトウェア開発を想像してください。「アジャイルソフトウェア開発宣言」にあわせていきますよ・・
(ここから)-------------------
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
→自動的にドキュメントからプログラムを自動生成しますよという某社のツールよりも
末端のSEさんとの対話とか独白(2ちゃんねる?)に
包括的なドキュメントよりも動くソフトウェアを、
→ドキュメントに付箋紙はって、そこを差し替えて直しているより、
動くソフトウェアに
契約交渉よりも顧客との協調を、
→中間業者の契約で無理いって優秀なSEが抜けるより
顧客と直接対話して予算もらうことに
計画に従うことよりも変化への対応を、
→スケジュール駆動で無理な計画を立てるより
実際出来ないものは出来ないと認めて、やり直したほうに
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
→価値があると考える。いままでのウォーターフォール、
スケジュール駆動の自動化開発が悪いとは言わないが、
現実を見つめて、働いている末端SEさんの話に価値を置く。
--------(ここまで)
そのためには、顧客と末端SEが直接話す機会を設けて、
短い期間でモノをみせたほうがいい。直接やるなら、
ドキュメントなんて要らないっていう話になってくる。
これがアジャイル
・・・ということは、顧客と末端SEが直接話す=中抜き
でも、これを実現するには、開発者には
「オーバーヘッダーズ」改め「デジタルあきんど」になりなさい! 基幹系に関わった経験は必ず生きる
http://itpro.nikkeibp.co.jp/atcl/column/14/463805/040700082/?ST=system&P=4
にあるように(以下太字は上記サイトから引用)
プログラムが書けて(書かないことと書けないことは違う)、クラウドネイティブの最新技術に精通し、ビジネス側の人たちと、ITを使った新サービスのビジネスモデルを考えられなければならない。
つまり、
ビジネスモデルを考えるのが三度の飯より好きなシリコンバレーの技術者と同じ
ってこと
ただし、実際には、顧客と開発者が直接話しが出来る規模というのは、
ある程度の開発規模までに限られる。大規模開発の場合、
炎上プロジェクトはどうして復活できるのか―伝説のプロマネが会社を救う (4/6)
http://itpro.nikkeibp.co.jp/atcl/column/15/060800143/040700036/?ST=management&P=4
にあるような(以下斜体は上記サイトより引用)
個別のチームやメンバーが何をしているのかを把握し、完了した仕事をチェックして、各チームから上がってくる課題を一つひとつ整理して解消する
プロジェクトマネージメントのほうが、顧客と開発者の直接対話より重要になる
・・・が、上記のプロジェクトマネージメントもアジャイルの範囲であったりはするが・・・
アジャイルを過大評価してる奴wwwwwwwwww
http://blog.livedoor.jp/itsoku/archives/48315925.html
に「アジャイルってつまるところ・・・内製じゃね?」ってあるけど、
内製ではなく、中抜き。
アジャイルは、アジャイルソフトウェア開発宣言に沿っているものを言う。これを現代風に書き換えれば、中抜きだとわかる。
銀行のソフトウェア開発を想像してください。「アジャイルソフトウェア開発宣言」にあわせていきますよ・・
(ここから)-------------------
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
→自動的にドキュメントからプログラムを自動生成しますよという某社のツールよりも
末端のSEさんとの対話とか独白(2ちゃんねる?)に
包括的なドキュメントよりも動くソフトウェアを、
→ドキュメントに付箋紙はって、そこを差し替えて直しているより、
動くソフトウェアに
契約交渉よりも顧客との協調を、
→中間業者の契約で無理いって優秀なSEが抜けるより
顧客と直接対話して予算もらうことに
計画に従うことよりも変化への対応を、
→スケジュール駆動で無理な計画を立てるより
実際出来ないものは出来ないと認めて、やり直したほうに
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
→価値があると考える。いままでのウォーターフォール、
スケジュール駆動の自動化開発が悪いとは言わないが、
現実を見つめて、働いている末端SEさんの話に価値を置く。
--------(ここまで)
そのためには、顧客と末端SEが直接話す機会を設けて、
短い期間でモノをみせたほうがいい。直接やるなら、
ドキュメントなんて要らないっていう話になってくる。
これがアジャイル
・・・ということは、顧客と末端SEが直接話す=中抜き
でも、これを実現するには、開発者には
「オーバーヘッダーズ」改め「デジタルあきんど」になりなさい! 基幹系に関わった経験は必ず生きる
http://itpro.nikkeibp.co.jp/atcl/column/14/463805/040700082/?ST=system&P=4
にあるように(以下太字は上記サイトから引用)
プログラムが書けて(書かないことと書けないことは違う)、クラウドネイティブの最新技術に精通し、ビジネス側の人たちと、ITを使った新サービスのビジネスモデルを考えられなければならない。
つまり、
ビジネスモデルを考えるのが三度の飯より好きなシリコンバレーの技術者と同じ
ってこと
ただし、実際には、顧客と開発者が直接話しが出来る規模というのは、
ある程度の開発規模までに限られる。大規模開発の場合、
炎上プロジェクトはどうして復活できるのか―伝説のプロマネが会社を救う (4/6)
http://itpro.nikkeibp.co.jp/atcl/column/15/060800143/040700036/?ST=management&P=4
にあるような(以下斜体は上記サイトより引用)
個別のチームやメンバーが何をしているのかを把握し、完了した仕事をチェックして、各チームから上がってくる課題を一つひとつ整理して解消する
プロジェクトマネージメントのほうが、顧客と開発者の直接対話より重要になる
・・・が、上記のプロジェクトマネージメントもアジャイルの範囲であったりはするが・・・