エンジニアが何か問題にぶつかったときにあるといい力を5個 - Mitsuyuki.Shiiba
最近ちょこちょこ相談されることがあって、直接のスキルではないけど、こういうのもスキルだよなぁって思ったので、思いついた順に書いてみる。5個になった。 ## 1. 問題を切り分ける力 「これがなぜか動かない」って相談されたときって、いくつかの要素が絡んでることが多い。 なので「ここは明らかに問題ないでしょう」という一番土台のところからチェックを始める。そうすると「え？そこは問題ないと思いますよ？」って言われるので「うん、それを『問題ないと思う』じゃなくて『問題ない』って断言できるようにしようと思って」みたいな会話をよくする。 可能性をひとつずつつぶしていくと「ここだなぁ」って場所が見つかって、そしたら、もうあとはそんなに難しくない。ひとつずつ確認していくのって遠回りに見えるけど、結局その方が確実ではやいと思う。 ## 2. 想像と事実を切り分ける力 ↑と絡んで、想像や思い込みなのに、「ここは
たまに「スクラムが難しい」って相談があって見に行ったりする。 - Mitsuyuki.Shiiba
「プロダクトオーナーとしてやることはしっかりやってるんです」 「もちろんバックログがあります。そして、ストーリーが優先順にならべられています」 「MVP(Minimum Viable Product)も考えていて、ここまでが必須だと考えています」 「そしてこのMVPをこの日までにリリースしたいと考えているんです」 いいですね。 でも、ストーリーポイントを見たところ難しそうですね。 「そうなんです。もうプロダクトオーナーとして自分ができることは全てやりましたから、あとは開発チームに、この日までにリリースできるようになんとか頑張ってもらうしかないと思っています。スクラムではこういうときどうしますか？」 そうですね・・・。まずは、実現できないということを受け止めましょう。 「え？」 そして、ここで頑張るのは開発チームではなくてプロダクトオーナーですね。 「もう自分のできることは全てやっていますよ
チームリーダーをやるときに気をつけてた「4つの混ぜない」 - Mitsuyuki.Shiiba
開発チームのチームリーダーやってたときってどんなこと考えながらやってた？って相談があって、僕がチームリーダーやってたときはこういうことに気をつけてたよ。って話をした。今は僕はリーダーは後輩にまかせて、自分はシニアエンジニア的な立場でコードを書いたりウロウロしたりして楽しく過ごしてるんだけども。 4つの混ぜない やってるときは特に考えてなかったけど、今になって考えるとこういうこと気にしてたなーってのね。数は、単に4つ思い出した。ってだけ。 帽子を混ぜない エンジニア出身のチームリーダーって、こんな帽子をかぶってることが多いかな: 組織マネージャの帽子で 後輩の育成や組織としての成長を考えたり 開発リードの帽子で クオリティの最後の砦みたいな役割や、チームの外との調整をやったり プロジェクトマネージャの帽子で プロジェクトをどうやってうまく回していくかを考えたり なので「今の自分の気持ちはどの
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
デイリースクラムで「困っていることは？」って言ってもでてこなくなった話 - Mitsuyuki.Shiiba
最近は、他のチームのプロセスだったりシステムだったりを改善していくサポートをしたりしてるんだけど。今日はデイリースクラムのお話。 進捗報告じゃないよ？ デイリースクラムって「昨日やったこと」「今日やること」「困っていること」を話すけど。誰かに対する進捗報告じゃなくて、お互いに対する共有だよね。って思う。 3つの質問は手段でしかないよ？ それと、デイリースクラムの3つの質問は手段であって、大切なのは「スプリントゴールに対して今僕らはどの位置にいるか」っていう足下確認をすることかなって思ってる。 ちょっと違うのかも？ んで、僕の見てるチームの特性として、ちょっと他のチームと違うのかなって最近感じてるのは、「全てのタスクをペアで担当している」ということ。 プログラミングだけじゃなくて、設計したり、ドキュメント書いたり、テストを作ったり、実施したりとか、そういう全てのタスクをペアで担当している。
続々：僕の好きなコードの書き方 - Mitsuyuki.Shiiba
これの続きです！ レビューしてもろた！ おぉ。メソッドわけない前提で、price<sumのほうが正常系なんだから先に異常系を抜けるべきってのと、正常系だけresultの値設定順が違うのと、最初のthrowがただのgotoになっててバグぽい。「続：僕の好きなコードの書き方」 http://t.co/6drsy6VG8I— きしだલ (@kis) May 8, 2015 そっこーでコメントくれてた！確かに確かに！ @bufferings 僕ならstaticイニシャライザで、def(1, 0); def(5, 0); def(10, 10); みたいなのたくさん定義してMapで持っとく。— CEROMETAL (@cero_t) May 12, 2015 なるほどですなー。 あと、@haradakiro にも「お邪魔したいのでテストコードも晒さないかな、ちらっちらっ」ってコメント頂きました。 レ
isValidの書き方 - Mitsuyuki.Shiiba
きっかけ コードのネストを深くするな | anopara を読んで、 僕もネストは浅い方が好きだけどisValid…お前はダメだ。 - bufferings のコメント / はてなブックマーク って書いたら、@m_seki さんに"isValidダメなんだ。どう書けばいいの？"というツッコミを頂いたので。ちょい考えてみた。まぁ、元記事の主題とは関係ないところなので。ゆるりとね。 元々のんは、こんな感じ？ Groovyで書いてみた。 class Data { def Count def Error def Result } class Validator { boolean isValid(Data a) { if(a != null) { if(a.Count > 0) { if(a.Error == null) { if (a.Result != null) return true; }
開発をうまく回したいなと思って僕が意識している40くらいのこと - Mitsuyuki.Shiiba
自分がこの1年間開発チームを引っ張ってきた中でこういうところに気をつけてたよってこと。 ザーッと勢いで書いてみる。分類はある程度なもんです。組織パターンやFearlessChangeは好きです。 心構え 1 現状を受け入れる 環境に文句を言ってても、何も変わんないし。自分は本当はもっとできるはずなんだ、って言ってても、実際アウトプットはでてないんやろ。なるほど、今はこうなんだってことを受け止めて、じゃあそこからどう改善していけるだろう？と考えたい。 2 遷移状態を受け入れる 現状から、理想的な状態にぴょんって飛び移れるわけじゃないんだから、その途中って泥臭かったりごちゃごちゃしてたりするんだけど、それを受け入れる。練習せずにいきなりスポーツがうまくなるわけないのと同じで。 3 正しいことが選ばれるわけじゃない 政治や感情や時期や思惑や抵抗や。そういうのがあるので「正しいこと」が常に選ばれる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
