Zenn
Closed3

アジャイル開発に関する忘備録

#
アジャイル
jimiijimii

共有される価値観

一部抜粋

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

https://agilemanifesto.org/iso/ja/manifesto.html

共有される原則(マニフェスト)

一部抜粋

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供する。
要求の変更は歓迎し変化を味方につけ、競争力を引き上げる。
動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースする。
ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働く。
意欲に満ちた人々を集めてプロジェクトを構成し信頼する。
効率的・効果的に情報を伝えるためにフェイス・トゥ・フェイスで話を。
動くソフトウェアこそが進捗の最も重要な尺度。
アジャイル･プロセスは持続可能な開発を促進する。
一定ペースを継続的に維持できるようにしなければならない。
技術的卓越性と優れた設計に対する不断の注意が機敏さを高める。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出される。
チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整する。

https://agilemanifesto.org/iso/ja/principles.html

jimiijimii

スクラム

概要:

  • 最大のビジネス価値を最短で生み出すアジャイルなプロセス
  • ソフトウェア開発における反復的なアプローチ。複数の小規模な反覆工程(スプリント)を使用
  • 各スプリント(2~4週間)で作られるのは、正しく動作するソフトウェア

プロセス:

  1. バックログリファインメントミーティング
    • 次のスプリント計画ミーティングに向けてプロダクトバックログを準備する
  2. スプリント計画ミーティング
    • プロダクトバックログのどのアイテムを含めるか決定する
    • スプリントの実現に必要なタスクを定義する
  3. デイリースクラムミーティング
    • スプリント期間中毎日行われる短い（通常は15分以内）チームミーティング
    • 各メンバーが前日の進捗、今日の予定、進行中の作業に関する障害点を共有する
  4. スクラムの実行
    • スプリントバックログのタスクをすべて実行する
  5. スプリントレビューミーティング
    • 各スプリントの最後に動作する製品のデモを利害関係者で行い、プロダクトバックログの新しいアイテムを特定する
    • DevOpsでは本番環境に近い環境でデモを実施することが求められる
  6. スプリントレトロスペクティブミーティング
    • 行動や成果について振り返り、将来のスプリントに向けた教訓を得る
  7. バックログリファインメントミーティング
    • 次のスプリント計画ミーテイングに向けてバックログを準備する

役割:

  • プロダクトオーナー
    • 全体的な結果に責任を追う
    • プロダクトバックログの唯一の責任者
    • プロダクトバックログの優先樹に付けを常に実施する
  • スクラムマスター
    • プロセス促進、適切なプラクティスを推進する
  • 開発チーム
    • 自立型組織で3名から9名程度のチーム
    • 職能横断型(ビジネスアナリスト、アーキテクト、プログラマー、セキュリティ、など)
jimiijimii

ユーザーストーリー

  • 新たな能力を求める人物(ユーザー、顧客など)の視点から、機能を完結に説明する。

  • 一般的なテンプレートは以下

    <ユーザーの種類>として、<機能や性能>を必要としている、なぜなら<ビジネス価値>を実現するためだ

準備完了の定義: Definition of Ready(DOR): INVEST

  • PBIが満たすべき条件。これによりチームは作業を開始できる
    • Independent(独立している): PBIは自己完結型、別のPBIとの依存関係が内在すべきではない
    • Negotiable(交渉可能である): PBIは、イテレーションの一部となるまではいつでも変更や書き換えが可能である
    • Valuable(価値を提供する): PBIは利害関係者に価値を提供しなくてはならない
    • Estimable(見積もり可能である): PBIのサイズを常に見積もることができなくてはならない
    • Small(小さい): PBIは大きすぎてはいけない。ある程度の確実性をもって計画/タスクの和知宛/優先順位付けができなくなるため
    • Testable(テスト可能である): PBIとそれに関する記述は、テスト開発が可能になる程度の情報を提供しなくてはならない

完了の定義: Definition of Done(DOD)

  • DevOpsにおける「完了」の定義。
  • 出荷できることが、本番に近い環境で実証された状態 ※本番環境に適用されている必要は無い
このスクラップは19日前にクローズされました