タグ

コミュニケーションと開発に関するluccafortのブックマーク (3)

  • 人の相談になんてのるな。|市谷 聡啓 (papanda)

    講師をつとめる研修の終わりに、参加者からの質問というか相談に答えるようにしている。先日の研修で、ある受講者から「職場の開発をアジャイルにしていきたいがどうしたら良いか」というよくある相談が寄せられた。実はこの手の相談はやりとりに手間がかかる。相手の置いている前提、置かれている状況を的確に把握しなければならない。 私「なぜ、アジャイルに取り組みたいのですか」 まず、狙いを聞かねばならない。Start With Why。ここが分からないと何を聞いて答えても的外れにしかならない。ここで、いきなり「見える化から取り組むといいですよ」「もちろんスクラムですね」と、手段を提示しはじめるような相手だと、相談するのはやめたほうが良い。 受講者「スピード感のある開発をしないといけないと思っています。ユーザーの声を聞いて、それを実装していけるように」 私「なるほど、"何をつくるべきか分からない" ソフトウェア

    人の相談になんてのるな。|市谷 聡啓 (papanda)
    luccafort
    luccafort 2019/07/14
    "いきなり「見える化から取り組むといいですよ」「もちろんスクラムですね」と、手段を提示しはじめるような相手だと、相談するのはやめたほうが良い。"それな。でも慣れてない人はそれを期待してしまう。
  • コードレビューのクオリティとスピード,とくにスピードについて,それとコミュニケーションについて - hitode909の日記

    ソフトウェアを作るときにクオリティとスピードのバランスをとりたくて,どちらかに偏ってはいけなく,どちらもキープしないといけない.すごく雑に*1とらえると, クオリティ→正しく動き,不具合がないほうがよい スピード→(計算時間ではなく)早く作れるほうがよい ということになる. コードレビューでは,不具合を見つけて直してもらったり,動きはしてもコードの可読性に問題があって直してもらったりと,クオリティに目を向けられがちだと思う. ところで,コードレビューとスピードの関わりについて考えてみる.スピードのためにできることはいくつかあり, 早く読み始める→他のことやってても手を止めて読み始めたり,1日のうち決まった時間にレビュータイムを設けたり 速く読む→これはコツとかある*2けど精読しないといけないので難しい 不具合を見逃さない→リリース後とか,リリース直前に正しく動かないことが分かったら大きな手

    コードレビューのクオリティとスピード,とくにスピードについて,それとコミュニケーションについて - hitode909の日記
    luccafort
    luccafort 2017/06/02
    "小さいpull requestを少しずつ送ると,一度で収束するサイクルを導入しやすくなる"これぼくも同意なんだけど抵抗のある人はこの時間を取るのを嫌がっていてそういう人に対してどうするか?で悩む。
  • コードレビューに費やす時間を短くする - クックパッド開発者ブログ

    はじめに こんにちは、広告事業部の芳賀(@func09)です。普段はクックパッドの広告配信周りや純広告・タイアップ広告などの商品開発を行っています。 私が広告事業領域の仕事をするようになって、そろそろ1年になるのですが、初めはエンジニア以外の人(営業、編集、広告入稿、レポート、メール配信、などなど様々な担当者がいます)と業務をすることが多くてコミュニケーションが上手くいかず業務がスムーズに進まないことがありました。 当たり前のことではありますが、エンジニアにしかわからない言葉は使わないとか、できるだけ相手の業務を理解し相手の考え方や視点に立って話すなど、ちょっと工夫することで、長引きがちなMTG相談がすんなり終わったり、お互い良い気分で終わることが多くなって、費用対効果が高いなと感じています。 一方でエンジニア同士のコミュニケーションでも時間がかかってコストが高いと感じることがあります。

    コードレビューに費やす時間を短くする - クックパッド開発者ブログ
    luccafort
    luccafort 2015/03/31
    サンプル例が非常にわかりやすいし、非常に簡潔によくまとまっている。自分もコードレビュー依頼するときはこれくらいの簡潔さを心がけよう。どうしても説明調になってしまい肥大化してしまうんだよね。
  • 1