ソフトウェア開発で学んだが使わなかったもの
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
全力で効率の良くないチームをつくる - Mitsuyuki.Shiiba
というのが、最近の僕の好み。 効率の良いチーム 効率の良いチームは、みんなすごく効率良く仕事を頑張ってて。システムも効率良く既存のリソースを使ったりしてて、開発もすごいスピードで進んでいる。 なんだけど、最短の道を選び続けていて、どんどん選択肢がなくなっていって、動きが鈍くなってく。 そうすると、どうするか？「このままじゃダメだ！もっと効率良くやらなきゃ！」ってなって、最後には、頑張り続けて疲れた人が離れていく。そんな感じがする。 効率の良くないチーム きょろきょろしたり、うろうろしてみたりして、選択肢を広げておく。ペアワークとか。暗黙知の共有とか。形式知化とか。新しい技術へのトライとか。そういう、一見、遠回りに見える道の方が、実は近い。という感じがする。リファクタリングとかもそうかな。 遠回りに見える道を選ぶのには、勇気が要るのだけどね。だって、最短に見える道を選んだのにうまくいかなかっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
