背景

• チームのタスク管理はAgile開発とAtlassianのツールが便利
• JiraとConfluenceは10年以上前からでファクタのアジャイル開発のツール
• そこでで改めてAgile開発とJiraとConfluenceについてまとめてみた

NOTE:

• 同じ用語で英語と日本語がMixしているので注意
• 例: Agile <=> アジャイル

Agile

Agileとは

• アジャイルはソフトウェア開発における方法論や価値観
• 柔軟性、迅速な応答、顧客との協力、変化に対する適応を重視している

Agileの4つの価値観

アジャイル宣言には以下の4つの価値観と12の原則が含まれている。

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

Agileの12の原則

1. 顧客満足を最優先に、価値のあるソフトウェアを早く継続的に提供する
2. 要求の変更を歓迎し、たとえ開発の後期であってもアジャイルプロセスを利用して顧客の競争力を高める
3. 動くソフトウェアを頻繁にリリースし、数週間から数ヶ月のスパンで、新しいリリースが好まれる
4. 開発者とビジネス側の人々は、プロジェクトを通して毎日一緒に働く
5. やる気に満ちた個人を中心にプロジェクトを構成し、必要な環境と支援を提供して仕事を成し遂げることを信頼する
6. チーム内の対話はできるだけ対面で行う
7. 動くソフトウェアは進捗の主な指標である
8. アジャイルプロセスは持続可能な開発を促進し、開発者、スポンサー、ユーザーは一定のペースを維持できるようにする
9. 優れた技術と設計への継続的な注目が俊敏性を高める
10. シンプルさ（不要な作業を最大限に減らすこと）が本質である
11. 最良のアーキテクチャ、要件、設計は自己組織化チームから生まれる
12. チームは定期的にどのようにより効率的になるかを振り返り、それに応じて自らの行動を調整する

フレームワーク

アジャイルの概念に基づいて、以下のような具体的なフレームワークがある。

• スクラム (Scrum)
• カンバン (Kanban)
• リーン (Lean)
• エクストリーム・プログラミング (XP)
• クリスタル (Crystal)

ウォーターフォールとアジャイル開発の違い

アジャイルとウォーターフォールの特徴と性質を比較すると次になる。

特徴:

性質:

Scrum

スクラムとは

• スクラムはアジャイルの原則に基づいたフレームワーク
• ソフトウェア開発チームが反復的かつ増分的に製品を開発するためのガイドラインを提供する

役割

• プロダクトオーナー
  • プロダクトのビジョンとバックログを管理
  • ステークホルダーとの調整、ユーザーストーリーの作成、スプリントゴールの定義など
• スクラムマスター
  • スクラムプロセスのガイドと障害の除去
  • チームのコーチング、障害の除去、スクラムイベントのファシリテーション
• 開発チーム
  • 実際に製品を開発するメンバー
  • 計画されたタスクの実施、デイリースクラムへの参加、スプリントレビューでの成果発表

スクラムに定義はされていないが、次のような役割もある。

• PdM: プロダクトマネージャー
• PM / PjM: プロジェクトマネージャー
• PO: プロダクトオーナー
• TL: テックリード
• EM: エンジニアリングマネージャー

イベント

スクラムには以下の定期的なイベントがある。

• スプリント
  • 通常2〜4週間の作業期間
• デイリースクラム
  • 毎日の短いミーティング
• スプリントレビュー
  • スプリント終了時のレビュー
• スプリントレトロスペクティブ
  • プロセス改善のための振り返り

アーティファクト

スクラムの重要な成果物には以下がある。

• プロダクトバックログ
  • 全ての要求と機能のリスト
• スプリントバックログ
  • スプリントで取り組むタスクのリスト
• インクリメント
  • 完成した製品の部分

Jira

Jiraとは

• Jiraはいわゆるアジャイル プロジェクト管理ツール
• 特にアジャイルチームのためのプロジェクト管理ツールとして使いやすいように作られている

Jiraの基本

Site

Atlassianアカウントで最初に作るのはSite。

• SiteとはAtlassianのSiteはクラウド製品をホスティングするためのドメインの事
• Jira、Confluence、Bitbucketなどを使用する際に、そのサブドメイン上で製品にアクセスできるようになる
• xxx.atlassian.netみたいな感じ
• いわゆるテナントのIDの事

Project

• Jiraでは、Siteを作成後に、Projectを作る
• Projectはチーム全体でそれらのタスクや課題を整理して追跡するためのコンテナーの事

プロジェクトにはTemplateとTypeがある

• Template: Kanban, Scrumなど
• Type: Team, Companyなど

Sprintの有効化

• スプリント機能を有効にするには、設定から有効化する必要がある
• project settings > featuresからsprintをONにする
• その際、backlogも有効化する必要がある

Issue

Issueとは

• プロジェクト内で追跡される作業項目
• タスク、バグ、ストーリーなど、さまざまな種類のイシューがある

Issueの種類

EpicとSprint、Versionの違い

• Epicは分母が作業であり、Sprintの分母は時間となり、Versionの分母はリリースとなる
• Epicは大規模な作業項目や機能なのに対し、Sprintは短期間の開発サイクルとなる

イベント

スプリントプランニングの流れ

スプリントプランニングとは、スプリント開始時の計画ミーティングの事。

1. イントロダクション
   • スクラムマスターがスプリントプランニングの目的と進行方法を説明し、全員が参加するよう促す
2. スプリントゴールの設定
   • プロダクトオーナーがプロダクトバックログの優先度の高いアイテムを提示し、スプリントゴールを提案する
   • チームが提案されたスプリントゴールを議論し、合意に達する
3. スプリントバックログの作成
   • チームがスプリントゴールを達成するために必要なバックログアイテムを選択する
   • 各バックログアイテムを詳細に分解し、必要なタスクを特定する
4. タスクの見積もりと割り当て
   • 各タスクの作業量を見積もり、適切な担当者を割り当てる
   • 見積もりには、ストーリーポイントや時間ベースの見積もりが使用される
5. チームのキャパシティの確認
   • チームの利用可能なリソースを確認し、スプリントバックログが現実的であることを確認する
   • 必要に応じてスプリントバックログの調整を行う
6. スプリントプランニングの締めくくり
   • スクラムマスターがスプリントバックログとスプリントゴールの確認を行い、全員の理解を一致させる
   • スプリントの開始を宣言し、次のスプリントに向けた作業を開始する

バックログリファインメント

• プロダクトバックログにあるアイテムを定期的に見直す事
  • アイテムは、ユーザーストーリー、バグ、タスクなどの事
• リファインメントとも

具体的には、次を行うする。

• 詳細化
  • DoD（Definition of Done）の決定
• 優先順位付け
• 見積もり
• 依存関係の確認
• 受け入れ基準の定義

Jiraでのスプリントの流れ

1. スプリント開始前にスプリントプランニングで作業タスクの明確化と見積りを行う
2. 日々、作業タスクを完了させていく
   • その作業中の際にサブタスクが生まれたら随時サブタスクを追加する
   • BoardでGroup by subtaskで表示できるので進捗が管理しやすいため
3. 毎朝デイリースクラム（朝会）でチーム一人ひとりの作業状況を共有する
4. スプリント最終日に成果物を説明するスプリントレビューを開催する
5. スプリントの最後にスプリントレトロスペクティブ（振り返り会）を開催する
6. スプリントとは別の時間軸でプロダクトバックログリファインメントを開催し、プロダクトバックログの棚卸・ブラッシュアップを行う

ロードマップの共有

• プロダクトオーナーのビジョン共有やチームとの長期的な目標を共有する事
• 目標とそのストーリーとリリースプランニングを通して合意形成を行う
• これはオレオレ定義のモノ

ロードマップの例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

Q1 2024:
- プロダクト目標: ユーザー登録プロセスの改善
  - エピック: 新ユーザー登録フローの導入
    - ストーリー1: 登録フォームのデザイン
    - ストーリー2: 登録データのバリデーション
    - ストーリー3: 登録完了ページの作成
  - リリース: Version 1.1
    - リリース日: 2024年3月31日

Q2 2024:
- プロダクト目標: 支払いシステムの導入
  - エピック: 支払いゲートウェイの統合
    - ストーリー1: 支払いフォームの作成
    - ストーリー2: 支払いAPIの統合
    - ストーリー3: 支払い確認ページの作成
  - リリース: Version 1.2
    - リリース日: 2024年6月30日

その他の機能

3つの主要機能

いわゆる、Timeline（ガントチャート）、Backlog（リスト）、ボード（カンバン）が主要な機能。

• Timeline
  • タイムラインはプロジェクトの計画や進行状況を視覚的に表示するツール
  • ガントチャート形式でタスクやプロジェクトの期間を表示する
  • 依存関係や進行状況を追跡が目的
• Backlog
  • バックログはプロジェクトに関連するすべての未処理の作業項目のリスト
  • 次の2つのbacklogに分けられる
    • プロダクトバックログ（全体のバックログ）
    • スプリントバックログ（特定のスプリントに取り組むアイテム）
• Board
  • Issueを視覚的に管理するためのツール
  • カンバンボードやスクラムボードなどの種類がある
  • 進行状況を示す列（例：To Do、In Progress、Done）で構成される
  • Swimlanesを使う事で更にまとめる事が可能

BoardはGropu byはAssignerごとにまとめたり、Subtaskを表示できるのでおすすめ。

レポート機能

客観的に進捗を把握するのにもこれらのツールが役立つ。

• バーンアップチャート
  • プロジェクトの進行状況とスコープの変化を視覚化するためのツール
  • 完了した作業量（y軸）と時間（x軸）を表示する
• スプリントのバーンダウンチャート
  • スプリント内の残り作業量を視覚化するツール
  • 完了する予定の作業量と実際の進行状況を比較し、スプリントの進行状況を追跡する
• ベロシティレポート
  • チームが過去のスプリントで完了した作業量（ストーリーポイントやタスク数）を表示するレポート
  • 将来のスプリント計画を立てる際の参考にするのが目的
• 累積フロー図
  • プロジェクトの進行状況を視覚化し、ワークフロー全体の安定性を評価するツール
  • 各ステータス（例：To Do、In Progress、Done）ごとに作業量を表示し、ボトルネックや遅延を特定するのが目的

見積もり

見積もりの前提

完璧な見積もり

• アジャイルの見積もりは、スプリント内での作業を予測するための目安
• 人月の神話ではないが、VOCAなソフトウェア開発において確実性の高い見積もりは不可能
• その前提があるがゆえに、Agileはスコープを小さくし漸進的な活動の手法を使っている
• 人月という言葉の「人」と「月」が交換不可能という事

不確実性のコーン

• そもそも、プロジェクトとは、「やったことがないことを、何が起こるのか分からないのに計画して、予定通りのモノ（コト）を期限までに作り上げる（終らせる）こと」
• プロジェクトの本質は、このやってみないと分からないという「不確実性」にある
• そして不確実性が高いほど、作業終了の見積もりにばらつきが生まれる

見積もり方法

ストーリーポイント

• ストーリーポイントは、作業の相対的な複雑さ、規模、および労力を評価するためのアジャイル手法
• プランニングポーカーで相対見積もりをする

見積もりの単位としては次のようなモノが使われる。

• Tシャツサイズ（S、M、L、XL）
• フィボナッチ数列（0, 1, 2, 3, 5, 8, 13, 21, …）

5-Why Technique

• 問題の根本原因を特定し、タスクの見積もりに役立つ情報を得るための手法
• いわゆるTOYOTA WAYの手法

PERT

• PERTはProgram Evaluation and Review Techniqueの略
• 3点見積もり（楽観値、最可能値、悲観値）を使用して見積もりの精度を高める手法

PERTは次の計算式で計算する。つまり、

$$ PERT = (O + 4M + P) / 6 $$

変数は次の意味:

• 楽観値（O）: 最短時間で完了する場合の見積もり
• 最可能値（M）: 最も可能性が高い場合の見積もり
• 悲観値（P）: 最長時間で完了する場合の見積もり

COCOMO

• COCOMOはConstructive Cost Modelの略
• プロジェクトの規模（KLOC）を基に、基本、中間、詳細モデルを使用してコストを見積る
• KLOCはKilo Lines of Codeの略で、ソースコード1000行の事

Confluence

Confluenceとは

• Atlassianが提供しているナレッジベースサービス

ドキュメントについて

• 従来のウォーターフォール型開発と比べてアジャイル開発におけるドキュメントは軽い
• 包括的なドキュメントはアジャイル開発では二次的なモノとみなされる
• ただし、設計についてある程度残すのは引き継ぎも簡易化するので大切
• また、データベース定義書はExcelの方が使いやすいので、適材適所で使分ける

ページのタイトル

ページタイトルは次のルールに従う。

• Confluenceの全てのページに、参照用に番号とIDを振る
• フォーマットは以下になる
  • フォーマット：[PageNo ContentId] PageTitle
  • PageNo
    • ページ構造の順番
    • フォーマット例: 1.1
  • ContentId
    • ページ内のコンテンツのID
    • 例えば、Use Caseなど
      • Use Caseのフォーマット例: UC1.1.4
    • これはオプショナルなので、必要に応じてつける
  • PageTitle
    • ページのタイトル
• 例
  • [1] 目的
  • [1.2] xxx APIの機能
  • [2.4 UC3.5~UC3.6, UC3.12, UC4.22] XXXのユースケース

基本的な書き方

次のルールに従う。

• です・ます調ではなく、である調にする
• テクニカルライティングのように結論を簡潔に述べる
• SD（Software Development）の設計ははUML2.1に準拠する
  • 例
    • アクターの定義
    • ユースケースでユーザーの利用シーンをを定義
    • シーケンス
    • クラス図
• プロトコルについてはRFCに寄せる
• 外注する所はRFPを書く

テンプレート

次は一般的な例における、アジャイル開発でのドキュメントの構造の例。

• BD情報
  • 事業計画
    • 目的・構想・背景・範囲
    • ロードマップ・スケジュール
    • バジェット
    • スコープ
    • ファイナンス
    • ユーザーストーリー
  • 事業評価
    • 顧客満足度
    • VoC
    • 投資対効果
  • 事業分析
    • 市場調査
    • マーケ
    • 競合調査
    • 提案
    • 課題
  • 営業計画
    • 集客
    • 体制
    • STP（Segmentation, Targeting, Positioning）
    • PMF
• SD情報
  • 体制
    • メンバーとロール
    • 使用しているサービス
    • リンク集
    • オンボーディング
    • 開発者共有情報
  • 要件
    • 非機能要件
      • 法的要件・セキュリティ・ネットワークアクセス
    • KOF・KBF
      • Knockout Factor
      • Key Buying Factor
    • テスト要件
  • 仕様
    • 用語
      • AP, FE, BE, BFF etc.
    • アクター
    • ユースケース
    • 運用
    • 鍵管理
  • 設計
    • アーキテクチャ
    • 業務フロー
    • API設計
    • モジュール設計
    • DB設計
    • データ設計
      • Masterデータ設計
      • Seedデータ設計
      • Mixture設計
    • インフラ設計
    • FE設計
    • AP設計
      • UI設計
  • 詳細設計

違い

機能要件・非機能要件の違い

分かりやすくは次の定義になる。

• 機能要件
  • システムが具体的に「何をするべきか」に関する要件
  • 例: ユーザー登録機能、商品検索機能、注文処理機能
• 非機能要件
  • システムの「どのように」動作するかに関する要件
  • 例: 応答時間、同時接続数、可用性、セキュリティ基準、拡張性など

要件・仕様・設計の違い

要件・仕様・設計の大まかな違いは次になる。

参考文献

• Jiraの活用事例　～スクラム初心者編～ #scrum - Qiita

• Jira 入門 - 初心者向け総合ガイド | Atlassian

• アジャイルソフトウェア開発宣言

• プロジェクトの本質とはなにか | 日経クロステック（xTECH）

• 第0回：人月の神話とはなんなのか？（解説編）｜本気で読み解く”人月の神話” - GiXo Ltd.

• Using Burn Up Charts for Transparent Project Management