観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな？」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない？もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは

社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて

最近何人かからキャリアパスの相談を受けてて、話をしているうちに自分の考えが少し整理できた気がするので忘れる前にメモ。雑記。 ## サービスエンジニア 僕の今いる部署に求められてるエンジニアは、技術をコアにしたエンジニアじゃなくて、サービスをコアにしたエンジニアだと思ってる。図の左側。技術を突き詰めて「この技術で何ができるか」というよりも、サービスのことを考えて「このサービスのためにあの技術が使えないか」という感じ。 ## アプリ開発とサービス開発 Webアプリの開発経験が10年以上あります、って人よりも、新卒の2,3年目の人の方が頼りになったりして、どういうところなんだろうなぁ？って思ってたんだけど。アプリ開発スキル、と、サービス開発スキル、が別のスキルってことなのかもしれない。 サービスを開発するときは、アプリの機能を実装するだけじゃなくて、全体のアーキテクチャ、インフラ、ビジネス側の運

を考えてみる。 Git Flow nvie.com やってみたことある。良いんだけど、僕の環境だと、もうちょっとシンプルにやれそうかなって思った。 Github Flow scottchacon.com これはシンプルだな。なんだけど、シンプルすぎてちょっと違うかな。 ということで、ちょうどいいくらいのを考えてみたい 今の僕の開発にとって、ちょうどいいくらいのを考えてみたいなーって。じゃあ、今の僕のやってる開発ってどんなん？ってところから。 チーム エンジニア5,6人くらい。 Feature, Story, Task Featureと呼ばれるものがあって、これは2,3ヶ月分の規模で。この単位でリリースする。 Featureは複数のStoryで構成されていて、Storyは4,5日くらいで完了する。から、1 Featureは10から15Storyくらいってことか。 Storyは複数のTaskを

遂にちゃんとDockerの勉強を始めた。"Using Docker"という本を読んでる。 www.safaribooksonline.com Safari Books OnlineでいくつかDocker関係の本をあさってみて、この本が一番良さそうだと思ったので読み始めたとこ。 玉川さんが翻訳されるそうなので、細かいニュアンスはそちらが出たら確認しようと思ってる。(おい 今しかできない 今日は、まだDockerについて全然詳しくない今だから感じてるDockerのいいなぁって思うところを書き残しておこうと思う。使い慣れてしまう頃にはもう今の感覚はなくなってると思うので。 ゴールは、誰かあんまり調べる気はない人に「Dockerの何が良いの？」って聞かれたときに「色々あるけど、これかな」って手っ取り早く伝えられたらいいかなってとこ。 とりあえずDockerの何が良いの？1分で教えてよ！ アプリのコ