お願いしなくても毎日その場がやってくる良さ - Mitsuyuki.Shiiba
軽くリファインメントをする時間 いまのチームでは、デイリースクラムのあとに毎日15分だけ、軽くリファインメントをする時間をとっている。目の前のスプリントのタスクのことをいったん忘れて、次のスプリントやもう少し先のことについてチームで相談する時間。 そこでは、PdM（プロダクトマネージャ）が「こういうこと考えてるんだけどどう思う？」って話をしてくれたり、エンジニアが「このあたり早めに改善しておきたいんだよねぇ」って話をしたりしている。 こういう軽い相談の場とは別に、もっと深く議論したいと思ったり、要件がかっちりと決まってきたりしたら、別途時間をとって、軽くないリファインメントでしっかりと相談している。 軽いリファインメントが結構好き 僕はこの日次の軽いリファインメントが好き。自分の「技術的な部分の改善をしたい」という考えをふわっとしてる段階で聞いてもらえるし、PdMがプロダクトの機能追加や改
神コントローラーにテスト駆動開発で機能追加 - Mitsuyuki.Shiiba
TDDBC オンラインの基調講演の録画を見た。とても面白かった。和田さんのセッションやスライドは何度も見て勉強してるので、それをひとつずつ再確認しながら見ることができて、とても良かった。話の流れが分かりやすくてすごいなー。 #tddbc みるー TDD Boot Camp 2020 Online 1 基調講演/ライブコーディング https://t.co/g4AkCkr429— Mitsuyuki Shiiba (@bufferings) August 8, 2020 最近実際にやったテスト駆動開発 その録画を見ながら、最近自分がテスト駆動開発で機能追加をしたことを思い出してた。今日は、それをだらだらと書いてみようと思う。プライベートメソッドに対してテストを書いてたりするのが、なんか泥臭くて面白いかなと思って。 背景 自動テストが全くないプロダクト God コントローラー（1000行以上あ
モブプロをやってみた。良さ。使いどころ。 #devkan - Mitsuyuki.Shiiba
devlove-kansai.doorkeeper.jp モブプログラミングやってきました！面白かったー。疲れたー。面白かったー。 モブプログラミングって？ チーム全員(プロダクトオーナー含む)が集まって、1人だけがコードを書いて、それがスクリーンに映しだされてて、その他の人みんなでやいやい言いながらものを作っていく。というスタイル。ルールは「ドライバー(コードを書いてる人)は、ナビゲーター(周りでやいやい言ってる人)に言われた通りにコードを書く。ドライバーが自分で考えてコードを書くのはダメ。」という感じ。 やってみた 7人ぐらいのチームで、プロダクトオーナーからのお題に対してTDDで実装をやってみた。2部制でやったのだけど、第1部はKotlin + IntelliJ IDEAでローマ数字の計算を。Kotlin全く知らないし、IntelliJも全然慣れてない。第2部はJavaで自動販売機を
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - 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
このまえ書いたのの続き この前の→ 開発するときに考えていること。信頼関係 マネージャ編。 - Mitsuyuki.Shiiba 今日はビジネス側の人の信頼を得るために僕が考えていること。 例によって、相手の立場で考えるところから始めよう。 ビジネスな人なので、ビジネスゴールがあって、それを追いかけてるんね。そのビジネスゴールは絶えず変化し続ける。最初に決めた場所に、ずっと向かい続けてもしょうがなくて。常に状況をみてどこに向かうべきかを判断し続けないといけない。という状況。 開発チームに求めるもの ここで、ちょっとタクシーに乗ることにしよう。 「京都の醒ケ井高辻ちょっと下がったところまでお願いします。」 こういうタクシーだったらいいなーってのは。 目的地までの最善の道を知っていること。「最短の道」でなくてよくて。渋滞や工事を考慮して「最善の道」を選んで欲しいなーと。 「この道を通ってここま
信頼関係 開発チーム編 - Mitsuyuki.Shiiba
自分の中の考えをまとめるシリーズの続き。前回まではこんなの 開発するときに考えていること。信頼関係 マネージャ編。 - Mitsuyuki.Shiiba 信頼関係 ビジネス側の人編。 - Mitsuyuki.Shiiba 今日は開発チームの信頼を得るために僕が考えていること。これで信頼編は最後！ いつもどおり相手の立場で考えるところから。とはいっても僕はエンジニアなので。自分のことを考えればいいのかな。 エンジニアは良いものを作りたい。お金が儲かるってのはもちろん良いんだけど、もちょっと奥の方に、誰かに喜んでもらえたら嬉しいとかがあるかなーと思う。とにかく良いものを作りたい。 でも、実際の仕事でそんな気持ちをそのまま出せるかというと。そういうもんでもなくて。それは何故だろう？と考えてみたんだけど。理不尽なことが多いからかな。と思った。 開発チームって工程的には下流にいて、だから、理不尽なこ
開発するときに考えていること。信頼関係 マネージャ編。 - Mitsuyuki.Shiiba
組織パターンを読んでたら@haradakiroさんに「そんな風にして自分の頭の整理できるよ」と言われ。なるほど。と。なので整理。とはいえパターンに昇華させられるまで考えられたりはできないので雑だよ。 作りながら書いてるから最終的にどうなるかは僕も知らんよ。 立ち位置 最初に立ち位置を簡単に。 僕は自社でWebサービス作ってる会社のいちウェブアプリエンジニアです。 いい感じのチームでコードを書いて過ごしたい！ ↑ じゃあいい感じのチームを自分で作ろう！ ↑ じゃあチームの外側のコントロールしなきゃ！ ってだんだんやりたい場所から遠ざかっている感じ。てイマココ。 まぁこれも悪くない。 開発するときに考えていること まずは何をやるにも信頼関係を築くのが最初に必要よね。ないと色々面倒。 信頼を得て最初に取り組んだのが、プロジェクトのリーダーをBizLeadとDevLeadに分けたこと。 BizLe
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
