アジャイルってますか？

読んだ。

復習がてら、面白かったところ、印象に残ったところを引用しよう。

アジャイルプラクティス達人プログラマに学ぶ現場開発者の習慣

作者: Venkat Subramaniam,Andy Hunt,木下史彦,角谷信太郎
出版社/メーカー: オーム社
発売日: 2007/12/22
メディア: 単行本（ソフトカバー）
購入: 35人クリック: 995回
この商品を含むブログ (291件) を見る

ヘラクレイトス曰く、「変化せぬものは変化のみ」。*1

万物は流転するって習ったよなあ。
情報業界の進歩の速さについていこうよっていう話の中で出てくる。

大野耐一著『トヨタ生産方式−−脱規模の経営をめざして』（ダイヤモンド社、1978）*2

これには興味がそそられた。
最新の開発手法の本に*3、この昭和の経営本が出てくるとは。

あとでわかったことだが、パッとが直接やり取りしていた担当者は、パットからの質問に対して、実際のユーザに問い合わせたり相談したりすることなく、個人的な判断で返答していたのだ。（中略）まだ完了まで先が長いのに、プロジェクトは早くもユーザのニーズを満たさないものになってしまった。*4

うーん。恐ろしい。自分も気をつけよう。

プロジェクトリーダーやマネージャの中には、設計とは、「コーダー」にそのまま引き継げば済むくらい詳細まで書かれているべきだと考えている人もいる。コーダーが決定を下すことなんてありえない。コーダーは設計をそのままコードに変換すればいい、と考えてるんだ。*5

残念ながら、日本の業務システム開発ってほとんどがそうなんじゃないか？

課題追跡システム
プロジェクトが進むにつれて、大量のフィードバックが蓄積される。訂正、提案、変更要求、機能拡張、バグ修正、などなど。把握しておくべき情報は膨大だ。行き当たりばったりの電子メールや殴り書きの付箋紙ではうまくいかない。こうした情報はすべて、課題追跡システムに記録すること。Webインターフェイスを使えるとなおよい。*6

Excel管理しているけど、ほうぼうに散逸して何が何やらわからなくなってしまったことがある。
どうするべきやら。
一度ちゃんとした課題追跡システムというのを使ってみたら分かるんだろうか。

テストを実行する際は必ず、失敗することを確認してから成功させること。*7

成功させちゃダメなコードを通しちゃうテストなんて、役に立たないどころの話じゃない。

「進捗はタイムシートで報告してくれないか。プロジェクトの計画を立てるのに必要になるんでね。ああ、それから、1週間の作業時間は必ず40時間にしておいてほしい。実際の作業時間じゃなくてね」*8

こんな進捗報告になんの意味があるの？
でも、気づくとそうなってしまっていることもある。実に恐ろしい。

「あー、それはですねえ、バグじゃないんです。お客様も他のみなさんと同じ勘違いをされてらっしゃいますねえ」*9

みんなが使えなかったら、それはバグと同じこと。

こんな話もある。高額を投じて工場の現場管理システムを開発したのに、誰にも利用されなかったらしい。システムを利用するためには、まずユーザ名とパスワードを使ってログインする必要があったのだが、工場の大半の労働者は読み書きができなかったのだ。誰もユーザから話を聞いたりフィードバックを受けたりしようとしなかったばかりに、完全に無駄なシステムを導入してしまったんだ。*10

日本では読み書きできない人ってほとんどいないとは思うけど、とはいえ外国人労働者は増えつつあるし、コンピュータリテラシーの格差は間違いなくある。