著 : Bertrand Meyer

原著 : Agile! The Good, the Hype and the Ugly

Amazon : https://amzn.to/3LCWkRf

訳が日本語としておかしい部分がちょくちょくある

とか

本書の内容

アジャイルの考え方を紹介し、包括的な評価をする

アジャイルについて説明

ウォーターフォール型開発などの伝統的な計画に基づくソフトウェア工学の手法の概要を説明

アジャイルな考え方を検証 : アジャイルの原則、役割、プラクティス、成果物

代表的な手法 : スクラム、リーンソフトウェア開発、XP、クリスタル

組織がアジャイル開発を適用する際に気を付けるべきこと

最終的な評価

アジャイル開発は、単一の開発手法を示す言葉ではない

原則として適格なもの

良い方法論の原則は、抽象的であると同時に反証可能であること

抽象的 : 原則とプラクティスの違い

プラクティスは原則を実現する手助けとなるもの

反証可能 : 常識との違い

分別のある人がその原則に同意しないこともあることを意味する

誰もが同意するようなものは常識であり、興味を持たれない

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

いくつか不足がある

プラクティスが含まれていたり、常識が含まれていたり、規範的でなく主張があったりする

代わりにアジャイルの核となる 8 つの原則を使う

メンバーとオブザーバー (豚と鶏)

ハーラン・ミルズ (Harlan Mills) は、1971 年にチーフプログラマというコンセプトを開発

アジャイルの役割についての評価

最も面白いのは、管理者からプロダクトオーナーの役割を分離したこと

以下 2 つを分けるのは有用

日々のプロジェクトの方向付け

ビジネスのために何をすべきか定義し、それが実行されているかを確認すること

整合性と独立性のトレードオフ

1 人が両方を見る方が整合性を取れるが、2 人の方が独立性が高い

他の役割についても、統合するかどうかをトレードオフで検討できる

アジャイルに取り組む人たちは新しい考えを生み出している

Thrashing や Anarchy、No Estimates なども

アジャイル開発 (カンバンやリーンソフトウェア開発、XP、スクラム、クリスタルなど) は、規律やプラクティス、役割やアーティファクトといった構成要素の組合せ

『Software Estimation: Demystifying the Black Art』 (和訳 : ソフトウェア見積り 人月の暗黙知を解き明かす) で言われるように、コストをかけても開発時間の短縮は一定程度までしかできない

アジャイルではタイムボックスの考え方を適用している → 機能と時間のどちらかしか保証できない

実際のところ、顧客がそれを受け入れるのかという問題がある

優秀なチームは、1 年以上、絶えず予算内で適切な機能を定刻通り提供できる

プロとアマチュアの違い

組織をアジャイルに変遷させる中で、アジャイルチームに責任を負ってもらうようにするのがデリケートな問題

合理的には、ゴールを中間的なステップ (マイルストーン) に分割する

アジャイル開発の難点

事前タスクの軽視 (特に事前要求と事前設計)

要求の基本としてのユーザーストーリー

抽象化を捨てている

機能単位の開発と依存関係の無視

依存関係追跡ツールの拒絶

ガントチャートなど

従来の管理者 (マネジャー？) のタスクの拒絶

事前の一般化の拒絶

個別の役割としてのコーチ

テストファーストやリファクタリングは良い

テスト駆動開発のプロセスは真剣には取り組まれないし、そういった取り組みを用いると最新のテストに注目することにより視野を狭めうる、とのこと

いまいちわからん

ドキュメントの軽視

アジャイル開発の誇張

持続可能なペースで作業する

最小の機能を生産する

計画ゲーム、プランニングポーカー

コードの共有 (コードの共同所有)

アジャイル開発の利点・素晴らしい点

利点

リファクタリングの推奨

チームのコミュニケーションの重要性

障害や無駄を識別して取り除くプラクティス

素晴らしい点

短いイテレーション

タイムボックス化したイテレーション

ベロシティとタスクボード

プロダクトオーナーという概念

継続的インテグレーションと回帰テストスイート

機能の全てにテストを記述すること

動作するソフトウェアを納品すること

#アジャイル #トップエスイーシリーズ #書籍 #文献