チームに浸透させるのが近年では難しくなっている - id:onk のはてなブログ
昨日「動いたけどチームメンバーを説得するのが面倒で、秘蔵のブランチになってしまう」って言ったけど、この気持ちはどこから出てくるのか。 分かりやすい Cons があると、反発が予想できて、その反発を解決するところまで労力を割くほどの気持ちが無いので困る。「直ちに問題になるわけじゃないが、どちらかというとやった方がいい、でもリスクもある」という選択肢を選べずにズルズルと現状維持に向かう圧力は、ある。チームの同質性が高いうちはほとんど困らないんだが、人数が増えたり、別の職種が増えたりするごとに「面倒」さはどうしても増していく。 我々の信念として以下を持ってはいるが、現状維持に向かう圧力がある中で変化を加えるのはそこそこ労力が要り、閾値を超えると変化が発生しなくなってしまう。 業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。 素早く変えてもし仮にダメだったら素早く
「ピープルウェア」を読んだ - $shibayu36->blog;
この前id:hitode909くんからピープルウェアを貰ったので読んだ。非常に面白くて、興味深い話が多かった。 ピープルウエア 第3版 作者:トム デマルコ；ティモシー リスター日経BPAmazon この本はソフトウェアのプロジェクトが失敗する時は、原因が単なる技術的問題だけである場合は少なく、その前段階の人とのコミュニケーションレベルにも問題があるときが多いという話をしている。それでプロジェクトを進める上での人に関する問題をテーマにしている。 最近は個人で作業をするというよりも、チームで仕事を進めるということが多くなりつつあるので、非常に参考になる事が多かった。印象に残った点を書いていく。 早くヤレとせかされると 早くヤレとせかされれば、雑な仕事をするだけで、質の高い仕事はしない 耳が痛い。でも自分自身が言われても直感的にはそうなりそうという感じだと思った。 またこの本の関連する内容に「
アクセルを踏むためのテストとブレーキを踏むためのテスト - yoshiori.github.io
Rebuild.fm#29 聴いてて少し語りたくなってるので書いてみる。 テスト考2014 – Hidden in Plain Sight から発してると認識してるんだけど新年早々テストについて盛り上がってますね！ で、個人的な意見を書くまえに、俺はテストどころかコンピュータサイエンスも学んだ事ない人間ですので色々見当違いな事言ってるかもしれないけど、エンジニアのスタートが組み込み系の QA エンジニアなので現場感覚はそれなりにあるつもりです。 で、早速なんだけど上記ブログから引用させてもらうと まぁ、なんにせよ、現在のウェブアプリ開発におけるテストなんて一歩間違えれば「ままごと」みたいなレベルだから、そんなに原理主義的になるのはダサいよねって話です。 id:kennejima に百パー同意で、ぶっちゃけちゃんと QA やった人間からすると境界値テストすらしてないしホワイトボックステストだ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
