GitHubのProjects機能を使ってタスク管理をしようとしている。そこで、Issueのラベルについても今一度整理しておこうと思った。で、ChatGPTに聞いた😂
真面目なことをやる時には真面目に役にたつな。
このチームが20%ルールを採用できないたった一つの理由について
Googleで有名な20%ルールは、エンジニアにとって垂涎の羨ましい制度だ（一時期なくなったという噂を聞いたが、今はどうなっているんだろう？）。憧れるよね。いいよね。わかる。僕もできることなら取り入れたいと思う。
でもダメです。ごめん。このチームではできません。しないんじゃなくて、できないです。多分、言えばわかってもらえると思う。
“このチームが20%ルールを採用できないたった一つの理由について” の続きを読むユニットテストを書き始めて得られた効果、困っていること
ここ数ヶ月ほど、ユニットテストを書くように努めている。と言うと、むしろ今まで書いていなかったのかとお叱りを受けそうだが、書いていなかった。今のプロジェクトは某社から引き継いだものだが、ユニットテストは書かれていなかった（ゼロではないが）。
例によって周囲に先達がいなかったので、自分で勉強して始めるしかなく、とにかくKent Beckのテスト駆動開発やらネット上の記事やらを読み漁りつつ、見よう見まねで始めたのだが、確かにユニットテストをすると、安心感がある。特に仕様の変更があった際、ユニットテストが異常検知してくれたケースもあった。
やってみてわかることもあるもんだ、と続けてみると、よいこともでてきたし、困ったこともでてきた。
“ユニットテストを書き始めて得られた効果、困っていること” の続きを読むバーンダウンチャートがバーンダウンするまでの半年間の苦闘の軌跡
見よう見まねで始めたアジャイル開発は、苦難の連続でした。最大でもせいぜい5人程度の少人数のチームだというのに、まったくまとまらず、チームは崩壊寸前（正直言って今もいつ壊れるかわからない）。
それでも、頑張って続けました。そして苦節半年、スプリントのバーンダウンチャートが、ようやくバーンダウンしたんです。感動です。そして、なんとベロシティも出せました。当たり前？いや、これが全然できなかったんです。本当につらかった。
本記事は、とある開発チームが紆余曲折を経てそれなりのチャートを描くようになるまでの、血と汗と涙の軌跡です。
“バーンダウンチャートがバーンダウンするまでの半年間の苦闘の軌跡” の続きを読む探索的テストの試行
ギリギリの時間で開発していると、どうしてもテストが疎かになりがちであるけれど、だからといってバグが許容されるかというとそんなことはもちろんないわけで。しかし、実際のところバグはボロボロ出てくるもので、その時はやはり「テストしないといけませんね」という当たり前の結論になるのだが、そんなことはそもそもわかっていたことであって、それにも関わらずリリースに踏み切らねばならない状況だったことに問題の本質がある。そして今日も本質は放置されたままである。
とはいえ、短い時間でもどうにかできんものだろうか、ということで探索的テストについて調べた。
「何が起きるかわからないから…」そこをわかってほしいのだ
未来はいつでもわからない。だから、人は常に余裕をもったスケジュールを組むことが求められる。結果としてその余裕が無駄に終わったとしても、それを必要なことだと思えることが、大人になるための一歩だと思う。しかし、その余裕がどれくらい必要なのかは難しい問題だ。
“何が起きるかわからない”から余裕を見積もる。それは定性的には正しい。確定できない未来に対し、冗長性は必要だ。だが、どれだけ冗長する必要があるかは、その者の実力による。行き過ぎた慎重さは、思慮深さよりむしろ無知の証左に見える。