昔、
アジャイル開発の方法について体系的に知りたかったので、Udemyのこのコースで勉強したことのメモがあったので、
エポケーで記事にしました。
(※メモなので軽く目を通す程度でお願いします.)
アジャイル開発とは
ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称
動画の中では「チームが品質保証する」とか言ってました。
アジャイルソフトウェア開発宣言
4つの価値
-
プロセスやツール<個々と対話
→「自己組織化」→コミュニケーション、チームワークが必須 -
包括的なドキュメント<動作するソフトウェア
-
契約交渉<顧客とのコラボレーション
→顧客と開発チームの継続的なコラボレーション -
計画に従順<変更への対応
12の原則
顧客満足度
1.早期かつ継続的の納品し顧客を満足させる
2.開発のあらゆる段階で変更を歓迎
3.動作中のソフトウェアを頻繁に納品
品質
4.動くソフトウェアが最も重要視される
5.技術的に優れ柔軟性と拡張性がある設計に注意
6.シンプルさ、無駄なく、作れる量を最大限に
チームワーク
7.ビジネス側と開発者は一緒に働く
8.意欲に満ちた人々でチームを構成し、信頼する
9.Face-to－Faceで話すのが一番効果的
プロジェクト管理
10.持続可能で一定の継続的に維持できるペースで
11.最良のアーキテクチャ、要求、設計のために、自己組織的なチーム作り
12.チームがもっと効率を高められるかを定期的に振り返り、方法を調整していく
Agileのフレームワーク
-
Scrum
プロダクトバックログの作成→スプリントプランニング→スプリント
→インクリメント→スプリントレトリスペクティブ→繰り返し -
XP(Extreme Programming)
コーディングスタンダード開発
ペアプログラミング→2人でやる
コードのリファクタリング→早めにコード修正
スクラム＋XPとかよく使うらしい。
-
Kanban
視覚化することで何を実行しているかを把握する
TODO DOING DONE -
Scrumban
Scrum + Kanban -
Hybrid
ウォーターフォールとスプリント
→全体的な仕様・要件は最初に決められている
その他いろいろ
-
Face to Faceで毎日スクラム会議に参加
→目標、優先順位、作業完了、取り組むべき作業、などを明確化して、共有 -
プロダクトオーナーとスクラムマスター
-
フィーチャーチーム：機能ごとのチーム
-
コンポーネントチーム：バックの部品ごとのチーム
-
スクラムオブスクラム：スクラム横断的にディスカッション
-
Adobe XD：プロダクトのプロトタイプの作成
-
Jira Software：プロダクト・バックログの管理, スケジュール管理など
-
Jira Confluence：プロダクト・ビジョン, チームメンバー情報の共有など
-
Visual Paradigm：アーキテクチャ設計図とか→画像作ってJiraのConfluenceに貼り付けたり
Scrumの手順
1.プロダクトビジョンの作成
WHO(誰が作る)：プロダクトオーナーがメイン(全員貢献できる)
FOR(誰のため)：内部の人間、技術者以外の人も
WHAT(何を作る)：最終目標と製品の価値
WHEN(いつ作る)：プロダクトバックログの前、更新時(必要に応じて)
手順
(ⅰ)製品目標の開発
製品の使用者
達成すること、目標
必要性
競合他社
差別化、特別性
(ⅱ)下書きの作成
大雑把すぎず、細かすぎず
(ⅲ)共有→フィードバック→修正
関係者、開発チーム、スクラムマスターが理解するまで繰り返す
(ⅳ)ファイナライズ
完成
2. プロダクト・バックログの作成
「プロダクトバックログとは、ロードマップと要件に基づいて開発チームが行う作業に優先順位を設定したリストです。プロダクトバックログの一番上に最重要項目が表示されるので、チームは最初に取り掛かることがわかります。」
(i)ユーザーストーリー(バックログアイテムの元になるもの)の作成
Desciptionの作成→ユーザー視点(+開発側視点)でどういう機能が必要かを考えて文章にする
A/C(Acceptance Criteira, 受入基準)の作成→各ストーリー毎に機能として何が達成されていなければならないかを決定する
(ⅱ)ストーリーポイント(必要コスト)、優先順位の決定
「プランニングポーカー」→ストーリーポイントを決める
「Tシャツのサイズ」→ストーリーポイントを決める
「ドット投票」→優先順位
などを使う。
スパイク(SPIKE)：「調べないとだめだよね」マーク。ポイントの見積もりに調査が必要なときとかに使う。
(ⅲ)プロダクト・バックログを整理する(→Jira Softwareのユーザーストーリーを使えばいい)
ユーザーストーリーを「エピック」にまとめる(要は、リリースの機能ごとにまとめる、バージョンを決めるということ)
直近のエピックで、取り組み順序、バックログアイテム、要件の説明、実装時間の評価、状態、担当者、などを決定
3. スプリント・プランニング
WHO：プロダクトオーナー(バックログアイテムのA/Cの詳細を明確にする)、スクラムマスター(ファシリテーター, MTGの進行まとめ役)、開発チーム(実際に作業する人なのでスプリントに必要な作業と労力を定義する)
WHAT：今後のスプリントのバックログを定義する(そのための会議)
WHEN：各スプリントの開始前(1～2時間)
バックログを整理→ユーザーストーリー(バックログアイテム)が適切か(サイズとか)を確認→進行度合い(1スプリントあたりどれくらいできるか)を評価→スプリント計画の議題を作成→MTG
MTG
スプリントの目標とビジョンを思い出す(原点回帰、完了すべき機能を説明)→ユーザーストーリー(バックログアイテム)を確認(新しい情報を確認)→チームの能力と速度の確認→スプリントバックログタスクを確認して役割分担
実現可能か、ストーリーポイントは適切か、を確認しながら、スプリントで達成することを決める
4. スプリント
Jira Softwareのボードを見ながら行う。
ポイント：サブタスクを作成する(現場で使われているテクニック)
「サブタスク」は開発者にわかる言葉で書かれたTODOみたいなもの。
ユーザーストーリーは開発者からすると何をすればいいか明確ではない。→サブタスクを作ってリンクさせることで開発者がわかりやすくなる。(例えば、サーバーの準備、HTMLの作成、etc)
5.インクリメント
「納入可能」：作業成果物は開発、統合、テスト、レビュー、文書化されていて、リリースの準備ができている
6. スプリント・レビュー
ソフトウェアを見せる
→実際に動くことを見せる
プロダクトバックログの修正
7. スプリント・レトロスペクティヴ(レトロ)
何がうまくいった？
何がうまくいかなかった？
何をどう変えたいか？
アクションアイテム(対策すべきこと)は？
②～⑦を繰り返す
感想
- 要は(？)「自己組織化」したチームって素敵、ということ。 →自律的に動くことのできる組織。変化に対応できる組織。
- そのための方法論が「Agile開発」という考え方。より具体的に落とし込んだものが「Scrum」とか「Kanban」とか。
- バックログアイテムはWBSみたいなもの。
- フレームワークにとらわれることなく、それぞれの組織とそれぞれの人にあった方法で取り組む。(開発を行うのは人間。人間中心。)
参考
- AgileについてまとまっているAttlasianのサイト https://www.atlassian.com/ja/agile
- スクラムの記事
- システム開発についてのYouTube動画