→開発プロセス
話題など†
- 海外でなぜアジャイル開発が普及しているのか? IPAが分析と提言 2012.6.13
- 米国では、ソフトウェアに対する投資が「自社開発(内製)」「パッケージソフト」で約3分の2を占めており、IT技術者の7割以上がユーザー企業に属しているという特徴が見られました。つまり他国に比べて同一組織内でソフトウェア開発を行うことが多く、契約を交わす必要がないため、ソフトウェアの変更に対応しやすいと考えられます。
- デンマークでは政府が発注するソフトウェア開発をアジャイル開発で行うことが推奨されており、できるだけ小さく始め、柔軟な計画変更ができるといった契約になっているそうです。
- 現代のAgile開発が抱える課題 2010.8.9
- 【1】Agile開発はプロジェクト管理が弱い
- 【2】Agile開発はスケールアップが難しい
- 【3】Agile開発はアーキテクチャや品質の作り込みの観点が弱い
- 【4】Agile開発は分散開発まで考慮されていない
- アジャイルって受託開発との相性が最悪な気がする 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
- 大規模プロジェクトでアジャイル開発を選択できない最大の理由は、機能分割するモデリング力が足りないからではないか、と推測している。
- イテレーション毎にリリースしていくには、膨大で複雑な業務を、イテレーションが定める期間内かつリリースできる単位に機能分割して仕様へ落とさなければならない。
スクラム†
- スクラムでプロジェクトを始める前にお客様に説明しておきたいスクラムのエッセンス | DevelopersIO 2022.8
- 1.アジャイル≠コスト削減
- 2.タイムボックスの重要性
- 3.スクラムは鏡
- 「スクラムをやればうまくいくのではなく、スクラムはいかにチームが『出来ていないか』を見せつけられる鏡だ」
- 4.プロジェクト開始当初など、ベロシティが上がらない時期もある
- 5.スプリントゴール達成率は50%が健全
- 「スクラムチームは作業見積もりにバッファを持たない」
- スプリントゴールの達成率が50%ということは、より高いゴールのために実験とチャレンジを継続しているということの現れであり、これはスクラムが健全に機能していることを表している
- 開発者がスクラムを嫌う7つの理由 2022.7
- 1.POがデイリースタンドアップにいる
- 2.スクラムマスタが開発に踏み込みすぎる
- 3.新機能しか開発しない
- 4.ストーリーポイントを時間として扱う
- 5.スプリントを中止しない
- 6.受け入れ基準が存在しない
- 7.バーンダウンチャートで人を責める
スクラムの基本†
- チームの人数は10人を目安とする
- スプリント:1〜4週間単位で 設計→実装→テスト のサイクルを回す工程の単位
- デイリースクラム:15分程度の毎日の朝会。昨日やったこと、今日やること、遂行時の障害や課題の報告。
- バックログ
- プロダクト・バックログ
- 機能
- 技術的改善要素
- 各項目の優先順位
- ユーザストーリー形式 誰のため? なんのため?
- スプリント・バックログ
- チームごとのタスクリスト
- プロダクト・バックログから抜き出し
- タスクボード(ToDo/InProgress/Done カンバンの一種?)
Last-modified: 2023-06-07 (水) 14:40:54