アジャイルソフトウェア開発技術者検定（アジャイル検定）Lv.2受験・対策記

怠（ナマケ）ニア

1度受験して落っこちたので、本腰入れて対策するために書いていきます
尚、以下記載する内容は個人の知識に基づくメモが多分に含まれます。
ついでに、Zennの使い心地も試してみます

怠（ナマケ）ニア

アジャイル検定Lv2の試験について

試験範囲

モデリング

オブジェクト指向設計：継承、インターフェース、ポリモーフィズム、疎結合、Dependency Injection

コーディング

コーディングルール：ツールによる確認(checkstyle)
ペアプログラミング
リーダビリティ(コードの読みやすさ)
テストコード(Mock、Testing frameworkなど)
静的解析ツール(SonarQube)
ドキュメンテーション

構成管理

チーム開発：SCM(ソースの変更管理システム)、分散型(git)、集中型(Subversion、CVS 等)
ブランチ戦略：ブランチとマージ、レビュー・受入(プルリクエスト)
コンテナ技術

テスト

TDD:Junit(モックを使ったテスト、テスト結果レポートの見方、網羅率C0,C1,C2)
品質管理のためのテスト(パフォーマンステスト、結合テスト、総合テスト・システムテスト)
ユーザー受入テスト、ブラックボックステスト、ホワイトボックステスト

常時結合

自動化の導入：何時動かして結果から何を読み取るか、自動化の導入効果、何を自動化するか(ビルド⇒テスト⇒デプロイ等)
何のため、誰のために、常時結合(CI)をおこなうのか

デザインパターン

デザインパターンを使うことのメリット
ロバート・C.マーチン「アジャイルソフトウェア開発の奥義」(アジャイルな設計、単一責務、Open/Closedの法則)、GoFのデザインパターン、DI(Dependency Injection)
オブジェクト指向開発の考え方(継承、カプセル化、ポリモーフィズムなど)
デザインパターンを使うことのメリット(各パターンの利用法、メリット)
システムアーキテクチャ設計(拡張性、保守性)
UML(Unified Modeling Language)

リファクタリング

マーティン・ファウラー「リファクタリング」(コードの不吉な匂い等)
オブジェクト指向設計原則(Principles Of Object Oriented Design)

チームのスキル

スプリント計画
自己組織化されたチーム：メンバーの行動規範(コミュニケーション、自立と協調)
レトロスペクティブ(振り返り)

試験形式

試験時間: 60分
試験形式: 多肢選択式 (四肢択一)40問
受験資格: アジャイルソフトウエア開発技術者検定試験Lv.1に合格していること
評価方法: 65％以上合格

怠（ナマケ）ニア

試験傾向

問題は一文の簡易な問題文から意味を選択させ知識を選ぶものは少なく、
全体を通し日常からありそうな場面・実例から
開発者としてどのような行動をとるべきか選択させるものが多い。
また、1つだけ正解を選ぶ問題は少なく、選択数を限定しない形で複数選択させる問題が多い。

従って、アジャイル開発のスキームの中で、チームメンバーとして、そして開発者としてどのような行動をとるべきか、知識を基にあるべき姿を答えられるようにする必要がある。

具体的には、23種類あるデザインパターンのそれぞれについて、どういった使い方をすべきで、どのような場面で有効な選択肢となり得るかや、チームメンバーとして、マージはどのタイミングで行うべきか、チームで取り組みを追加するときにどのようにチーム内で提案すべきか等。

怠（ナマケ）ニア

先人の皆様

怠（ナマケ）ニア

モデリング・コーディング・リファクタリング

対策すべき内容

オブジェクト指向におけるSOLIDの原則
クラスの粒度
- 疎結合は保つべきだが関係性の深いクラスはどこまで区切りどこまで統合するか
- 継承の使いどころ
可読性をどこまで重視すべきか（変数は多めに作るべきか？ソースコードはどこまで短さを求めればよいか？一時的な変数は必要か？ソースコードはむやみに減らせばいいのか？）
- 一時的な変数はないほうが良い。
- 三項演算子、1行if文の是非
リファクタリング時におけるメインのコードとテストコードの関係性
コメントは1行コメントを書くべきか最小限で良いか（コメントが多すぎると消臭剤になり得る）
テストの前処理が大きい場合に考えられる内容
テストコードは本体のコードのカバレッジ100%を目指すべきか
どのタイミングでリファクタリングを行えば良いか
リファクタリングを実施すべき範囲、方法
変数の命名の在り方
静的解析ツールはいつ入れるべき？
IDEのフォーマッターはコーディングルールを決めるために役に立つか？
コーディングルールを決めるタイミング

怠（ナマケ）ニア

構成管理

対策すべき内容

アジャイル開発においてどこまでが管理すべき範囲になるのか（ソースコード？ドキュメント？テストレポート？）
物理的な端末なども構成管理に入り得るのか
そもそもの構成管理の意味
構成管理の方法は一度決めたら簡単に変えたらいけないの？

怠（ナマケ）ニア

テスト

対策すべき内容

通常の開発時、各テストごとにどこまでの網羅率を目指せばいいのか（クラス、カバレッジ、命令網羅）
単体・結合・システム・受け入れの各段階において重視すべきテスト観点（パフォーマンス？要件？）
- アジャイルテストの4象限
- ウォーターフォールのようなフェーズに対応したテストを意識するのではなく、4象限の中でどのような観点を誰がいつまでにテストすべきかというところを気にする
- 各段階においてもテストについて役割分担はするが、すべてのテストに対してチーム全体で責任を持つ
- 常時結合の観点からはQ1のテストは必ず自動で行い、Q2のテストは場合によって自動で実施する

怠（ナマケ）ニア

常時結合

対策すべき内容

CI/CDが落ちたときのチームメンバーとの協調の仕方
CI/CDの実行タイミング
すべてのテストをCI/CDで回さなければならないのか
マージのタイミングは？1日の業務が終わったらやるようにする？
セントラルリポジトリ = リモートリポジトリ？
コンフリクトを避けるためのチームメンバーとの協調の仕方

怠（ナマケ）ニア

デザインパターン

対策すべき内容

各デザインパターンの構成内容
各デザインパターンが使われる場面
各デザインパターンの構造とメリットの関係
主なもの:Factory, Command, Proxy, Composite, Builder, Facade

怠（ナマケ）ニア

チームのスキル

対策すべき内容

チーム内でのメンバーとの協調の仕方（単独で判断できる範囲とチームで決定すべき範囲）
- チームで取り入れるワークは誰が決定すべきか
- 一番最初の取り入れ方と、ワークは寸分違わず実施すべきか、導入を判断できる人
最終的にあるべきアジャイルのチーム像（自己組織化されたチーム）
設計段階でどこまでチーム内での協調を図るべきか（責任者が介在すべき範囲と開発者が決める範囲。チケット？エピック？）

怠（ナマケ）ニア

参考になりそうな書籍

アジャイル概論 (アジャイルソフトウェア開発技術シリーズ・応用編)

試験を運営するコンソーシアムの代表の方が著者の中に名を連ねており、これを買うのは悔しい気もするが、この試験における基礎的なアジャイルに対する考え方、言葉の定義等を読み取るには非常に有用。
特にスクラムからアジャイルに入るなど、一般化した言葉に慣れていない方（スプリントとイテレーションという言葉がつながらない等）は特に一読しておくことをおすすめ。

リーダブルコード

コーディングを嗜む者であれば一読すべき内容。可読性の高いコードを書くために必要な考え方が詰め込まれている。