ドキュメントを残さない
普段仕事をしてるとき、いろいろなことに気を使いながら仕事をしてると思う。たとえばissueには、その背景、やりたいことや期待する効果、制限事項、認識している副作用やリスクの情報等などを書くような運用ルールを作っているチームは多いらしい。しかし、私たちのチームではそういうルールはない。それでうまくいくんだっけっていう話をよく質問されるので、考えてみた。 コードの品質をカバーするためのコメント私たちは、常にわかりやすいコードを書けるとは限らない。解説として、コメントが役立つ場面はある。 ちょっと待ってよ「よし、Why notを書こう！」と言って上手く書けるのは、そうとうに経験を積んだ人だ。そして、経験を積んだ人は大体問題ない。悪いコードほどコメントが必要だが、良いコメントが書けるくらいならコードはもっと良くなってる。鶏と卵じゃん。 コメントについて議論する暇があったら、コードについて議論したほ
休日にカンファレンスがあるときに、参加者はどうするか？
土日や祝日にフルタイムで技術カンファレンスがあるとして、例えば参加しますよね、そのときにどうするか考えようという提起です。 カンファレンスは疲れるセッションを黙って座って聴いてるだけでもそれなりに疲れるし、せっかく参加するなら登壇者の人を捕まえて話をしたり、他の参加者と議論したり、もしくはワークショップセッションに参加したりとかしますよね。聴いてるだけみたいな参加の仕方をしても「あとで資料だけみればいいや」程度の価値しかないから。なので、フルタイムで1日参加するとそれなりに疲労するわけです。楽しさとは別に。 土日2daysなカンファレンスの場合、前の週フルタイムで働き、土日に疲労し、次の週またフルタイムで働くとか、たぶん働きすぎなので、最低でも次の月曜とかは休みたくなるのが人間ってものだと思います。私はそうする。 平日カンファレンスの参加は休暇を使いますか？CROSS 2016に登壇したと
ソフトウェア開発で学んだが使わなかったもの
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
