$shibayu36->blog;スマートフォン用の表示で見る$shibayu36->blog;株式会社はてなでエンジニアをしています。プログラミングや読書のことなどについて書いています。2014-05-14開発フローに新しい仕組みを導入するとき気をつけていることtech最近開発フローに新しい仕組みを導入したりすることも多いのだけど、気をつけていることがいくつかある。小さく導入する短く導入する振り返る小さく導入するなんか導入する時は出来るだけ小さく導入してる。理由はいきなりスクラムだとか言い始めてチーム全体のワークフローを変えようとした結果、チームの文化が崩壊するいきなりこれからはこのツールだとか言い始めてツールを導入した結果、誰も得してないのにツールだけ使われ続けるみたいなことがよく起こると思ってるため。既存の文化を壊したら元も子もないので結構気をつけてる。小さく導入すれば、影響範囲を最小限に留めることができるし、あとから簡単にやめることが出来る。導入する範囲を小さくするなどといったことが考えられる。ホワイトボードやプラニングポーカー、バーンアップチャートなどの仕組みを、新しく始まった新機能プロジェクトにのみ適応するその中でうまくいったホワイトボードの仕組みだけ、全体に適応するとかそういう感じでやってたりする。短く導入する導入する時はなるべくまずはこの期間導入するっていうのを決めてやってる。理由は期限を決めずに導入すると、なんとなくで続けられてしまうので、それを防ぐため区切りを付けることで、自分の中で振り返る機会を決めておくなどがある。大体、これまでのやり方は良くなかったのでやり方を変えます!と意気込んだやつは、ある部分は良くなるけどある部分は悪くなる。期限や区切りを決めてないと、大体そのままなあなあに運用され、全員があんま良くないのにと思ってても、なぜかそのまま続いてしまうことが多い。期限や区切りは自分の中で決めるか、みんなに共有する。終りがあるプロジェクトで区切るなどがある。振り返る小さく導入すると、変数が少ないので何が良くて何が悪かったかが分かりやすい。短く導入すると、それを振り返るきっかけが出来る。それで、最低でも自分の中で、可能ならチームを巻き込んで振り返りの機会を作っている。次からやることを出し合って議論したりする。やり方は結構柔軟にやってて、例えば、事前に考えてきてもらって議論するとか。最近はもうちょっとゆるく、何も準備なしで来てもらって、10分くらい付箋にいろいろ書いていってもらって、ホワイトボードに貼ったりしながら議論するという方が楽だし、議論も進みやすかったりするなーと思ってそうしてる。まとめなんとなく思ったこと書いた。チームの文化に合う、チームがやりやすい、というようなやり方はかなりそれぞれだと思ってて、大抵の場合全体的におすすめされているやり方をそのまま導入するとあまりうまくいかないと思ってる。導入する時は合わなかったらすぐやめられるように小さく短く導入したり、何が良かったか振り返って次に活かす、みたいなことが大事だなと思う。それでなんかミスったら、ごめんなんかうまく行かなかったって謝って一回仕組みをなくしたらいい。文化にあう仕組みみたいなの結構難しいし、それは仕方ない。自分のミスを認めずにそのままなあなあで導入しておくというのは一番良くないと思う。このへんの話、もうちょっと本とか読んで知りたいとか思ってるけど、あまりいい本が見つけられずにいるので、おすすめの本あったら教えて下さい。ちなみに文化大切にしたいというのはチームギークとかの影響です。月別アーカイブはてなブログをはじめよう!shiba_yu36さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。