アジャイルの履歴(No.15)

→開発プロセス

サブトピック
一般

サブトピック†

スクラム

↑

一般†

アジャイル失敗の本当の原因は？シリコンバレー経験を持つMIXIのスクラムマスターが明かす - エンジニアtype | 転職type 2023.12
- 「文化は組織構造に依存する」という言葉が非常に印象に残りました。いくらアジャイルやスクラムについて知識があり、高い理想を掲げたとしても、縦割りの組織構造やトップダウンによる指揮命令系統が残っていては、アジャイルに即したカルチャーは育めない
- 基本を軽視する姿勢こそが、アジャイル開発の失敗を招いているのではないかと感じます。

「アジャイルソフトウェア開発という概念」の源流は日本なのか〜『日本企業はなぜ「強み」を捨てるのか』を読んで〜 - bonotakeの日記 2023.10
- 1998年の青山論文をアジャイルの源流とするのは誤り

適切な問題設定と小さくリリースするということ / release small - Speaker Deck 2023.9

アジャイル開発は本当に必要なのか、何を解決するのか - Speaker Deck 2023.6

アジャイルの苦難の道のり｜ソフトウエア開発現場歴30年の経験者ブログ｜SHIFT Group 技術ブログ 2023.6

アジャイル開発とは？プロジェクト推進からチームビルディング、見積もりのコツまでを完全解説 | Think IT（シンクイット） 2023.5

【書籍】アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法

不確実性の時代に、アジャイル開発で向き合っていこう - ZDNET Japan 2023
- 第4回：アジャイルに対する誤解（1）--設計せずにいきなり作る？文書を書かない？ - ZDNET Japan 2023.3

大企業を変革せよ！「すごいリーダー」不在のアジャイルチャレンジ - Speaker Deck 2023.3

長期のプロジェクトを小さく完了していく - KAKEHASHI Tech Blog 2022.12

大規模アジャイル手法を鳥の目で眺める | 豆蔵デベロッパーサイト 2022.12
- 大規模アジャイルはそもそも難しいということを理解すること
- 取り組むならば年単位の試行錯誤を覚悟すること
- 普通のアジャイルチームもないうちから大規模とか言うなコラ

XPエクストリームプログラミングは偉大だ～時代がその設計思想に追いついた: プログラマの思索 2022.11

アジャイルを始めて10年。ようやくアジャイル開発の目的がわかるようになってきた - TOWN株式会社 2022.6

ウォーターフォールやってたけど、アジャイル開発をはじめてしばらくたったので基本からおさらいしてみた - TOWN株式会社 2022.6

アジャイルに対する6つの誤解 - エムティーアイエンジニアリングブログ 2022.6

   1.「計画を立てない」
   2.「要求変更は自由である」
   3.「ドキュメントはいらない」
   4.「プロジェクトマネジメントはいらない」
   5.「スクラムマスターはいらない」
   6.「アジャイル＝ソフトウェア開発方法論と捉え、IT部門が開発を考えるべき」

ユーザー要望で要件が増えてく〜アジャイル開発での落とし穴〜 | フューチャー技術ブログ 2022.6

富士通が｢巨額をかけた残念なシステム作り｣から一線を引けるようになったワケ 2021.8

「アジャイルがダメだと思う7つの理由」から始まったアジャイル論争の現時点のまとめ 2013.4.2

アジャイルがダメだと思う7つの理由 - arclamp 2013.3

1.全体スケジュールにコミットできない
2.アーキテクチャ上の無駄が生じる
3.コーチって何だよ
4.変化ヲ抱擁スルために固定化している
5.実証主義的な説明に過ぎない
6.手段が目的になっている
7.アジリティはアジャイルだけのものではない

ドラクエXマネージャが語る大規模アジャイル開発の極意 2012.8.29

こんなプログラマはアジャイル出来ますって言ったらアカンやろ 2012.8.10

一括請負という契約形態のままアジャイル化するのは危ない 2012.6.12

プロジェクトという形態は下火になり、プロダクト開発が台頭している。IPAの調査から 2012.6.14

海外でなぜアジャイル開発が普及しているのか？ IPAが分析と提言 2012.6.13
- 米国では、ソフトウェアに対する投資が「自社開発（内製）」「パッケージソフト」で約3分の2を占めており、IT技術者の7割以上がユーザー企業に属しているという特徴が見られました。つまり他国に比べて同一組織内でソフトウェア開発を行うことが多く、契約を交わす必要がないため、ソフトウェアの変更に対応しやすいと考えられます。
- デンマークでは政府が発注するソフトウェア開発をアジャイル開発で行うことが推奨されており、できるだけ小さく始め、柔軟な計画変更ができるといった契約になっているそうです。

炎上プロジェクトの責任はプロマネが９割 2014.1.26
- ウォーターフォールとアジャイルの比較

Agile in 30mins 2010.10.23
日経ITProの記事にケチつけておく 2010.8.23

アジャイルはウォーターフォールよりも難しい 2010.8.20

現代のAgile開発が抱える課題 2010.8.9
- 【1】Agile開発はプロジェクト管理が弱い
- 【2】Agile開発はスケールアップが難しい
- 【3】Agile開発はアーキテクチャや品質の作り込みの観点が弱い
- 【4】Agile開発は分散開発まで考慮されていない

Hudson を使ったアジャイルな開発入門

アジャイルって受託開発との相性が最悪な気がする 2010.2.12
- 工程の分断が絶対許されないから、上流工程と下流工程を別会社が担当する今の日本の受託開発業との相性は最悪だね。自分たちで全部やれる人材が揃ってないといけない上に、コミュニケーションを綿密にとらないと成果物がグダグダになりそうだから、人月との相性も悪い。
- 要件まとめてぽーんと丸投げしたほうがSIerとしては美味しいわけだから、なんでこんな苦労を別にしなくちゃならないの的な話になってる所がいっぱいいそうなんだけど、どうだろう。アジャイル導入って自己否定なんじゃないのかしら。だからやりたくても出来ないんだね、これ。
- 滝には色々問題があるけれど、滝は契約体系としてはわかりやすいし、お金の積み方が合理的に説明しやすいという点はあると思う。リスクマネーが利益の源泉になることが多いしリスク取るからおカネを請求できるわけで、そこが不明瞭で不確かだろうが｢○○円でいつまでにやります｣とコミットするから契約を結ぶ価値が出てくるわけなんだけど、アジャイル開発のやり方だとどう説明するの？
アジャイルは二度死ぬ
Through 分類別INDEX
Agileが根付かないもう一つの理由 2009.2.28
- 「1年間1.2億円」で見積もったプロジェクトがあったとしよう。
- 下記筋書きのどちらが嬉しい？
  - 開始後一ヶ月で中止に追い込まれ、お客さんからは月割りで1000万円だけしか回収できなかった。ただし、デスマーチにはならなかった。チームは次の仕事に向けて鋭気を維持できた。
  - 1年間開発を続けたが完了せず、要員追加＆デスマーチで2ヶ月超過。お客さんからは1.2億円もらったが、超過分の原価で赤字になった。チームの半分以上は病気になった。
- ほとんどの受託システム開発業者は、後者を選ぶのではないかな。DDJの記事にあるように、Agileの失敗率は「20%」。2割の確率で予算未達が発生する、と考えるとビビる経営者は多いはず。
- 予算達成重視主義も、日本におけるAgile普及の足かせになっているのではないかね。

裏プロセスは並行プロセス 2008.2.20
- 大規模プロジェクトでアジャイル開発を選択できない最大の理由は、機能分割するモデリング力が足りないからではないか、と推測している。
- イテレーション毎にリリースしていくには、膨大で複雑な業務を、イテレーションが定める期間内かつリリースできる単位に機能分割して仕様へ落とさなければならない。

大企業を変革せよ！「すごいリーダー」不在のアジャイルチャレンジ - Speaker Deck 20??

アジャイル の履歴(No.15)

サブトピック†

一般†

アジャイルの履歴(No.15)