no strict

ちゃんとしない。面白いことからやる。

スクラムの原典:書評「リーンソフトウェア開発」

リーンソフトウエア開発?アジャイル開発を実践する22の方法?

リーンソフトウエア開発?アジャイル開発を実践する22の方法?

2003年に書かれたアジャイル開発の指南本。 伝統的なウォータフォール開発からアジャイル開発に移行する際の要諦が詰め込まれています。内容はどれも現在に通用するものであり、14年も前に書かれたとは思えません。本書に書かれていることの多くはその後スクラム開発として体系化されたと言えるでしょう。いわば、スクラム開発の「原典」のような本です。

トヨタかんばん方式がなぜ優れているのか、短いイテレーション(スプリント)はなぜ必要なのかなど、開発プロセスを変革する必要性が語られており納得感が得られます。

実践してみたいメソッドが満載。

  • 七つのムダ一つひとつについて議論する
    • 未完成の作業のムダ
    • 余分なプロセスのムダ
    • 余分な機能のムダ
    • タスク切り替えのムダ
    • 待ちのムダ
    • 移動のムダ
    • 欠陥のムダ

というチーム内アンケートはやってみたくなるし

ほとんどの改善プログラムでは、マネジャーが作業者に仕事のしかたを教える。ワークアウトでは、それが逆になっている。つまり、作業者がマネジャーに仕事のさせ方を教えるのだ。

というマネジメント改善プロセスの話も面白い。

以下のような部分も、とても頷けます。

  • スケジュールによって作業を押し進める(プッシュ)のではなく、顧客のニーズが作業を引っ張る(プルする)ことだ。
  • まずサブシステムのインターフェース(結合部分)のみを開発し、うまく機能したら中身を作る
  • チームマネジメントはボランティアに接するように人に接すれば良い
  • モチベーションをくじかせる、最も簡単な方法の一つは「ゼロ欠陥精神」だ
  • 変更承認プロセスを気にするのではなく、変更に強い設計プラクティスを気にかける
  • 開発チームの各メンバーに、チームの専門分野が「浅い」分野を書いてもらう

従来型の製造のプロセスがなぜ変革を迫られたのか、スクラム開発の本質とは何なのかを考えさせられる一冊でした。 手法だけでなく、手法が産まれた背景を理解することも大切ですね