![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2024-04-23T12:26:53+09:00","default:irrp","irrp") #author("2024-04-23T21:59:19+09:00","default:irrp","irrp") →開発プロセス #contents *サブトピック [#h9cdfe3d] -スクラム * 一般 [#w6ca638c] -[[これからのプロジェクトマネジメントに大事なのは「結果にコミットしない」こと クリエイティブな仕事に求められる“アジャイル思考” - ログミーTech>https://logmi.jp/tech/articles/330431]] 2024.4 -[[KDDIのアジャイル開発推進ストーリー──進化する組織を支える開発生産性向上の秘訣とは？ (1/3)|CodeZine（コードジン）>https://codezine.jp/article/detail/19254]] 2024.4 -[[受託開発におけるアジャイルに限界を感じた私が、「納品のない受託開発」を始めるまで - 倉貫義人の「はじめてのアジャイル」 - Agile Journey>https://agilejourney.uzabase.com/entry/2024/03/25/103000]] 2024.3 -[[アジャイルソフトウェア開発 - アンサイクロペディア>https://ja.uncyclopedia.info/wiki/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA#cite_note-2]] 2023 --※かなり皮肉の効いた文章だが、一面の真実が語られている -[[アジャイルの価値を活かせる受託開発案件の取り方・始め方 | ドクセル>https://www.docswell.com/s/aratafuji/54Q7MN-rsgt2024-aratafuji]] 2024.1 -[[アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは | Social Change!>https://kuranuki.sonicgarden.jp/archives/10201]] 2023.12 -[[アジャイル失敗の本当の原因は？ シリコンバレー経験を持つMIXIのスクラムマスターが明かす - エンジニアtype | 転職type>https://type.jp/et/feature/24095/]] 2023.12 --「文化は組織構造に依存する」という言葉が非常に印象に残りました。いくらアジャイルやスクラムについて知識があり、高い理想を掲げたとしても、縦割りの組織構造やトップダウンによる指揮命令系統が残っていては、アジャイルに即したカルチャーは育めない --基本を軽視する姿勢こそが、アジャイル開発の失敗を招いているのではないかと感じます。 -[[「アジャイルソフトウェア開発という概念」の源流は日本なのか 〜『日本企業はなぜ「強み」を捨てるのか 』を読んで〜 - bonotakeの日記>https://bonotake.hatenablog.com/entry/2023/10/24/055537]] 2023.10 --1998年の青山論文をアジャイルの源流とするのは誤り -[[適切な問題設定と小さくリリースするということ / release small - Speaker Deck>https://speakerdeck.com/soudai/release-small]] 2023.9 -[[アジャイル開発は本当に必要なのか、何を解決するのか - Speaker Deck>https://speakerdeck.com/yuukiyo/is-agile-development-really-necessary-and-what-does-it-solve]] 2023.6 -[[アジャイルの苦難の道のり｜ソフトウエア開発現場歴30年の経験者ブログ｜SHIFT Group 技術ブログ>https://note.com/shift_tech/n/nbdbdc417654f#a5fe9a63-8741-4ba4-972e-f6ebde35110a]] 2023.6 -[[アジャイル開発とは？プロジェクト推進からチームビルディング、見積もりのコツまでを完全解説 | Think IT（シンクイット）>https://thinkit.co.jp/article/22032]] 2023.5 -[[【書籍】アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法>https://amzn.to/3C5j8oW]] -[[不確実性の時代に、アジャイル開発で向き合っていこう - ZDNET Japan>https://japan.zdnet.com/development/sp_23agile_development/]] 2023 --[[第4回： アジャイルに対する誤解（1）--設計せずにいきなり作る？文書を書かない？ - ZDNET Japan>https://japan.zdnet.com/article/35200754/]] 2023.3 -[[大企業を変革せよ！「すごいリーダー」不在のアジャイルチャレンジ - Speaker Deck>https://speakerdeck.com/ynishiuchi/20230304-agile-challenge]] 2023.3 -[[長期のプロジェクトを小さく完了していく - KAKEHASHI Tech Blog>https://kakehashi-dev.hatenablog.com/entry/2022/12/22/093000]] 2022.12 -[[大規模アジャイル手法を鳥の目で眺める | 豆蔵デベロッパーサイト>https://developer.mamezou-tech.com/blogs/2022/12/14/scaling-agile-birdview/]] 2022.12 --大規模アジャイルはそもそも難しいということを理解すること --取り組むならば年単位の試行錯誤を覚悟すること --普通のアジャイルチームもないうちから大規模とか言うなコラ -[[XPエクストリームプログラミングは偉大だ〜時代がその設計思想に追いついた: プログラマの思索>https://forza.cocolog-nifty.com/blog/2022/11/post-ff6f5f.html]] 2022.11 -[[アジャイルを始めて10年。ようやくアジャイル開発の目的がわかるようになってきた - TOWN株式会社>https://town.biz/blog/2775]] 2022.6 -[[ウォーターフォールやってたけど、アジャイル開発をはじめてしばらくたったので基本からおさらいしてみた - TOWN株式会社>https://town.biz/blog/2785]] 2022.6 -[[アジャイルに対する6つの誤解 - エムティーアイ エンジニアリングブログ>https://tech.mti.co.jp/entry/2022/06/10/080000]] 2022.6 1.「計画を立てない」 2.「要求変更は自由である」 3.「ドキュメントはいらない」 4.「プロジェクトマネジメントはいらない」 5.「スクラムマスターはいらない」 6.「アジャイル＝ソフトウェア開発方法論と捉え、IT部門が開発を考えるべき」 -[[ユーザー要望で要件が増えてく〜アジャイル開発での落とし穴〜 | フューチャー技術ブログ>https://future-architect.github.io/articles/20220608a/]] 2022.6 -[[富士通が｢巨額をかけた残念なシステム作り｣から一線を引けるようになったワケ>https://president.jp/articles/-/49055]] 2021.8 -[[「アジャイルがダメだと思う7つの理由」から始まったアジャイル論争の現時点のまとめ>http://www.publickey1.jp/blog/13/7_3.html]] 2013.4.2 --[[アジャイルがダメだと思う7つの理由 - arclamp>https://arclamp.hatenablog.com/entry/2013/03/21/233012]] 2013.3 1.全体スケジュールにコミットできない 2.アーキテクチャ上の無駄が生じる 3.コーチって何だよ 4.変化ヲ抱擁スルために固定化している 5.実証主義的な説明に過ぎない 6.手段が目的になっている 7.アジリティはアジャイルだけのものではない -[[ドラクエXマネージャが語る大規模アジャイル開発の極意>http://www.atmarkit.co.jp/news/201208/29/cedec_araki.html]] 2012.8.29 -[[こんなプログラマはアジャイル出来ますって言ったらアカンやろ>http://d.hatena.ne.jp/simplearchitect/20120810/1344615415]] 2012.8.10 -[[一括請負という契約形態のままアジャイル化するのは危ない>http://ssff.hateblo.jp/entry/2012/06/12/230847]] 2012.6.12 -[[プロジェクトという形態は下火になり、プロダクト開発が台頭している。IPAの調査から>http://www.publickey1.jp/blog/12/ipa.html]] 2012.6.14 -[[海外でなぜアジャイル開発が普及しているのか？ IPAが分析と提言>http://www.publickey1.jp/blog/12/_ipaga.html]] 2012.6.13 --米国では、ソフトウェアに対する投資が「自社開発（内製）」「パッケージソフト」で約3分の2を占めており、IT技術者の7割以上がユーザー企業に属しているという特徴が見られました。つまり他国に比べて同一組織内でソフトウェア開発を行うことが多く、契約を交わす必要がないため、ソフトウェアの変更に対応しやすいと考えられます。 --デンマークでは政府が発注するソフトウェア開発をアジャイル開発で行うことが推奨されており、できるだけ小さく始め、柔軟な計画変更ができるといった契約になっているそうです。 -[[炎上プロジェクトの責任はプロマネが９割>http://getlife.hateblo.jp/entry/2014/01/26/045603]] 2014.1.26 --ウォーターフォールとアジャイルの比較 -[[Agile in 30mins>http://www.slideshare.net/kakutani/agile-in-30mins]] 2010.10.23 -[[日経ITProの記事にケチつけておく>http://d.hatena.ne.jp/masayang/20100823/1282603810]] 2010.8.23 -[[アジャイルはウォーターフォールよりも難しい>http://itpro.nikkeibp.co.jp/article/Watcher/20100820/351255/]] 2010.8.20 -[[現代のAgile開発が抱える課題>http://forza.cocolog-nifty.com/blog/2010/08/agile-a643.html]] 2010.8.9 --【1】Agile開発はプロジェクト管理が弱い --【2】Agile開発はスケールアップが難しい --【3】Agile開発はアーキテクチャや品質の作り込みの観点が弱い --【4】Agile開発は分散開発まで考慮されていない -[[Hudson を使ったアジャイルな開発入門>http://gihyo.jp/dev/feature/01/hudson/0001]] -[[アジャイルって受託開発との相性が最悪な気がする>http://d.hatena.ne.jp/gothedistance/20100212/1265907956]] 2010.2.12 --工程の分断が絶対許されないから、上流工程と下流工程を別会社が担当する今の日本の受託開発業との相性は最悪だね。自分たちで全部やれる人材が揃ってないといけない上に、コミュニケーションを綿密にとらないと成果物がグダグダになりそうだから、人月との相性も悪い。 --要件まとめてぽーんと丸投げしたほうがSIerとしては美味しいわけだから、なんでこんな苦労を別にしなくちゃならないの的な話になってる所がいっぱいいそうなんだけど、どうだろう。アジャイル導入って自己否定なんじゃないのかしら。だからやりたくても出来ないんだね、これ。 --滝には色々問題があるけれど、滝は契約体系としてはわかりやすいし、お金の積み方が合理的に説明しやすいという点はあると思う。リスクマネーが利益の源泉になることが多いしリスク取るからおカネを請求できるわけで、そこが不明瞭で不確かだろうが｢○○円でいつまでにやります｣とコミットするから契約を結ぶ価値が出てくるわけなんだけど、アジャイル開発のやり方だとどう説明するの？ -[[アジャイルは二度死ぬ>http://www.anyprojecta.com/project/265.html]] -[[Through 分類別INDEX>http://www.mars.dti.ne.jp/~hirok/xp/col/index_f.html]] -[[Agileが根付かないもう一つの理由>http://d.hatena.ne.jp/masayang/20081204/1228458032]] 2009.2.28 --「1年間1.2億円」で見積もったプロジェクトがあったとしよう。 --下記筋書きのどちらが嬉しい？ ---開始後一ヶ月で中止に追い込まれ、お客さんからは月割りで1000万円だけしか回収できなかった。ただし、デスマーチにはならなかった。チームは次の仕事に向けて鋭気を維持できた。 ---1年間開発を続けたが完了せず、要員追加＆デスマーチで2ヶ月超過。お客さんからは1.2億円もらったが、超過分の原価で赤字になった。チームの半分以上は病気になった。 --ほとんどの受託システム開発業者は、後者を選ぶのではないかな。DDJの記事にあるように、Agileの失敗率は「20%」。2割の確率で予算未達が発生する、と考えるとビビる経営者は多いはず。 --予算達成重視主義も、日本におけるAgile普及の足かせになっているのではないかね。 -[[裏プロセスは並行プロセス>http://forza.cocolog-nifty.com/blog/2009/02/post-1bc1.html]] 2008.2.20 --大規模プロジェクトでアジャイル開発を選択できない最大の理由は、機能分割するモデリング力が足りないからではないか、と推測している。 --イテレーション毎にリリースしていくには、膨大で複雑な業務を、イテレーションが定める期間内かつリリースできる単位に機能分割して仕様へ落とさなければならない。 -[[アジャイルの衰退と凋落>http://www.hyuki.com/yukiwiki/wiki.cgi?DeclineAndFallOfAgile]] -[[ソフトウェアは育てる時代へ>http://itpro.nikkeibp.co.jp/article/NEWS/20080906/314278/]] 2008.9.6 -[[『アジャイルプラクティス』はスゴ本>http://dain.cocolog-nifty.com/myblog/2008/02/post_918a.html]] -[[いいアジャイルと悪いアジャイル:http://www.aoky.net/articles/steve_yegge/good_agile_bad_agile.htm]] -[[Agileで始める実践アジャイル開発:http://www.atmarkit.co.jp/fdotnet/nagile/index/index.html]] -[[大企業を変革せよ！「すごいリーダー」不在のアジャイルチャレンジ - Speaker Deck>https://speakerdeck.com/ynishiuchi/20230304-agile-challenge]] 20??
