アジャイル検定に向けて

会社で導入されたアジャイル開発

運用保守メインの部署から最新技術を使える部署に異動になり、開発もアジャイルで行っている。
先輩方からの説明でなんとなくアジャイル開発についてわかったつもりだが、知識の確認としてアジャイル検定を受けてみることにした。

試験範囲

公式に発表されている試験内容は以下の通り。
公式テキストや調査した内容から概要をその下に記載する。

アジャイル開発に対する基礎知識

• アジャイル・マニフェスト
  １．プロセスやツールよりも個人と対話を
  ２．包括的なドキュメントよりも動くソフトウェアを、
  ３．契約交渉よりも顧客との協調を、
  ４．計画に従うことよりも変化への対応
• アジャイル原則
  １．顧客満足を最優先し、
  価値のあるソフトウェアを早く継続的に提供します。

２．要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。

３．動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。

４．ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。

５．意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。

６．情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。

７．動くソフトウェアこそが進捗の最も重要な尺度です。

８．アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。

９．技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。

１０．シンプルさ（ムダなく作れる量を最大限にすること）が本質です。

１１．最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。

１２．チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。

開発チームの運営

• コミュニケーション
  チームのコミュニケーション：
  フェイストゥフェイスでの打ち合わせが望ましい＝デジタルな情報（文字や言葉）アナログな情報（しぐさや表情）が読み取れる
  チャットツールなどを使うのが悪いわけではないが、伝わる情報量は少ない。
  ユーザとのコミュニケーション：
  チームだけでなくユーザーや関係者とのかかわりも密に。
  常に支援やフィードバックをいただいたり、よりよい開発のためにはユーザとの関係も重要。
  話し方だけでなくデータを提示するなどの伝え方にも注意。

• 自律性と協調
  自立したチーム＝自己組織的なチーム
  チーム員全員が積極的に開発に取り組み、自発的に最良の行動をすることができる。
  自らの作業部分については説明責任を持つ。

協調＝役割・仕事・プロセスのつなぎ目での行動の仕方
チームメンバーと協力し、自発的に最良の行動をとる。

• ルール
  チームのルールをチーム員が自ら制定すること。
  指示されたルールではなく自らが作ったルールを順守する。
  ただし、新たなルールの追加や不要なルールの削除やそのための話し合いは順次行うこと。

• 振り返り
  振り返り（レトロスペクティブ）はチームの成長のため日々の業務の中でチームの改善点を話し合い、対応策を決める。
  このとき、「がんばる」や「意識する」など漠然とした目標ではなく誰が見ても実績を図れる目標とすること。
  また、個人ではなくチームで取り組める目標とすること。
  振り返りの場づくり（会議）→課題の優先順位決定→行動目標決定のステップで行う。
  KPTなどの手法が用いられる。

アジャイル開発プロジェクト管理

• 会議体
  イテレーション計画会議:
  そのイテレーションで行うストーリーを選択し、作業可能なレベル（タスク）に落とし込む。

スタンドアップミーティング：
日次のミーティング。
朝礼のように進捗報告を行う。
15分以内の短い時間が望ましく、課題や疑問が出てもここでは共有のみにとどめる。
（必要な場合は別途打合せを設ける）

イテレーションレビュー会議：
プロダクトオーナーにイテレーション内で実施した内容を報告し、レビューを行う。
デモなどを用意してそのイテレーションでリリースした成果物のレビューをしていただく。
イテレーション計画会議で決定したストーリーがどこまで実施できたかなど。

イテレーションの振り返り：
イテレーション内の実施内容についてチームで振り返る。
開発のプロセスやチームの規約などを定期的にKPTなどを使って次スプリントの改善に努める。
イテレーションとイテレーションの間に行う。

• ロール（役割）
  プロダクトオーナー：
  ストーリー（要件）を適切に管理し優先順位を決定する。
  プロダクト全体が価値あるものになるよう努める。

チームリーダー：
開発には関わらず、チームがうまく回るよう潤滑剤としての役割に徹する。
問い合わせの窓口やマネジメント対応など外部の妨害から開発チームを守る。
極論チームが回るためなら何でもする。

開発チーム：
実開発作業を行い、価値のある製品を作ることを目的とする。
お客様の要望に応えることが目的ではないので製品を作ることが不可能な場合もある。
（ここまでは作れますがこれは作れません。など）

• 反復
  アジャイル開発ではイテレーションという数週間程度の開発期間を繰り返す反復型の開発手法を行う。
  1つのイテレーションの中で設計→開発→テスト→リリースまでを一通り行い、イテレーションごとに動く製品がリリースされる。

• ドキュメント
  アジャイル開発ではドキュメントよりも動くソフトウェアに価値があるとされているが、
  ドキュメントが不要という意味ではない。
  運用や知見を残すために必要と思われるドキュメントはイテレーションの中で残していくべき。

• チーム編成
  特定の分野に特化した人材ではなく開発におけるすべての業務を担える人間を10人以下で構築するべき。
  1つのストーリーに対して1人（ペアプロの場合2人）が担当することになるので設計からリリースまですべて行える必要がある。
  また、人数が増えすぎると意思疎通が難しくなるためチームを分割する。

• 計画
  ストーリーの洗い出し：
  ストーリー（要件）を洗い出し、相対的な難易度によってストーリーポイント（タスクの見積もり）をチーム全員で割り振る。

プロジェクト全体計画：
おおまかに最終的な納期やイテレーション数・期間、どのイテレーションでどのストーリーを実施するかを決める。
※ただし、優先順位や実施内容は各イテレーション実施前に変更される可能性もある。

イテレーション計画：
そのイテレーションで行うストーリーを選択し、作業可能なレベル（タスク）に落とし込む。
どのストーリーを実施するかは開発チーム等の意見を踏まえたうえでプロダクトオーナーが決定。

• 見積り
  アジャイル開発においてはストーリーを基準にした見積もりを行う。
  これをストーリーポイントといい、人日や人時、金額などチーム全員が納得できる単位でストーリーの見積もりを行う。
  また、見積もりによって出されたストーリーポイントにはその要件に対する設計からテスト、ドキュメント作成などすべての作業が含まれる。

• ビジョン
  プロジェクトの方針、優先順位、規約、マイルストーンなど関係者全員の共通認識にしておく必要がある。
  初期作業（インセプション・スクラムにおけるスプリント0）でプロジェクト関係者全員で合議をとり、プロジェクトの間は常に確認できる場所に共有される。

• 品質
  1つのストーリーに対して見積もりやタスク割り振りを行うため、ストーリーの完了条件についてプロダクトオーナーと認識を合わせておく必要がある。
  イテレーション計画会議などで話し合いを行い、決定した完了条件を満たすように開発作業を行う。
  品質向上のためのプラクティスについてはペアプログラミング・リファクタリング・常時結合などがある。
  （次に記載）

アジャイル開発の技能

• ペアプログラミング
  1つの開発端末に対しドライバー（コーディング）とナビゲーター（指示）に分かれて一緒に作業を行う。
  作業スピードの向上や初心者の能力向上、スキルの共有などが見込める。
  二人での作業は神経を使うので、作業を行う時間を決めてから休憩をとりつつ行うのが望ましい。

• リファクタリング
  コード全体の挙動は変えずに内部構造のみを書き直すこと。
  アジャイルに限った技能ではないが、冗長なコードを関数にまとめるなど機能を保ったままきれいなコードに書き直すことで保守性の向上などが見込める。
  開発者としてのメリットのみでなく、利用者（ユーザー）の立場からしても障害対応や機能追加の期間短縮など間接的な恩恵を受けられる。

• 常時結合
  コーディング後すぐにビルドすることで品質を保つ
  1日1回程度のビルドが望ましい
  ビルドツールを使用した自動ビルドなども行う
  ※リリースやテストも自動化されていることをDevOpsという

• テスト駆動開発
  テストケース作成（レッド）→動きのみ実装（グリーン）→リファクタリングを繰り返し開発を行う

テストを開発前に作成するため、ある程度の経験値が必要となる

その他気になった用語

スコープ

作るシステム全体の中での開発対象のこと
すべて順番に作るウォーターフォール開発では無かった考え方
スプリントの中でスコープを調整する。

イテレーション

アジャイル開発における繰り返しの一回をイテレーションと呼ぶ
スプリントとの違いは？

ストーリー

アジャイル開発における要件

常時結合

コーディング後すぐにビルドできること
一日一回程度のビルドが望ましい
ビルドツールを使用した自動ビルドなども行う
DevOpsはさらにリリースやテストも自動化されていること

スタンドアップミーティング

毎日おこわなれる短時間の打合せ
その日のペアや実施内容、昨日の進捗や課題を共有

受験結果

合格！！
基本は公式テキストのみで合格できると思います。