アジャイルソフトウエア開発技術者検定試験

はじめに

• アジャイル開発についての知見を得るため、試験を受験した。
• 公式対策本にて学習を進めた。
  • 2018/09頃にKindleで購入しており、その頃から何となくアジャイル開発への興味はあった。
• 「アジャイルマニフェスト」に記載されている4つの価値がアジャイル開発の本質。
• 4つの価値を原則化した12の原則「アジャイル宣言の背後にある原則」別にアジャイル開発のトピックをまとめることで理解を深めていった。

試験受けてみて

• その作業は、誰(役割)が実施するのかを、しっかりと理解しておく。
• 誰(役割)の用語定義は、公式本ではアジャイルに統一されているが、スクラム用語であったり、他のフレームワークで用いられている用語で登場する。
  • 代表的なものがイテレーション ▶︎ スプリント、チームリーダー ▶︎ スクラムマスター 等々
• 公式本で用語がアジャイルに統一されているので、それであれば試験も合わせるべきとは思う。

まとめ

• アジャイルの考えを改めて理解する良い機会となった。継続して関連本を読み、Lv.2にもチャレンジしてみたい。
• アジャイル検定資格もってる人いるけど、(テスト)コード書かないとか。こんなことやってたら、実際の開発は回らないし、資格もってるだけで意味ないよって意見も出そうだとは思う。
• が、アジャイルは大いに目指すべき理想が書かれていて、その理想を実現するにはどうやっていくか本質を理解するのは、とても意義があることだと思う。特に経営層がアジャイルのやり方に目を向け、これに対して、理想を掲げて全員が目指す方向になれば、良い開発・職場に繋がって行くんじゃないかと思う。(こういう理想を語る経営者に憧れる。)
• 全部が全部実現できなくても、理想にむかって進んでいく、理想大いに語るってのは悪いことではないから、もっともっと広がってほしい。

以下、参考

Terms

• スクラムはアジャイル開発のフレームワークの一種である。スクラムで利用される用語がアジャイル用語として表現されている場合もあるため、以下まとめて記載する。
• アジャイル開発フレームワークとしては、Scrum, Hybrid, Scrumban, XP, Kanban等がある。

Agile	Scrum	Description
プロダクトオーナー		開発製品の最終責任者。原則一人。
チームリーダー	スクラムマスター	開発チームのプロセスを円滑に遂行できるよう支援する。
ストーリー	プロダクトバックログ	顧客の目線で実現したいこととその価値をシンプルに記述したもの。顧客の価値視点で記載することが重要。 Ex. ...を実現することで自社の売上を40％以上伸ばす
タスク	スプリントバックログ	ストーリーを実現する為に具体的に作業項目化したものであり、「開発者の言葉」で記載する。
ユーザーストーリー		Mike Cohnによって提唱されたユーザ要求をINVESTという簡単なルールで記述する方法。役割、機能、理由(価値)を完結に整理できる。
インセプション(初期作業)		アジャイル開発の開始時に行い、関係者全員で、プロジェクトの背景にあるビジョンを共有する。
イテレーション計画会議		プロダクトオーナー、チームリーダー、開発チーム参加。 前半は、次のイテレーションで実現すべき成果物となるストーリーの一覧を決定。 後半は、ストーリーについての詳細見積を実施。タスク分解・定義を行う前に、チーム全員で対象となるストーリーの実装イメージをすり合わせる。この作業は時間をかけてでも、しっかりと全員のイメージが合うまで議論し認識を合わせる。
イテレーションレビュー会議	スプリントレビュー
イテレーション振り返り	スプリントレトロスペクティブ	ヒトを責めたり、反省したりする場ではなく、コトを責める。チーム内で定期的に実施し、毎週日時を決めて行う。
スタンドアップミーティング	デイリースクラム	イテレーション進捗確認のため、毎朝実施するミーティング。チームリーダー、開発チームの参加。 技術的な課題や進捗の遅れなどの課題について議論したい場合、別で実施し、決められた時間(15分程度)で終わらせる。
常時結合		コードを作成した後すぐにビルドを行う。ビルドツールを利用して、ソフトウェアの配置を自動化すること。
DevOps		常時結合からさらに、ユニットテスト, 結合テスト, 受け入れテストを自動化し、本番環境に配置すること。
ベロシティ		イテレーションごとの生産性。そのイテレーションにおいて実現できた成果の総量。

アジャイルマニフェスト

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

引用元： 「アジャイルマニフェスト」

アジャイル宣言の背後にある原則

私たちは以下の原則に従う:

顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。

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

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

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

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

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

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

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

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

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

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

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

顧客満足と価値あるソフトウェア提供

• 開発期間を短くして、動作するソフトウェアをすぐに作り、顧客に確認してもらい、素早いフィードバックをもらう。このフィードバックにより、顧客の意図にあったシステムを構築し、認識相違がないようにできる。

ビジネスの変化に応じた要求変更

• とはいえ、システム全体の開発規模は、概算で始めに予測し予算化しておく。
• 計画よりも計画作り、立てた計画そのものよりも、計画を何度も作り直すことが大事。
• 何か問題が発生した場合は、スコープを変動させることで対処する。
• 計画作りの段階で挙げたストーリーをすべて完遂することが目的ではなく、ストーリーが持つ価値の実現が目的となる。目的が達成されるのであれば、計画時に立案したストーリーでも実施しないものが発生する場合がある。

動くソフトウェアを短い間隔でリリース

• ストーリーに対する実行可能な成果物を定義して、作成する。
• 全体計画時には、ストーリーについては詳細見積もりは実施しない。イテレーション計画時に詳細化する。これは、変化に柔軟に対応するため。

顧客と開発チームは一緒に働く

• 計画では、2レベルプランニングという方法が用いられる。リリースプラン(ユーザにリリースする計画)とイテレーションプラン(チームの作業計画)の2つをそれぞれ計画し、常に見直し、作り替えて運用していく。

チームメンバーがお互いを信頼する

• アジャイルチームの中に序列を作らない。また、意思決定は、多数決でなく全員一致。
• 大きなことを大きなチームでやるのではなく、小さなことをする小さなチームがいくつも集まり、コラボレーションして大きなものを作り上げる。

直接対話が情報を伝える最も効果的な方法

• 最良のコミュニケーションはFace to Face。
• 開発チームのメンバー数は、プロダクトオーナー、チームリーダーを除き、5〜9人くらいが良い。

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

• 開発期間を短くし、動作するソフトウェアを作成、それを顧客に確認してもらい、素早いフィードバックをもらう。このフィードバックにより、顧客の意図にあったシステムを構築する。
• ドキュメントを作成する必要がないという誤解が一部にあるが、アジャイルであっても必要なドキュメントは作成する。
  • イテレーション0(開発イテレーション開始前)に、アーキテクチャ設計のドキュメントを作成する。

開発ペースを継続維持することが開発を効率化する

• イテレーションは固定期間。実施予定のストーリーが終了しない場合でも、イテレーションの期間を延長しない。イテレーションの期間中にタスク完成の目処が経たない場合、タスクの分割や実現するレベルの調整について、プロダクトオーナーへ相談する。

分かり易い設計がソフトウェアの柔軟性を高める

• テストを始めに作成する。単体テストではなく、テスト項目は、ストーリーからシナリオを考える。
• テストコードを作成した時点では、テストコードを追加した人がソースコードも作成する。
• リファクタリングは機能追加、バグフィックス、コードレビュー等のタイミングで一度にまとめて実施ではなく、少しずつ実施する。

シンプルが本質

• 今必要なものだけを単純な設計で作成する。

自己組織的なチームは最良の成果を生み出す

• 誰がどのストーリを担当するかは、管理者が指示するのではなく、開発者が自身で自主的に決める。
• イテレーション期間内で起こる事象、問題、課題などは開発チームの中で解決する。
• イテレーションにおけるタスク進捗の把握は、アジャイルチーム全員が把握する。

定期的な振り返りがさらなるチーム作業の効率化を生む

• 振り返りのミーティングの手法としてKPT(Keep/Problem/Try)がある。
  • Keep: うまくいったこと、続けたほうが良いこと
  • Problem: 問題があった事象
  • Try: 次のスプリントで試してみたいこと、Problemで挙がった問題の解決策、Keepをさらに強化する改善策
• 振り返りはアジャイルチームが成長するためのプラクティスである。チーム内で定期的に実施し、一般的には、毎週日時を決めて実施するくらいが良い。
• 振り返りはデータ(数字)で見ること。数字データが不足している場合には、その議論は次回に持ち越し、データ収集を行う。

一応記念