タグ

teamに関するhamacoのブックマーク (6)

  • コードレビューの目的と考え方 - osa_k’s diary

    まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高(大きな損失を生む問題・後からの修正が困難な問題) 優先度中 優先度低(システムに大きな影響を与えない問題・後からの修正が容易な問題) レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを

    コードレビューの目的と考え方 - osa_k’s diary
  • Team building at forkwell meetup

    What we learned from our failure at Cookpad Mart to increase the probability of success in product development

    Team building at forkwell meetup
    hamaco
    hamaco 2017/09/20
  • 情報を無視する能力 - 良いあそなすちゃん

    情報を流す人が対象になる人を選ぶ労力と漏れのリスクととりあえず全員に流して各人がそれを取捨選択する労力ではどちらがよいのだろうなぁ— あそなす (@asonas) 2014, 12月 17 エンジニアじゃない人もリポジトリにコミットしたり、チャットでがやがや話をしていたり、Issuesトラッカーで盛り上がりをみせていたり、そういう情報があふれるチームで何年も仕事をしていると、必要のない情報を無視する能力が育ってくる。 メンションがきたら何かしらのポップアップで僕に通知がくる。それを見て、自分に関係ありそうなものだったら何かアクションをする、そうじゃなかったら無視をする。そういう能力。鍛えれば鍛えるほどその判断は高速にできて、仕事が捗る。 「いや、そもそも通知とか必要最低限にしておけばそういう判断も能力も必要ない」という意見もあるけど、それって結局情報を発信する側が、その情報を必要としてそう

    情報を無視する能力 - 良いあそなすちゃん
  • 雑に発言をしよう - id:bash0C7の進捗 過去アーカイブ[〜2019-02-23]

    雑というとネガティブな意味合いが強いかもしれませんが、そういうのじゃないです。 雑(ザツ)とは - コトバンク 今回述べたい「雑に発言する」とは、きっちりと推敲したり計画立ててやってるわけじゃないおおざっぱな、しかしそれを契機に話を膨らませたり、世界観の一端を伝えたりできるような、適当に役に立つライトウェイトな発言という事です。 正確とは さて、普段仕事をしている中では、正確な発言が求められます。正確な指示、正確な報告、正確な情報共有などなど。 もちろん間違った事をあえて必要はまったくなく、正確であることはいい事です。 しかし、いつでも正確でいられるでしょうか。例えば、事実確認は確かに正確かどうかの判断がやれるかもしれません。ですが、今後のアクションについては正確さは正確である/正確でないの2値ではないです。その間には色々な何かがあります。 我々の仕事は*1その間の微妙なところ、とくに不正

    雑に発言をしよう - id:bash0C7の進捗 過去アーカイブ[〜2019-02-23]
  • 情報共有おじさん - ローファイ日記

    プロジェクト全体のMLにエラー通知メール飛ばすのうざい」、「〜についてはみんながいるチャンネルで相談すべきことではない」みたいな指摘がある。 個人的には情報は可能な限り広いスコープで公開してほしいし、自分でもそうしようとしている。まだ未熟なので霊力に負けることもあります...。 というのも、「情報が届いていない」ことによる不利は仕事上非常に大きいし、場合によって致命的になるので、むしろ冗長化して届けられているべきなのである。 あと、情報が多ければ多いほど普通は判断が適切になると思うので、情報が広く共有されていると言うことは、チームメンバー一人一人が自分で判断できる材料を持ちやすくなると言うことにもつながる。スクラムとか色々言われているけど「一人一人が自分で判断できる」ということはどういう開発スタイルでも大事だと思う。 なのでむしろみんながいる場で議論していたり、細かい情報をどんどん流して

    情報共有おじさん - ローファイ日記
  • チームを良くする話 - 良いあそなすちゃん

    今いる会社でプロジェクトはいくつかあって、それぞれのチームにエンジニアが居るんだけど、僕のチームでは厳密にはエンジニア1人でやっている。 最近、ただ単にぼっちなのが寂しいのかこの半年で急激にエンジニアの数が増えてきてコミュニケーションの機会が減ったのか僕が昼すぎから出社するからなのか、理由はよくわからないけど、会社の日報に日々思ってることを長文にして投げたりとか、Wikiにポエム書いてたりしてたら、なんとなく他のチームにも伝搬していってて日報にポエムが溢れかえるようになった。お前ら女子か。 ポエムというのは言い過ぎかもだけど、日々思っていることをチームの中に共有するのはすごいいいものだなぁと感じる。日報、ありがちなのはその日にやったことを書いたりするけど、僕はあんまりそういうの気にして無くて、「君がいるチームのリポジトリでgit logすればわかることやん?」ってなる。いや、もちろんそうい

    チームを良くする話 - 良いあそなすちゃん
  • 1