Fight the Future

Java言語とJVM、そしてJavaエコシステム全般にまつわること

おまいらが好きな『アジャイルプラクティス』のプラクティスを挙げてみろ

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

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


まずおいらから。

  • 23「ありのままの進捗を計測する」
  • 39「アーキテクトもコードを書くべき」
  • 41「メンターになる」

23「ありのままの進捗を計測する」

「作業の進捗率は80パーセントです」
何日たっても何週間たっても、ずっと進捗率は80パーセントのまま。
割合なんて報告しても意味はない。

作業がどれだけ残っているかを測定するんだ。
最初に40時間かかると見積もった作業が、35時間経過した時点で、さらに30時間かかりそうだったら、その見通しの方が重要だ。
作業が完了したら、実際にかかった時間をありのままに記録しよう。
たぶん最初の見積もりより長くかかっているんじゃないだろうか。
でも、それでいいんだ。
次回のために、そのとおり記録しておくんだ。

しばらくの間、見積もりは過大評価と過小評価の間を行ったりきたりするかもしれないが、それもやがて収束する。

Joel on Softwareにもあったけど、このプラクティスはとても重要だよ。
世の中勘でスケジュールの線を引けばそのとおりに進むのが普通と思っているマネージャが多すぎる。
本当にプロジェクトをうまく進めるためには、パーセンテージじゃなくて残作業にかかる時間が必要だ。
自分の進捗が遅れていたって、そのこと自体は恥ずかしいことじゃない。
(もしも力量が足りずに遅れたのなら、進捗の遅れではなく自分の力のなさを認識すれば行動につながる)

39「アーキテクトもコードを書くべき」

机上の設計からよいアプリケーションは作れない。
設計は、試作され、テストされ、検証されるべきものだ。
設計は進化しなければならない。
実際に使える設計を生み出すことが設計者ないしアーキテクトの仕事だ。

上流工程って呼び方自体が好きじゃない。
設計だけで実装しないエンジニアなんて、やり逃げでしかない。
事前設計ですべて満たすことは不可能だ。どれだけ重厚なプロセスでも不可能だ。
みんなわかってるのに何でそんなプロセスなんだ?SEとPGって分け方はなんだ?
フィードバックこそ重要。

41「メンターになる」

「私のロウソクから、誰かかが火を採ったとしても、私のロウソクは暗くならない」

人から心のこもった感謝を伝えられるのは人間としての喜びの中で最上級のものだと思う。
結婚式で親が泣くのもそうじゃない?
日本人は感情をストレートに伝えないけど、「師匠!」って呼んだりするのは明らかに慕ってるからだよね。