アジャイル

→開発プロセス

話題など†

• アジャイルの苦難の道のり｜ソフトウエア開発現場歴30年の経験者ブログ｜SHIFT Group 技術ブログ 2023.6

• アジャイル開発とは？プロジェクト推進からチームビルディング、見積もりのコツまでを完全解説 | Think IT（シンクイット） 2023.5

• 【書籍】アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法

• 不確実性の時代に、アジャイル開発で向き合っていこう - ZDNET Japan 2023
  • 第4回： アジャイルに対する誤解（1）--設計せずにいきなり作る？文書を書かない？ - ZDNET Japan 2023.3

• 大企業を変革せよ！「すごいリーダー」不在のアジャイルチャレンジ - Speaker Deck 2023.3

• 長期のプロジェクトを小さく完了していく - KAKEHASHI Tech Blog 2022.12

• 大規模アジャイル手法を鳥の目で眺める | 豆蔵デベロッパーサイト 2022.12
  • 大規模アジャイルはそもそも難しいということを理解すること
  • 取り組むならば年単位の試行錯誤を覚悟すること
  • 普通のアジャイルチームもないうちから大規模とか言うなコラ

• XPエクストリームプログラミングは偉大だ〜時代がその設計思想に追いついた: プログラマの思索 2022.11

• アジャイルを始めて10年。ようやくアジャイル開発の目的がわかるようになってきた - TOWN株式会社 2022.6

• ウォーターフォールやってたけど、アジャイル開発をはじめてしばらくたったので基本からおさらいしてみた - TOWN株式会社 2022.6

• アジャイルに対する6つの誤解 - エムティーアイ エンジニアリングブログ 2022.6

     1.「計画を立てない」
     2.「要求変更は自由である」
     3.「ドキュメントはいらない」
     4.「プロジェクトマネジメントはいらない」
     5.「スクラムマスターはいらない」
     6.「アジャイル＝ソフトウェア開発方法論と捉え、IT部門が開発を考えるべき」

• ユーザー要望で要件が増えてく〜アジャイル開発での落とし穴〜 | フューチャー技術ブログ 2022.6

• 富士通が｢巨額をかけた残念なシステム作り｣から一線を引けるようになったワケ 2021.8

• 「アジャイルがダメだと思う7つの理由」から始まったアジャイル論争の現時点のまとめ 2013.4.2
  • アジャイルがダメだと思う7つの理由 - arclamp 2013.3

    1.全体スケジュールにコミットできない
    2.アーキテクチャ上の無駄が生じる
    3.コーチって何だよ
    4.変化ヲ抱擁スルために固定化している
    5.実証主義的な説明に過ぎない
    6.手段が目的になっている
    7.アジリティはアジャイルだけのものではない 

• ドラクエXマネージャが語る大規模アジャイル開発の極意 2012.8.29

• こんなプログラマはアジャイル出来ますって言ったらアカンやろ 2012.8.10

• 一括請負という契約形態のままアジャイル化するのは危ない 2012.6.12

• プロジェクトという形態は下火になり、プロダクト開発が台頭している。IPAの調査から 2012.6.14

• 海外でなぜアジャイル開発が普及しているのか？ IPAが分析と提言 2012.6.13
  • 米国では、ソフトウェアに対する投資が「自社開発（内製）」「パッケージソフト」で約3分の2を占めており、IT技術者の7割以上がユーザー企業に属しているという特徴が見られました。つまり他国に比べて同一組織内でソフトウェア開発を行うことが多く、契約を交わす必要がないため、ソフトウェアの変更に対応しやすいと考えられます。
  • デンマークでは政府が発注するソフトウェア開発をアジャイル開発で行うことが推奨されており、できるだけ小さく始め、柔軟な計画変更ができるといった契約になっているそうです。

• 炎上プロジェクトの責任はプロマネが９割 2014.1.26
  • ウォーターフォールとアジャイルの比較

• Agile in 30mins 2010.10.23
• 日経ITProの記事にケチつけておく 2010.8.23

• アジャイルはウォーターフォールよりも難しい 2010.8.20

• 現代のAgile開発が抱える課題 2010.8.9
  • 【1】Agile開発はプロジェクト管理が弱い
  • 【2】Agile開発はスケールアップが難しい
  • 【3】Agile開発はアーキテクチャや品質の作り込みの観点が弱い
  • 【4】Agile開発は分散開発まで考慮されていない

• Hudson を使ったアジャイルな開発入門

• アジャイルって受託開発との相性が最悪な気がする 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
  • 大規模プロジェクトでアジャイル開発を選択できない最大の理由は、機能分割するモデリング力が足りないからではないか、と推測している。
  • イテレーション毎にリリースしていくには、膨大で複雑な業務を、イテレーションが定める期間内かつリリースできる単位に機能分割して仕様へ落とさなければならない。

• アジャイルの衰退と凋落
• ソフトウェアは育てる時代へ 2008.9.6
• 『アジャイルプラクティス』はスゴ本
• いいアジャイルと悪いアジャイル
• Agileで始める実践アジャイル開発

• 大企業を変革せよ！「すごいリーダー」不在のアジャイルチャレンジ - Speaker Deck 20??

スクラム†

• 「終わらなかったから次のスプリントにまわそう」なんてありえない – 旅と子育てとアジャイルコーチのブログ「世界」 2023.6

• 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」とか言うお前らに告ぐ 2023.5

• スラクムを電車にたとえて説明してみた - arclamp 2023.3

• スクラム開発でベロシティが約3倍になった話 | Offers Tech Blog 2023.3

• アジャイルとスクラム何が違うの？ | DevelopersIO 2023.3
  • アジャイル = 原理原則・概念・マインドセット
  • スクラム = 方法論・開発手法

• それって本当に「スクラム」ですか？ - Goodpatch Tech Blog 2022.12

• 開発組織にはじめてのスクラムを導入する - Mirrativ Tech Blog 2022.12

• ゾンビスクラムにならないための6つの問い - Alternative Architecture DOJO 2022.12
  • 1. ステークホルダーと協調して価値あるプロダクト作りはできていますか
  • 2. 動くプロダクトや価値あるインクリメントはありますか
  • 3. ゴールは適切に設定できていますか
  • 4. スクラムイベントは機械的になっていませんか

       スプリント: 他のイベントの実施するための期間の決められたタイムボックス
       スプリントプランニング: スプリントゴールを決め、達成にスプリントバックログを計画する
       デイリースクラム: スプリントゴールへの進捗状況を検査する
       スプリントレビュー: ステークホルダーからプロダクトのフィードバックを収集する
       スプリントレトロスペクティブ: スプリントのふりかえりを行う

  • 5. 継続的に改善ができていますか
  • 6. チームは自律的に行動し、プロダクトに対する重要な決定権をもっていますか（自己組織化できているか）

• 新米スクラムマスターの思考メモ（その２　Retrospective編） | 豆蔵デベロッパーサイト 2022.12
  • Retrospectiveがスクラムイベントの中では最も取り組みやすい

• スクラムチームの成果を最大化させた7つの改善 ~ 新米リーダーの挑戦 ~ 2022.12

  1. プロダクトバックログアイテムの改善
  2. 完成の定義の改善
  3. 開発時間の改善
  4. Sprint Reviewの改善
  5. スクラムイベントの運用改善
  6. 顧客理解の改善
  7. 改善サイクルの改善

• 私はスクラムを解っていなかった - LIVESENSE ENGINEER BLOG 2022.12

• スクラムチームの開発者は複数チームを兼務してもよいですか？ | Ryuzee.com 2022.11

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

• SSO（スクラム知らないおじさん）がスクラムチームにやって来た - ぐるなびをちょっと良くするエンジニアブログ 2022.10

• スクラム未経験者が約1年スクラムを経験した話について - nextbeat-engineering - Medium 2022.8

• それなりに長いことスクラム開発を続けて得た知見とこれから。 2022.8

• スクラムの各種イベントに対して懐疑的だったが、チームでの改善を繰り返すうちに意義を感じるようになった話 - commmune Engineer Blog 2022.8

• スクラムでプロジェクトを始める前にお客様に説明しておきたいスクラムのエッセンス | DevelopersIO 2022.8
  • １．アジャイル≠コスト削減
  • ２．タイムボックスの重要性
  • ３．スクラムは鏡
    • 「スクラムをやればうまくいくのではなく、スクラムはいかにチームが『出来ていないか』を見せつけられる鏡だ」
  • ４．プロジェクト開始当初など、ベロシティが上がらない時期もある
  • ５．スプリントゴール達成率は50%が健全
    • 「スクラムチームは作業見積もりにバッファを持たない」
    • スプリントゴールの達成率が50%ということは、より高いゴールのために実験とチャレンジを継続しているということの現れであり、これはスクラムが健全に機能していることを表している

• 【スクラム導入】経験者1人(自分)のみのチームにスクラムを導入した話 - Qiita 2022.8

• スクラム開発のために絶対理解しておくべきこと - YouTube 2022.7

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

• スクラム開発ってシンプルだよね、と思っていたら５年間で８つのアンチパターンを踏み抜いていた話 - TOWN株式会社 2022.7

• スクラム開発のメリット 〜スクラム初心者が経験して感じたこと〜 - Safie Engineers' Blog! 2022.4

• チームに初めてデザインスプリントを導入して体感したこと - LIFULL Creators Blog 2022.4

• スクラムにおける朝会の目的は進捗共有ではないよという話 - Qiita 2021.5

• Scrumの公開資料 2012.6.10

• スクラムガイド（日本語版） 2020

スクラムの基本†

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

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

最新の50件