→開発プロセス


#contents


* 話題など [#a405351c]
-[[富士通が「巨額をかけた残念なシステム作り」から一線を引けるようになったワケ>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割以上がユーザー企業に属しているという特徴が見られました。つまり他国に比べて同一組織内でソフトウェア開発を行うことが多く、契約を交わす必要がないため、ソフトウェアの変更に対応しやすいと考えられます。
--デンマークでは政府が発注するソフトウェア開発をアジャイル開発で行うことが推奨されており、できるだけ小さく始め、柔軟な計画変更ができるといった契約になっているそうです。

-[[炎上プロジェクトの責任はプロマネが9割>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]]
-[[アジャイル・プロセス協議会:http://www.agileprocess.jp/index.jsp]]


*スクラム [#e0558345]
-[[スクラムにおける朝会の目的は進捗共有ではないよという話 - Qiita>https://qiita.com/getty104/items/35ccb10ce660e7487ef8]] 2021.5

-チームの人数は10人を目安とする
-スプリント:1〜4週間単位で 設計→実装→テスト のサイクルを回す工程の単位
-デイリースクラム:15分程度の毎日の朝会。昨日やったこと、今日やること、遂行時の障害や課題の報告。

-バックログ
--プロダクト・バックログ
---機能
---技術的改善要素
---各項目の優先順位
---ユーザストーリー形式 誰のため? なんのため?
--スプリント・バックログ
---チームごとのタスクリスト
---プロダクト・バックログから抜き出し
--タスクボード(ToDo/InProgress/Done カンバンの一種?)

-[[Scrumの公開資料>http://forza.cocolog-nifty.com/blog/2012/06/scrum-8d22.html]] 2012.6.10

トップ   編集 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS