タグ

ブックマーク / bufferings.hatenablog.com (34)

  • アジャイルな開発とチームづくり - Mitsuyuki.Shiiba

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

    アジャイルな開発とチームづくり - Mitsuyuki.Shiiba
  • 知らない技術は怖い - Mitsuyuki.Shiiba

    AよりB、CよりD 今後の方向性を決める判断の中で「Aという技術ではなくBを採用する方がが良さそうです」とか「既存システムのCは良くないからやめてDを使うようにしましょう」とか。最近、何人か全然別の人からそういう話を聞く機会があった。 AよりBが良さそう? 「僕はAの方が良いと思うんですけど、Bの方が良さそうだと思う理由を知りたいです」って聞くと「Aはこういう部分に問題があると思います」って言われて話が噛み合わなくて、しばらく話をして気づいた。 この人、Aを触らずに想像だけで喋ってるんだ。ってことに。なので、実際に動かして見せてあげると「あぁ、それならAの方が良いですね」ってなった。 「興味があるだけなんですけど、僕も知らない技術だったので少しドキュメントを読んで実際に触ってみて機能を確認してからAの方が良いなと思ったのですが、どうして触らずに想像だけでAは問題があるって断言したんですか?

    知らない技術は怖い - Mitsuyuki.Shiiba
  • 僕のチームのGitの開発フロー - Mitsuyuki.Shiiba

    を考えてみる。 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を

    僕のチームのGitの開発フロー - Mitsuyuki.Shiiba
  • 僕らのモブプログラミングは「全員でプログラミングをする」ということではなかった - Mitsuyuki.Shiiba

    ## 去年の夏ぐらいからサポートしているチーム で、それまでもちょこちょこモブプログラミングを試してはいたんだけど、3月からは思い切ってそれを基として開発をするようにした。つまり、3月からは1日中モブプログラミングをするのを毎日やってる。 プログラミングだけじゃなくて、設計も、運用も、テストも、全部モブでやってるので、僕らはそれをモブワークと呼んでる。 ## やっていく中で学んだのは モブプログラミング(モブワーク)は「全員でプログラミングをする」ということではなくて「全員で考えて取り組む」というだけのことだった。 サービスにとってどう動くのが良いかを全員で考える。 目の前のプロジェクトのことだけではなく、少し先を見据えてメンバー間の知識やスキルの共有や、チームがまだ詳しくない分野の学習をすることも含めて、どこにトレードオフスライダーをセットするのが良いかを全員で考える。 ## 全員でプ

    僕らのモブプログラミングは「全員でプログラミングをする」ということではなかった - Mitsuyuki.Shiiba
  • エンジニアが何か問題にぶつかったときにあるといい力を5個 - Mitsuyuki.Shiiba

    最近ちょこちょこ相談されることがあって、直接のスキルではないけど、こういうのもスキルだよなぁって思ったので、思いついた順に書いてみる。5個になった。 ## 1. 問題を切り分ける力 「これがなぜか動かない」って相談されたときって、いくつかの要素が絡んでることが多い。 なので「ここは明らかに問題ないでしょう」という一番土台のところからチェックを始める。そうすると「え?そこは問題ないと思いますよ?」って言われるので「うん、それを『問題ないと思う』じゃなくて『問題ない』って断言できるようにしようと思って」みたいな会話をよくする。 可能性をひとつずつつぶしていくと「ここだなぁ」って場所が見つかって、そしたら、もうあとはそんなに難しくない。ひとつずつ確認していくのって遠回りに見えるけど、結局その方が確実ではやいと思う。 ## 2. 想像と事実を切り分ける力 ↑と絡んで、想像や思い込みなのに、「ここは

    エンジニアが何か問題にぶつかったときにあるといい力を5個 - Mitsuyuki.Shiiba
  • 開発をうまく回したいなと思って僕が意識している40くらいのこと - Mitsuyuki.Shiiba

    自分がこの1年間開発チームを引っ張ってきた中でこういうところに気をつけてたよってこと。 ザーッと勢いで書いてみる。分類はある程度なもんです。組織パターンやFearlessChangeは好きです。 心構え 1 現状を受け入れる 環境に文句を言ってても、何も変わんないし。自分は当はもっとできるはずなんだ、って言ってても、実際アウトプットはでてないんやろ。なるほど、今はこうなんだってことを受け止めて、じゃあそこからどう改善していけるだろう?と考えたい。 2 遷移状態を受け入れる 現状から、理想的な状態にぴょんって飛び移れるわけじゃないんだから、その途中って泥臭かったりごちゃごちゃしてたりするんだけど、それを受け入れる。練習せずにいきなりスポーツがうまくなるわけないのと同じで。 3 正しいことが選ばれるわけじゃない 政治や感情や時期や思惑や抵抗や。そういうのがあるので「正しいこと」が常に選ばれる

    開発をうまく回したいなと思って僕が意識している40くらいのこと - Mitsuyuki.Shiiba
  • 良い本だったよー→モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める - Mitsuyuki.Shiiba

    ## 2月23日に発売予定 解説を書かれた及部さんからいただきました。ありがとうございます! 今日届いてたのでどんなことが書いてるのかちょっとだけ読んでみようかなーって思いながら、あーわかるーとか言いながら読んでたら、サクッと読み終わってしまった。おすすめです。 books.rakuten.co.jp ## 読んでみてどうだったか? 良かった! 僕はこれまでに、何度かモブプログラミングを小さく実験してて「ふーむ。これは良さそう」と思ってて。ついに先週は「一週間ずっとモブプログラミングをする」という実験をして、このチームに合ってるなーと感じたので、組織として正式に導入する相談を進めてるところ。 このには、そんな僕達が学んだり、悩んだり、試行錯誤したり、実感したりしたことの多くが書いてあって、笑った。先に読みたかったわ。 ## どういう人におすすめ? こういう人かな: モブって何が良いの?っ

    良い本だったよー→モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める - Mitsuyuki.Shiiba
  • たまに「スクラムが難しい」って相談があって見に行ったりする。 - Mitsuyuki.Shiiba

    「プロダクトオーナーとしてやることはしっかりやってるんです」 「もちろんバックログがあります。そして、ストーリーが優先順にならべられています」 「MVP(Minimum Viable Product)も考えていて、ここまでが必須だと考えています」 「そしてこのMVPをこの日までにリリースしたいと考えているんです」 いいですね。 でも、ストーリーポイントを見たところ難しそうですね。 「そうなんです。もうプロダクトオーナーとして自分ができることは全てやりましたから、あとは開発チームに、この日までにリリースできるようになんとか頑張ってもらうしかないと思っています。スクラムではこういうときどうしますか?」 そうですね・・・。まずは、実現できないということを受け止めましょう。 「え?」 そして、ここで頑張るのは開発チームではなくてプロダクトオーナーですね。 「もう自分のできることは全てやっていますよ

    たまに「スクラムが難しい」って相談があって見に行ったりする。 - Mitsuyuki.Shiiba
  • 読みやすいコード(僕にとって) - Mitsuyuki.Shiiba

    最近気づいたことがある。それは、僕はみんなみたいに複雑なことが理解できない、ってこと。 話をしてても「ごめんなさい。いまのわかんなかった。もう一回教えて欲しい。」とかよくあるし。ドキュメントも、ちょっと複雑なことが書いてあると、全然頭に入ってこない。 色んなルールがドキュメントに書いてあって、それをちゃんと守りながら開発してる人たちとか見てると、みんなすごいなぁって思うのであった。 なんだろうなぁ。こう・・・色んな想像が始まってしまって、考えが落ち着かないんよね。 そんな僕なのだけど、ここ数年はありがたいことに色んなコードを読む機会がある。読みやすいコードもあれば、パズルみたいに複雑なものもあって。そんな中で、たぶん、僕にとって読みやすいコード、というのは普通の人にとってはとても読みやすいコードなのかなぁって思って。書いてみる。 JavaでWebのアプリを開発してる。基盤とかフレームワーク

    読みやすいコード(僕にとって) - Mitsuyuki.Shiiba
  • 僕がJavaのWebアプリのコードレビューをするときって何を気にしてるっけなぁ? - Mitsuyuki.Shiiba

    コードレビューをするときには、フォーマットや慣例的な書き方とか、名前ちゃんとした方が良いよとか、処理にも名前をつけようねとか、そういうことは伝えるんだけど。それよりももっと気にするのは、「ここで見つけておかなきゃいけない」ってことだなぁってふと思ったのだった。 ここで見つけておかなきゃいけないこと? 仕様に従ってるかどうかとかは、動かしてみれば分かるし、PDM(Product Manager)が受け入れテストとして見てくれたり、QAと呼ばれるテストのチームがやってくれたりもする。ので、そこまで気にしてない。 気にするのは、エンジニアがソースを読むことでしか見つけづらいバグ。かな。特定の条件が重なったときにだけ発生するようなやつとかそういうの。10msのタイミングで発生するとか、12/31の0時にだけ発生するとか、エラーが発生したときにだけ発現するとか、今は大丈夫だけど2年後ぐらいに発火する

    僕がJavaのWebアプリのコードレビューをするときって何を気にしてるっけなぁ? - Mitsuyuki.Shiiba
  • TDDはあんまり使わなくなったけど心の中にある - Mitsuyuki.Shiiba

    今日は娘たちとコログ探しして楽しかった。 この数年間、頭の中にTDDを入れた状態で開発をしてきたんだけど。タイトルに書いた風に思う。 良い所がいっぱいある 見失わずに済む 僕にとってTDDの良さは、まず、自分が何をしようとしているかを見失わずに済むところ。一歩先にゴールを立てて、そこに向かって一歩進む、たどり着いたら、次の一歩を進める。その繰り返し。だから、遠く離れたゴールに対して、急いで走って、途中で道に迷ってどこに向かってるか分かんなくなったりしないで済む。 余計なものを作らなくて済む 「必要なものはこれだよね?」という確認から入って、それを実現するための実装に集中するから余計なものを作らなくて済む。実装を先に作ると「こういう機能もあるといいかもだから入れとこうかな」ってついつい入れてしまう。 リファクタリングできる まず最初に動くものを作ってから、その状態をキープしたまま、実装の改善

    TDDはあんまり使わなくなったけど心の中にある - Mitsuyuki.Shiiba
  • モブプロをやってみた。良さ。使いどころ。 #devkan - Mitsuyuki.Shiiba

    devlove-kansai.doorkeeper.jp モブプログラミングやってきました!面白かったー。疲れたー。面白かったー。 モブプログラミングって? チーム全員(プロダクトオーナー含む)が集まって、1人だけがコードを書いて、それがスクリーンに映しだされてて、その他の人みんなでやいやい言いながらものを作っていく。というスタイル。ルールは「ドライバー(コードを書いてる人)は、ナビゲーター(周りでやいやい言ってる人)に言われた通りにコードを書く。ドライバーが自分で考えてコードを書くのはダメ。」という感じ。 やってみた 7人ぐらいのチームで、プロダクトオーナーからのお題に対してTDDで実装をやってみた。2部制でやったのだけど、第1部はKotlin + IntelliJ IDEAでローマ数字の計算を。Kotlin全く知らないし、IntelliJも全然慣れてない。第2部はJavaで自動販売機を

    モブプロをやってみた。良さ。使いどころ。 #devkan - Mitsuyuki.Shiiba
  • だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう? - Mitsuyuki.Shiiba

    先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第2ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1買えること」 最初に「100円を入れてボタンを押すとコーラが1買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速! 「200円を入れてボタンを押すとオレンジジュースが1買えること」 次に「200円を入れてボタ

    だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう? - Mitsuyuki.Shiiba
    mikage014
    mikage014 2017/06/01
    現実だと1ヶ月でも1週間でもいいから現場に足突っ込んでくると良かった。真の要件は会議室ではなく現場にある。言葉にすると伝わらない肌感覚もある。
  • プログラムが動くのが1割で、残りの9割って何だろう?って思って書いてみた。 - Mitsuyuki.Shiiba

    ぼけーっと、自分の中に、観点とそのレベルみたいなんがあるなぁって思って。書いてみた。 A: 動く A-0: 動かんよ! A-1: とりあえず動くよ! A-2: 動くことをテストで確認してるよ! B: 異常系 B-0: 正常系しか考えてないよ! B-1: 想定内の異常系が考慮されてるよ! B-2: 想定外の異常系でも不整合が起きないよ! C: サービス運用 C-0: サービス運用がまわらんよ! C-1: サービス運用がまわせるよ! C-2: サービス運用がなくてもまわるよ! D: コードの保守 D-0: 読めん! D-1: 変数やクラスに適切な名前がついているよ! D-2: コードを読めば意図が伝わるよ! ドヤァ! 1日でできたぞ!どやぁ!って感じで。たぶん、このときが一番コード書けてるように思えるので一番楽しい。 A-1: とりあえず動くよ! B-0: 正常系しか考えてないよ! C-0:

    プログラムが動くのが1割で、残りの9割って何だろう?って思って書いてみた。 - Mitsuyuki.Shiiba
    mikage014
    mikage014 2015/12/11