→開発プロセス


#contents


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

-[[炎上プロジェクトの責任はプロマネが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]
-[[それって本当に「スクラム」ですか? - Goodpatch Tech Blog>https://goodpatch-tech.hatenablog.com/entry/2022/12/25/000000]] 2022.12

-[[開発組織にはじめてのスクラムを導入する - Mirrativ Tech Blog>https://tech.mirrativ.stream/entry/2022/12/23/120216]] 2022.12

-[[ゾンビスクラムにならないための6つの問い - Alternative Architecture DOJO>https://aadojo.alterbooth.com/entry/2022/12/10/200000]] 2022.12
--1. ステークホルダーと協調して価値あるプロダクト作りはできていますか
--2. 動くプロダクトや価値あるインクリメントはありますか
--3. ゴールは適切に設定できていますか
--4. スクラムイベントは機械的になっていませんか
    スプリント: 他のイベントの実施するための期間の決められたタイムボックス
    スプリントプランニング: スプリントゴールを決め、達成にスプリントバックログを計画する
    デイリースクラム: スプリントゴールへの進捗状況を検査する
    スプリントレビュー: ステークホルダーからプロダクトのフィードバックを収集する
    スプリントレトロスペクティブ: スプリントのふりかえりを行う
--5. 継続的に改善ができていますか
--6. チームは自律的に行動し、プロダクトに対する重要な決定権をもっていますか(自己組織化できているか)

-[[新米スクラムマスターの思考メモ(その2 Retrospective編) | 豆蔵デベロッパーサイト>https://developer.mamezou-tech.com/blogs/2022/12/05/newcomer-scrum-master-02/]] 2022.12
--Retrospectiveがスクラムイベントの中では最も取り組みやすい

-[[スクラムチームの成果を最大化させた7つの改善 ~ 新米リーダーの挑戦 ~>https://zenn.dev/loglass/articles/b04910b823aead]] 2022.12
 1. プロダクトバックログアイテムの改善
 2. 完成の定義の改善
 3. 開発時間の改善
 4. Sprint Reviewの改善
 5. スクラムイベントの運用改善
 6. 顧客理解の改善
 7. 改善サイクルの改善

-[[私はスクラムを解っていなかった - LIVESENSE ENGINEER BLOG>https://made.livesense.co.jp/entry/2022/12/02/090000]] 2022.12

-[[スクラムチームの開発者は複数チームを兼務してもよいですか? | Ryuzee.com>https://www.ryuzee.com/faq/0087/]] 2022.11

-[[スクラム初心者が経験した、劇的ビフォーアフター - Qiita>https://qiita.com/yamamoto_anna/items/9532dbdd660d7b08e35f]] 2022.10
--1つ目の改善策、5本指表明を取り入れてみた
--2つ目の改善策、MIROを使って話し合いの短縮
--3つ目の改善策、チーム振り返り内に良かった所を褒めあう

-[[SSO(スクラム知らないおじさん)がスクラムチームにやって来た - ぐるなびをちょっと良くするエンジニアブログ>https://developers.gnavi.co.jp/entry/scrum-development]] 2022.10

-[[スクラム未経験者が約1年スクラムを経験した話について - nextbeat-engineering - Medium>https://medium.com/nextbeat-engineering/%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E6%9C%AA%E7%B5%8C%E9%A8%93%E8%80%85%E3%81%8C%E7%B4%841%E5%B9%B4%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%82%92%E7%B5%8C%E9%A8%93%E3%81%97%E3%81%9F%E8%A9%B1%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6-63fb2dcb0eac]] 2022.8

-[[それなりに長いことスクラム開発を続けて得た知見とこれから。>https://zenn.dev/peraichi/articles/01gb5eyntdmcamtvm4q3cndeh0]] 2022.8

-[[スクラムの各種イベントに対して懐疑的だったが、チームでの改善を繰り返すうちに意義を感じるようになった話 - commmune Engineer Blog>https://tech.commmune.jp/entry/2022/08/24/113000]] 2022.8

-[[スクラムでプロジェクトを始める前にお客様に説明しておきたいスクラムのエッセンス | DevelopersIO>https://dev.classmethod.jp/articles/the-essence-of-scrum-that-i-want-to-explain-to-customers/]] 2022.8
--1.アジャイル≠コスト削減
--2.タイムボックスの重要性
--3.スクラムは鏡
---「スクラムをやればうまくいくのではなく、スクラムはいかにチームが『出来ていないか』を見せつけられる鏡だ」
--4.プロジェクト開始当初など、ベロシティが上がらない時期もある
--5.スプリントゴール達成率は50%が健全
---「スクラムチームは作業見積もりにバッファを持たない」
---スプリントゴールの達成率が50%ということは、より高いゴールのために実験とチャレンジを継続しているということの現れであり、これはスクラムが健全に機能していることを表している

-[[【スクラム導入】経験者1人(自分)のみのチームにスクラムを導入した話 - Qiita>https://qiita.com/toripdev/items/2eba8745c8ddafa0b422]] 2022.8

-[[スクラム開発のために絶対理解しておくべきこと - YouTube>https://www.youtube.com/watch?v=-YcblVrRzGU]] 2022.7

-[[開発者がスクラムを嫌う7つの理由>https://twitter.com/iwashi86/status/1546108514845982722]] 2022.7
--1.POがデイリースタンドアップにいる
--2.スクラムマスタが開発に踏み込みすぎる
--3.新機能しか開発しない
--4.ストーリーポイントを時間として扱う
--5.スプリントを中止しない
--6.受け入れ基準が存在しない
--7.バーンダウンチャートで人を責める

-[[スクラム開発ってシンプルだよね、と思っていたら5年間で8つのアンチパターンを踏み抜いていた話 - TOWN株式会社>https://town.biz/blog/3450]] 2022.7

-[[スクラム開発のメリット 〜スクラム初心者が経験して感じたこと〜 - Safie Engineers' Blog!>https://engineers.safie.link/entry/2022/04/25/%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E9%96%8B%E7%99%BA%E3%81%AE%E3%83%A1%E3%83%AA%E3%83%83%E3%83%88_%E3%80%9C%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E5%88%9D%E5%BF%83%E8%80%85%E3%81%8C%E7%B5%8C%E9%A8%93]] 2022.4

-[[チームに初めてデザインスプリントを導入して体感したこと - LIFULL Creators Blog>https://www.lifull.blog/entry/2022/04/06/100000]] 2022.4

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

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

-[[スクラムガイド(日本語版)>https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf]] 2020


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

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


トップ   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS