0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

アジャイル開発の基本

Last updated at Posted at 2024-05-12

はじめに

Udemyのコース「現役アジャイルコーチが教える!半日で理解できるアジャイル開発とスクラム」で学んだことを備忘録として記録します。

用語

  • ユーザーストーリー
    やりたいこと。バックログアイテムとも呼ばれる。
  • バックログ
    やることリスト。
  • ストーリーポイント
    ユーザーストーリーを見積もる方法。

アジャイル開発の手法

スクラム

現在最も有名な開発手法。

特徴

  • シンプルなフレームワークで人気
  • ソフト開発以外でも使われている

理論

  • 経験主義
    透明性→検査→適応
    スプリントごとにレビューを繰り返すのは検査
  • リーン思考
    無駄を減らすこと。
    無駄なく3本柱を回していく。

XP(エクストリームプログラミング)

特徴

  1. コミュニケーション
  2. シンプルさ
  3. フィードバック
  4. 勇気
  5. 尊重

プラクティス

  1. 全員同席
  2. チーム全体
    職能横断型チームを作る
    難しい場合は外部の協力を得る
  3. 情報豊富な作業空間
  4. 活気ある仕事
    残業ベースで働かない
  5. ペアプログラミング
    知識や経験を倍速で積んでいく
  6. ストーリー
    ユーザーの要求を小さくまとめ管理する
  7. 1週間サイクル
    短い期間で開発とリリースを繰り返す
  8. 四半期サイクル
    中長期的な計画も出来るだけ作る
  9. ゆとり
  10. 10分ビルド
    特定の短い時間内にビルドを終わらせる
  11. 常時結合
    継続的インテグレーション(CI)
  12. テストファーストプログラミング
  13. インクリメンタル設計
    少しずつ設計しましょう

応用プラクティス

  1. 実顧客の参加
    ユーザーを巻き込む
  2. インクリメンタル配置
    継続的デリバリ(CD)
  3. チームの継続
    チームとして成熟度を高めていく
  4. チームの縮小
    意欲ある経験者で別チームを立ち上げる
  5. 根本原因の分析
    表面的な問題にとらわれずに問題を深堀する
  6. コードの共有
  7. コードとテスト
  8. 単一のコードベース
  9. 日次配置
  10. 協議によるスコープ契約
  11. 利用分払い

リーンソフトウェア開発

原則

  1. 無駄をなくす
  2. 品質を作り込む
    欠陥をあとで見つけようとしない
  3. 知識を作り出す
  4. 決定を遅らせる
  5. 速く提供する
  6. 人を尊重する
  7. 全体を最適化する

かんばん

基本原則

  1. 現在、何をしているかを理解することから始める
    ホワイトボードに書き出す。かんばんにする。
  2. インクリメンタルに進化させ、変化を追求していく
  3. 現状のプロセス、役割、責務、職位を尊重する
  4. すべての地位でのリーダーシップを求める

コアプラクティス

  1. 可視化する
  2. WIPを制限する
  3. 流れを管理する
  4. 明確なポリシーを作る
  5. フィードバックループを実現する
  6. コラボレーティブに改善し、実験的に進化する

DevOps

開発と運用の効率的・効果的なコラボレーションをベースとしている

ツール

  • コード
    GitHubなど
  • ビルド
    JenkinsなどのCIツール
  • テスト
    自動テスト
  • パッケージ
    コンテナ技術、ライブラリ管理
  • リリース
    リリース自動化
  • コンフィグレーション
    インフラ自動構築、オーケストレーションツール
  • モニター
    パフォーマンスモニタリングツール

DevOpsの目標

  • デプロイの頻度
  • 変更のリードタイム
  • 変更失敗率
  • 平均修復時間

スクラム

  • スクラムガイドはわずか18ページ
  • 時代に応じて更新されていく

概要

複雑な問題に対応する適応型のソリューションを通じて、人々・チーム・組織が価値を生み出すための軽量級フレームワーク

開発を行う際は、シンプルかどうかを重視

流れ

  1. プロダクトバックログ
    やることリスト
  2. スプリントバックログ
    短い期間のやることリスト
  3. デイリースクラムミーティング

スクラムチーム

  • プロダクトオーナー
    やることややる順番を決める。
    最終的な決定責任がある。
  • 開発者
    開発を行う。
  • スクラムマスター
    スクラムの理論を全員に理解させる。

人数は10人以内が推奨。

プロダクトオーナー

責任
  1. ゴールを策定し、明示的に伝える
  2. プロダクトバックログアイテムを作成し、明確に伝える
  3. プロダクトバックログアイテムを並び替える
  4. プロダクトバックログに透明性があり、見える化され、理解されるようにする

開発者

責任
  • スプリントバックログを作成する
  • 完成の定義を忠実に守ることにより、品質を作り込む
  • スプリントゴールに向けて毎日計画を適応させる
  • 専門家としてお互いに責任を持つ

スクラムマスター

  • チームメンバーをコーチする
  • チームが集中できるよう支援する
  • 進捗を妨げる障害物を排除するように働きかける
  • すべてのスクラムイベントが開催され、ポジティブで生産的であり、タイムボックスの制限が守られるようにする

スクラムイベント

スプリント

- 固定の期間を指す
- 2週間が一般的。まず1週間を試すのが良い。

スプリントプランニング
  • スプリントの計画を立てる
  • スプリントバックログを決めること
  • スプリントゴールを決める
  • POはスプリントバックログを選ぶ
  • 見積(ストーリーポイント)、スコープを決める
  • 必要な場合、スプリントバックログをタスクに分割する
デイリースクラム
  • 朝礼、15分以内のイベント
  • スプリントゴールの進捗を確認し、計画を再計画
  • 問題や課題の対策も考え、意思決定する
  • 3つの質問を行う
    • 昨日やったこと
    • 今日やること
    • 課題や不安
スプリントレビュー
  • 成果を検査し、今後の適応を決定する
  • 成果のプレゼン+ディスカッションを行う
スプリントレトロスペクティブ
  • ふりかえり
  • 開発全体の検査
  • KPT
    • Keep
    • Problem
    • Try

スクラムの成果物

プロダクトバックログ
  • プロダクトレベルのやることリス
スプリントバックログ
  • スプリントレベルのやることリスト
  • 解像度は高い
  • スプリントゴールが含まれる
インクリメント
  • プロダクトゴールのための階段
  • スプリントレビューで検査される
    • ユニットテストが出来ているかなど

アジャイルになるために

成熟度モデル

  1. ゴールが見えない・不信感・仲が悪い
  2. みんなで頑張る雰囲気
  3. 仕事がなんとか回りだす
  4. 仕事を進め改善も出来る
  5. DEVアジャイル
  6. BIZアジャイル
  7. 全員リーダー
  8. アジャイルに「なる」

Not doing agile, but be agile.
アジャイルをするよりアジャイルになる

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?