cpwのブックマーク - はてなブックマーク

開発チーム間の情報を遠回りさせてる - Mitsuyuki.Shiiba

いまの会社では、エンジニアどうしの距離が近いので、他のチームのエンジニアと一緒に開発に取り組んでたりする。のだけど僕からは﹁この部分はディレクター︵社内でスクラムマスター的なロール︶さんから、あのチームのディレクターさんに共有してもらってもいいですか？﹂って自分のチームのディレクターにお願いしたり﹁この部分はプロダクトマネージャ︵社内のプロダクトオーナー的なロール︶さんから、他のチームに確認してもらってもいいですか？﹂ってプロダクトマネージャにお願いしたりしてる。エンジニアどうしで話をして、お互いに状況を理解しているのに、公式なルートとしては、情報を遠回りさせているのだ。そんなお願いをすると、一瞬︵え？エンジニアどうしで話して認識合ってるのに？︶って反応をされるし、僕自身も︵大企業っぽいかなぁ？︶って思ったりするのだけど、自分の気持ちを説明すると﹁たしかにそうね。おっけー！やっ

cpw 2023/07/16

結局最終的にコード外で仕様を残す文化なら積極的にエンジニア外を巻き込んだ方が良さそう。コードが仕様の文化ならエンジニア間で決められるものなら早い方で良いと思う。結局コード見ないと分からないんだよねー。 ●開発 ●エンジニア ●management ●仕事

リンク

Gitのコミットメッセージは適当に書いてる - Mitsuyuki.Shiiba

「Gitのコミットメッセージをしっかり書こう」という記事を読んで、いい話だなーと思う一方で、うちのチームはちょっと前に「コミットメッセージは適当でいこう」って決めたなーって思った。 Gitのコミットメッセージをしっかり書こうという話【備忘録的共有】 | SIOS Tech. Lab しっかり書くのを否定するわけでは全然ない。しっかり書くのはしっかり書くのでいいなって思う。どっちがいいかはチームやプロダクトによるので、チームがいいと思う方を選べばいいかなと。僕もしっかり書くほうがいいなって思うときもあるのだけど、今のチームでは適当のほうがいいなってだけ。しっかり書きたいとき僕が、コミットメッセージをしっかり書きたいときはどういうときだろう？って考えると、OSSにプルリクエストを出すときかなぁ。自分は特にOSSの何かを作ってるわけじゃないけど、自分で何かのOSSを作るならある程度ちゃんと

cpw 2023/06/06

ソースコードをドキュメントにしている文化の会社だからコミットメッセージを参照したことがない。

git

リンク

ウェブアプリケーションエンジニアとして転職活動をしますー！ - Mitsuyuki.Shiiba

しばらくしたら次のことを考えたいなと思ってるので、よい仕事や空いてるポジションがあったら教えてください！— Mitz Shiiba@フルスタックエンジニア (@bufferings) December 8, 2022 突然ですが CircleCI を辞めることになりました。そのことについてあまり話すつもりはないのですが、今の気持ちだけ書いておくと、びっくりはしたけど特にネガティブな感情はなく、面白い経験だなぁという気持ちです。この一年間、色々とあまりできない体験をしてきた締めくくりにピッタリです。この状況を受け入れて、流れに身をまかせて楽しもうと思います。ということで、こんな機会はあまりないので、次をどうするか、折角だから色々な会社のお話を聞いてから考えたいなぁと思ってつぶやいたら、たくさんのご連絡をいただき、とても嬉しく思っています。ひとつひとつのお誘いや励ましが、とてもありがたいで

cpw 2022/12/11

エンジニア

リンク

約束は開発を遅らせる - Mitsuyuki.Shiiba

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

cpw 2022/11/23

スコープを小さくすると期待感ズレなくて良いと思ってる。長くても2週間くらい、通常なら3日以内くらいのサイズに機能を分解して実装していくとブレが少ない。

リンク

「ユニコーン企業は書籍に書かれているようなアジャイルなんてやってない」 - Mitsuyuki.Shiiba

4/26 に発売されます！﹁ユニコーン企業のひみつ﹂をいただいて読みました。読みやすくて面白かったー。4/26 に発売されます！チームをリードしている人や組織づくりをしている人にはもちろんおすすめだし、メンバーの一員としてチームの中で仕事をしている人も﹁なるほどそんな風に仕事をしてるのかー！﹂って感じることができて面白いと思うー。あと、アジャイルな開発とかスクラムをやってる人ももう一度自分の大切にしているものを見直すことができるんじゃないかなぁ。ぜひどうぞ。 www.oreilly.co.jp ユニコーン企業はスクラムをやっていないこの本の﹁ユニコーン企業﹂とか﹁テック企業﹂って﹁大きくなってもスタートアップみたいな働き方をしている企業﹂のことで、Google・Amazon・Facebook・Spotify のような企業を指してる。そういった企業が何を大切にしているか、どんな風に開発を

cpw 2021/04/25

感覚的にはスクラムに従うと生産性がすごく下がるイメージ。

アジャイル

リンク

はてなブックマーク

タグ

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

お知らせ

今週のはてなブックマーク数ランキング（2024年7月第3週）

今週のはてなブックマーク数ランキング（2024年7月第2週）

はてなブックマーク透明性レポート（2024年 2月-2024年4月）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス