![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2024-04-12T11:12:38+09:00","default:irrp","irrp") #author("2024-04-22T14:34:33+09:00","default:irrp","irrp") →開発プロセス →アジャイル #contents *一般 [#ac257ebd] -[[スクラム開発がエンジニアから成長機会を奪うかもしれない話 - 開発日報>https://ponpon-soft.com/entry/2023/12/31/000514]] 2023 -[[GitHub Projectsを使った（プロダクト/ スプリント）バックログ管理 #スクラム | DevelopersIO>https://dev.classmethod.jp/articles/scrum-backlog-github-projects/]] 2024.4 -[[スクラムガイドを読んでスクラム開発の理解を深める>https://zenn.dev/voicy/articles/7cd948f6b88edc]] 2024.3 -[[本に書いてあるスクラムと、お前らのいうスクラム開発は別物だということにいい加減気づいてくれ>https://zenn.dev/shin_semiya/articles/13ecfad2d0f126#%E3%80%8C%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%82%92%E5%A7%8B%E3%82%81%E3%81%9F%E3%81%84%E3%80%8D%E3%81%A8%E7%B5%8C%E5%96%B6%E9%99%A3%E3%81%8C%E8%A8%80%E3%81%A3%E3%81%9F%E3%81%A8%E3%81%8D%E3%80%81%E8%87%AA%E5%88%86%E3%81%AF%E3%81%A9%E3%81%86%E3%81%99%E3%82%8B%E3%81%B9%E3%81%8D%E3%81%8B%E3%80%82%E3%83%AC%E3%83%99%E3%83%AB3%E3%81%AE%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%82%92%E5%A7%8B%E3%82%81%E3%82%8B%E3%81%AB%E3%81%AF%E3%81%A9%E3%81%86%E8%A8%80%E3%81%86%E4%BA%BA%E6%9D%90%E3%81%8C%E5%BF%85%E8%A6%81%E3%81%AA%E3%81%AE%E3%81%8B]] 2024.2 -[[スクラムを0から導入してみた話 - JMDC TECH BLOG>https://techblog.jmdc.co.jp/entry/20231206]] 2023.12 -[[スクラムでストーリーポイントを時間に紐付けて運用すると何が起きるか - Qiita>https://qiita.com/junseinagao/items/5558b9f8523e012c7a53]] 2023.6 --ストーリーポイントの基準を時間にして運用するとストーリーポイントを工数見積もりとして濫用される危険性があります。 --工数見積もりとストーリーポイントはまったく別々に運用されるべきです。 -[[アジャイル初心者が聖書「スクラムガイド」を読んで図解してみた - Qiita>https://qiita.com/minorun365/items/8353f772609bd094c16f]] 2023.6 -[[「終わらなかったから次のスプリントにまわそう」なんてありえない – 旅と子育てとアジャイルコーチのブログ「世界」>https://daipresents.com/2023/06/02/sprint-done/]] 2023.6 -[[「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」とか言うお前らに告ぐ>https://zenn.dev/shin_semiya/articles/47775ff1659e3a]] 2023.5 -[[スラクムを電車にたとえて説明してみた - arclamp>https://arclamp.hatenablog.com/entry/2023/03/30/174712]] 2023.3 -[[スクラム開発でベロシティが約3倍になった話 | Offers Tech Blog>https://zenn.dev/offers/articles/20230316-story-of-how-velocity-tripled-in-scrum]] 2023.3 -[[アジャイルとスクラム何が違うの？ | DevelopersIO>https://dev.classmethod.jp/articles/what-agile-scrum/]] 2023.3 --アジャイル = 原理原則・概念・マインドセット --スクラム = 方法論・開発手法 -[[それって本当に「スクラム」ですか？ - 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. チームは自律的に行動し、プロダクトに対する重要な決定権をもっていますか（自己組織化できているか） -[[新米スクラムマスターの思考メモ（その２ 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 --１．アジャイル≠コスト削減 --２．タイムボックスの重要性 --３．スクラムは鏡 ---「スクラムをやればうまくいくのではなく、スクラムはいかにチームが『出来ていないか』を見せつけられる鏡だ」 --４．プロジェクト開始当初など、ベロシティが上がらない時期もある --５．スプリントゴール達成率は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.バーンダウンチャートで人を責める -[[スクラム開発ってシンプルだよね、と思っていたら５年間で８つのアンチパターンを踏み抜いていた話 - 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人を目安とする -スプリント：１〜４週間単位で 設計→実装→テスト のサイクルを回す工程の単位 -デイリースクラム：15分程度の毎日の朝会。昨日やったこと、今日やること、遂行時の障害や課題の報告。 -バックログ --プロダクト・バックログ ---機能 ---技術的改善要素 ---各項目の優先順位 ---ユーザストーリー形式 誰のため？ なんのため？ --スプリント・バックログ ---チームごとのタスクリスト ---プロダクト・バックログから抜き出し --タスクボード（ToDo/InProgress/Done カンバンの一種？）
