【書評】アジャイルイントロダクション
アジャイルについて知りたかったので、近くの図書館で借りて読んでみました。
主に重要と思った部分の抜粋です。
「アジャイルイントロダクションのご紹介」こちら詳しくわかりやすかったです。
初期において要求を収集し、設計に入る前に暫定版として策定し、プロジェクトの中でフィードバックを受け、動的な要素として要求を扱うことこそが、健全な方法なのである。
ドキュメントよりも口頭のコミュニケーションが優れている
・書面上の言葉は誤解されやすい
3.2.2 事前の要求分析に対するアジャイルの批判
・変更に対する批判
アジャイルの視点では、顧客は自らが望んでいるものはわかっていない。顧客が思う通りに実施すると、非現実的なシステムとなるかもしれない。そして、いずれにせよ顧客の考えは変わるだろう。顧客を満たす唯一の方法は、システムの一部を構築し始め、顧客に見せ、フィードバックを集め、反復することだけである。
ジャック・リーヴスが指摘するには、他の工学領域における「設計」とは、ソフトウェア工学におけるプログラミング、つまり、ソースコードを書くことであり、他の工学領域における「生産」とは、ソフトウェア工学のビルドのプロセスのこととなる。
アジャイルの原則
-組織-
１.顧客を中心に考えよう
２.自己組織化チームにしよう
自己組織化とは、管理層が事前に有効な行動とはどんなものかを規定する代わりに、個人のやり取りから発生する行動を進化させていくことに責任を持つという意味なのだ
３継続可能なベースで仕事をしよう
アジャイル開発は、プログラマーに敬意を払うことと、良い作業環境を提供することの必要性を強調している
４最小限のソフトウェアの開発をしよう
4.１最小限の機能を開発しよう
4.２要求されたプロダクトだけを開発しよう
4.３コードとテストのみを開発しよう
５変化を許容しよう
-技術-
６反復的に開発しよう
アジャイルでは、理論よりもコードである。素早く、頻繁に提供することが重要だ。
6.１イテレーションごとに機能を開発しよう
スプリントが始まってしまうと、チームは計画されている機能を実装し、誰もスプリントが終わるまでは何も追加することができない。
6.２イテレーションの間は要件を固定しよう
７テストを重要なリソースとして扱おう
アジャイル開発はどんなプロジェクトにおいてもテストを中心的なリソースとみなす。リソースは回帰テストスイートを必要とし、回帰テストスイートはこれまで試されたテストのセットであ流。名前が示しているように、目的は「回帰」として知られる現象を防ぐことである。回帰とは過去に解決されたバグが再度現れることである
7.１全てのテストが通るまでは、新しい機能には着手しないようにしよう
7.２テストファーストでやろう
どんなにリファクタリングしたとしても、欠陥のあるアーキテクチャを修正することはできない。設計者の主要な責任は、アーキテクチャの骨格を提示する基礎的な抽象化を明確にすることである
7.5.1テスト駆動開発（TDD）
【TDDサイクル】
１素早くテストを追加
２全テストを実行し、新しいテストが失敗することを確認
３小さな変更を加える
４全テストを実行し、全てのテストが成功することを確認
５リファクタリングし、重複を除去する
８シナリオを使って要求を表現しよう
【リーンソフトウェア開発の規律】
１無駄をなくす
２知識を作り出す※プログラマーが挑戦して、検証して、
修正するプロセスを経て経験から学ぶことを促すものである
３決定をできるだけ遅らせる
４できるだけ早く提供する
５チームに権限を委譲する
６品質を作り込む
７全体を最適化する※「契約交渉よりも顧客との協調」
１１アジャイル開発の難点
ユーザーストーリーは、鍵となる中小と連想する作用（ドメインモデル）を定義し、マシンとドメインの性質を明確に分けることを目的としたもの
※ユーザーストーリーはアジャイル開発においてユーザーのシステム操作の
シナリオを定義したものであるが、これによって、抽象化されたマシンと、
それに対して具体的に存在するビジネスドメインモデルが明確に区別される。
双方のインターフェースとしての存在ともなり得るもの。これは、DDD
（ドメイン駆動設計） の考え方とも通じており、ドメインモデルを明確にし、
マシンの内部ロジックと分離することで、より「現実世界の業務に即した
システム設計」が可能になる。と、理解しました。🫡🫡🫡
テスト駆動開発の技術は広く実践されているわけではない。一方で、多くの企業はユーザストーリーを採用している。ユーザーストーリーで要求を置き換えることは、テストで仕様を置き換えることと同じであると、企業が自覚することを望んでいるだけかもしれない。
訳者あとがき
アジャイルソフトウェア開発宣言でも「プロセスやツールよりも個人と対話」を重視すべきと謳われている。
Meyer氏は、アジャイルにおいて難点なものとして「事前タスクの軽視」「ドキュメントの軽視」を挙げている。ただし全てのドキュメントを否定しているわけではない。例えば開発において重要なことをユーザーストーリーマッピングのワークショップで洗い出すことなどは重要だと考えている。アジャイルが否定する事前のタスクとは、上流工程と呼ばれる要件定義や設計と呼ばれる事前の作業を実施し、下流工程のエンジニアが顧客の思いや期待を想像することすらなく、設計書に基づいて、作業を実施する。※この状況に陥らないように事前タスク（上流工程）を否定する
Mike Beedle氏が「アジャイルとは、ソフトウェア開発における人間回帰なんだ」と言っていた。この言葉は、非常に納得でき、興味深いものである。つまり、開発者はロボットのように命令（設計）通りにコードを書くのが仕事なのではない。ユーザーの価値を考え、その価値を提供し、ユーザーを笑顔にするというのが、開発者の仕事なのであると私は解釈している。そして、少々論理的な説明ではなくなるが、そのように人間らしく働けるからこそ、目の前のソフトウェアの構築に注力でき、素晴らしいソフトウェアを作ることができるのだろう。
アジャイルとは、当たり前のことと当たり前に実施することだ。常識や慣例といったものに盲目的に従うのではなく、プロジェクトが成功するために当然するのが妥当なことを、適切に実施することである。盲目的に従わずに考えることこそが人間回帰であり、人間的に思考するエンジニアが利用するからこそアジャイルのプラクティスは機能するのである。
Discussion