『アジャイルイントロダクション : Agile 開発の光と影』 で説明される、アジャイルの原則

from アジャイルイントロダクション : Agile 開発の光と影

アジャイルの信条の価値基準に従うもの

「アジャイル宣言の背後にある原則」 は原則とは言えない

組織 (プロジェクトマネジメント、スケジューリング、チーム構成に影響)

1. 顧客を中心に考える

目的は、顧客に最良の投資利益率 (ROI) をもたらすこと

2. 自己組織化チームにする

メンタリングとコーチングはアジャイルのマネジャーの重要な役割

経験豊富な結束の強いチームは例外的に管理者がいなくても機能しうるが、ほとんどのチームには管理者が必要

伝統的な管理者の役割の一部はチームメンバーに任せられる (次のイテレーションのタスクの選択など)

管理者は、チームメンバーの自主性を促し、チームを自己組織化に導いていくようにすべき

3. 継続可能なペースで仕事をする

エドワード・ヨードン (Ed Yourdon) によるデスマーチの否定

トム・デマルコ (Tom DeMarco) とティモシー・リスター (Timothy Lister) による 『PeopleWare』 での主張

プログラマに敬意を払うことと、良い作業環境を提供すること

2 つの流派 : 真にプログラマの尊厳を取り戻す vs 伝統的な産業における生産工学に基づくムダの排除

4. 最小限のソフトウェアを開発する

1. 最小限の機能を開発

2. 要求されたプロダクトだけを開発

ソフトウェア工学では拡張可能性と再利用可能性が重要だが、アジャイルではそうではない

そうなんかな？？

3. コードとテストのみを開発

アジャイルは文書に価値を置かない、みたいな主張だが、必ずしもそうではないと思う

5. 変化を許容する

歓迎するプロジェクトと受け入れるプロジェクトがある

スクラムはスプリント中の変更を制限 (本書では閉じられた窓のルール (closed window rule) と呼んでいる)

技術

6. 反復的に開発する

1. イテレーションごとに機能を開発

反復開発は 1975 年の 「Iterative enhancement: A practical technique for software development」 のころからソフトウェア工学の論文で推奨されている

2. イテレーションの間は要件を固定

7. テストを重要なリソースとして扱う

1. 全てのテストに通るまで新しい機能には着手しない

2. テストファーストでやる

8. シナリオを使って要求を表現する

ユースケースやユーザーストーリーと呼ばれるものを含む概念