呪い: 見積もりの3倍だけ常にかかってしまう
みなさん、進捗どうでしょう？最高ですか？そんなことないよね！なぜならあなた達は呪われている。事前の計画よりも、常に、3倍の期間が必要になる。常にだ！！この呪いは強力であり、解放されるのは難しい。我々はどうすればよいだろうか？ パーキンソンの呪いある資源に対する需要は、その資源が入手可能な量まで膨張する パーキンソンの法則 — Wikipedia ある仕事の作業量を見積もったとしよう。機能Aの追加に2週間程度必要そうだ、とする。順調にいけば、再来週には動き出し、価値が出せそうだ。ペースを作り、粛々と仕事を進めていこう。 ところが、現実的にはそんなに上手くはいかない。新しく導入するライブラリがうまく動かないとか、くだらないtypoに悩まされて半日失ったとか、既存コードの改修箇所が想像してたより多かったとか、何らかの別の仕事をやらなければいけなかったり、もしくは休暇が必要だったりとか。当初計画よ
ドキュメントを残さない
普段仕事をしてるとき、いろいろなことに気を使いながら仕事をしてると思う。たとえばissueには、その背景、やりたいことや期待する効果、制限事項、認識している副作用やリスクの情報等などを書くような運用ルールを作っているチームは多いらしい。しかし、私たちのチームではそういうルールはない。それでうまくいくんだっけっていう話をよく質問されるので、考えてみた。 コードの品質をカバーするためのコメント私たちは、常にわかりやすいコードを書けるとは限らない。解説として、コメントが役立つ場面はある。 ちょっと待ってよ「よし、Why notを書こう！」と言って上手く書けるのは、そうとうに経験を積んだ人だ。そして、経験を積んだ人は大体問題ない。悪いコードほどコメントが必要だが、良いコメントが書けるくらいならコードはもっと良くなってる。鶏と卵じゃん。 コメントについて議論する暇があったら、コードについて議論したほ
リファクタリングをいつ、どのようにやるか
コードから不吉なにおいがしてきたなーと思うことはよくあるだろう。リファクタリングの機運かもしれないし、YAGNI原則を思い出して踏ん張るときかもしれない。では、いつリファクタリングをやるべきか、どのようにコードを整理していくべきだろうか？ リファクタリングには方針が必要リファクタリングの目的は、コードの拡張性を高めることだ。ここではそういうことにしよう。Open-Closed原則に従うように、凝集度を高め、結合度を低くするようにやっていけばいい。つまり、何か既存機能を変更するときはたった1箇所だけの変更で済むとか、もしくは新しい機能を足すときには既存機能を触らないで済むとか、そういう状態であれば比較的マシなコードになりえるよねっていうことです。 では、あらゆる変更に対してOpen-Closedであることはできるのか？おそらくそれは難しい思う。なので僕らは、経験的に「どの辺に変更が入りそうで
休日にカンファレンスがあるときに、参加者はどうするか？
土日や祝日にフルタイムで技術カンファレンスがあるとして、例えば参加しますよね、そのときにどうするか考えようという提起です。 カンファレンスは疲れるセッションを黙って座って聴いてるだけでもそれなりに疲れるし、せっかく参加するなら登壇者の人を捕まえて話をしたり、他の参加者と議論したり、もしくはワークショップセッションに参加したりとかしますよね。聴いてるだけみたいな参加の仕方をしても「あとで資料だけみればいいや」程度の価値しかないから。なので、フルタイムで1日参加するとそれなりに疲労するわけです。楽しさとは別に。 土日2daysなカンファレンスの場合、前の週フルタイムで働き、土日に疲労し、次の週またフルタイムで働くとか、たぶん働きすぎなので、最低でも次の月曜とかは休みたくなるのが人間ってものだと思います。私はそうする。 平日カンファレンスの参加は休暇を使いますか？CROSS 2016に登壇したと
ソフトウェア開発で学んだが使わなかったもの
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
はてな社に修行に行ってきた話
「社会人インターン」と称して2週間はてなのMackerelチームで働いてきましたので、その感想をつらつらと書きます。 おしゃれ感を演出している青山オフィスビデオチャットをいい感じに使ってるはてなといえば本社は京都ですが、東京のど真ん中、青山にもオフィスがあって、以前からビデオチャットでいい感じに中継したり会議したりしてる話は大昔からどこかに上がってた記憶がある。 Mackerel開発チームも東京、京都、その他にメンバーが散っていて、ビデオチャットは大活躍だった。朝会はそれぞれ zoom.us を立ち上げてみんなでビデオチャット。会議室で京都メンバーを交えた打ち合わせをするときは、備え付けのカメラとマイクで会議室の全景を写しつつ、大型モニターには京都の会議室の様子を写しているーというのが日常風景らしい。 こんなスペースでもビデオチャットできる用意がある先日 gitlab.com のトラブルで
アジャイル界隈研修の感想まとめ
自社会場で開催したりして、それなりの回数を参加したり聴講したりした経験があるので、なんとなくまとめていきます。 Jeff Patton, 認定スクラムプロダクトオーナー研修VOYAGE GROUP会場で4-5回くらいは開催してる。会場係としてお手伝いしつつ、内容をなんとなく聞いている。 印象に残ってるのは、プロダクトオーナーは開発者に対して、いろんな手段を使って実現したいもののことを伝えるのが仕事だということ。ドキュメントだけ書きゃいいってもんじゃないし、かと言って会話すりゃいいってわけじゃない。やり方はそれぞれの関係性によるが、とにかく、伝えるというのが大事らしいぞっていう。 研修の進め方も面白くて、毎回ちょっとずつ違いがあって、改善してるんだなーっていう印象がある。 手法の一例として彼はユーザストーリーマッピングというものを提唱していて、そのトレーニングもある。いろんな人に感想を聞くと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
