nabokov7; rehash : 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム
October 22, 201010:13 カテゴリプログラミング組織とyou 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム perl 界隈の皆様、YAPC::Asia 2010 おつかれさまでした。 @nipotan のライトニングトークはシャッフルに関する話でした。で、ここで、なぜそもそもシャッフルが出てきたのかについて、チームマネジメント的な観点から補足したいと思います。 (元の発表はこちら: 動画 / スライド ) ■相互チェック体制の運用 ライブドアのプログラマは、だいたい一人でひとつのサービスを受け持っています。一人が複数のサービスを受け持つのは普通ですが、一つのサービスに複数のプログラマがフルコミットするという贅沢な状況はあまりありません。 担当が一人ずつしかいないと、担当の人が休むと何も進まない。やりたいことが色々あ
ソフトウェアレビューが成功する進行役の6条件
全員に配慮し、よりよい指摘を引き出すスキルが必要 さて、以上のような役割を1人1人が明確に認識したうえでレビューに取り組むと、あらゆる無駄がなくなり、効率、効果ともに大幅に向上します。そのイメージをつかんでもらうために、前のページで紹介した「進行役が配慮すべきポイント」を実践に落とし込んだ進行例を紹介します。同じレビューでありながら、冒頭の例とは雲泥の差があります。進行役の言動について、（ ）内に解説を加えましたので参考にしてください。 進行役 「今回のレビューの目的は、タイミング問題になりそうな部分がないかを確認することです。タイミング問題が原因となってテスト工数が大きく膨らむことは、経験的に理解していると思います。安定したリリースに向け、この場でタイミング問題をつぶしておきましょう」 （まず、レビューの目的を明確化している） 進行役 「なお、自身の作成物のエラーを指摘されることは恥ずか
スペル修正プログラムはどう書くか
Peter Norvig / 青木靖 訳 先週、2人の友人(ディーンとビル)がそれぞれ別個にGoogleが極めて早く正確にスペル修正できるのには驚くばかりだと私に言った。たとえば speling のような語でGoogleを検索すると、0.1秒くらいで答えが返ってきて、もしかして: spelling じゃないかと言ってくる(YahooやMicrosoftのものにも同様の機能がある)。ディーンとビルが高い実績を持ったエンジニアであり数学者であることを思えば、スペル修正のような統計的言語処理についてもっと知っていて良さそうなものなのにと私は驚いた。しかし彼らは知らなかった。よく考えてみれば、 別に彼らが知っているべき理由はないのだった。 間違っていたのは彼らの知識ではなく、私の仮定の方だ。 このことについてちゃんとした説明を書いておけば、彼らばかりでなく多くの人に有益かもしれない。Googleの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
