がんばるあなたがプロジェクトを殺す - haradakiro's blog
あまりに暑いのでちょっと怪談を。 今のような仕事のやり方をする前、いわゆるシステムインテグレータに所属していた。まあ、呼び方はいろいろあるのだろうけれど、一番長いこと仕事にしていたのは、いわゆる「火消し」。問題プロジェクトにがあると、プロジェクトに投入されるという役どころだ。まあ投げ込まれるのは大変だけれど、いろいろなものを見ることができた。 投入されたプロジェクトは多種多様だけれど、たいていの場合、すぐに問題があるようには見えない。みんな忙しそうに働いているし、大きな開発プロセスの問題もない。粛々と作業がすすんでいるように見える。でも、クライアントと管理職は怒っている。怒っているから、いろいろな作業が追加されて、メンバーはどんどん忙しくなる。 しばらく見ていると、プロジェクトには必ずある種類の人がいることに気がつく。みんなに頼りにされていて、なにかあると彼(彼女の場合もあるよ、もちろん)
アジャイルがそんなにダメだと思わない7つの理由 - haradakiro's blog
鈴木雄介さんが、「アジャイルがダメだと思う7つの理由」というすごいブログを書いてくれたので、がんばって返答を書いてみる。どこかでディスカッションできるといいなぁ。 1. 全体スケジュールにコミットできない コミットメントって何だろう。コミットメントは約束なのか。約束であったら、破った場合のペナルティも受け入れるのか？受け入れたところでバッファが巨大になるだけではないのか？そして、そのバッファは見えないところで食い尽くされる。 全体を見えずに計画したところでうまくいくはずはない。アジャイルがタイムボックスで計画、実施を行うからといって、全体を計画しないわけではない。むしろ積極的にやるべきである。 全体を計画する上では、なるべく漏れがないように、実施可能なように最大限の努力をする。ただ、それに時間を掛けすぎるのは無駄だ。そして、神ならぬ人間が計画するのであるから、以下を認めなければならない。
Scrum ではコードレビューをどうやっているか？ - haradakiro's blog
森崎先生のソフトウェアレビューの講演を聴いて、今やっているレビューの方法をまとめときたいと思ったので、まとめてみます。今回は、コードレビューの話です。Scrum ではといっていますが、レビューのやり方はチームによって違うので、あくまでも例ですよ。PBI とか、仕様、ドメインモデルのレビューの話はまたこんど。 レビューの目的は、もちろん作成するプロダクトの品質向上です。障害を検出するのも、もちろん目的ではあるのですが、それ以降のスプリントで作成されるコードで同じ障害を作り込まないのが目的としては大きいです。そのため、レビューはプロジェクトもしくはチーム立ち上げ後、数スプリントで重点的にやります。後はスプリントの振り返りでレビューをやりたいが出てきたら、チームで決めます。 レビューのやり方 基本はチーム全員で集まってやります。最大２時間。それ以上やっても集中力が続かないので。プロジェクタで対象
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
