深い業務知識が必要なのは案件の提案者と要件定義者 - ひがやすを技術ブログ
SIerが必要としているのは業務知識だという都市伝説のエントリで、誤解されたのは、「SIerは深い業務知識が不要だ」というふうに私が主張していると思われたことですね。 誤解されるのは、もちろん、私の書き方が悪かったせいなので、続きを書きます。 SIerで深い業務知識が必要とされる人がいます。案件の提案者と要件定義者です。営業がお客様のところから案件を持ってくると、その案件に関する深い業務知識を持っている人がアサインされ、提案書と見積りを作ります。この役割の人は、深い業務知識が必要です。 無事に案件が獲得できたとしましょう。お客様のところにいって要件をつめるのですが、このときのメンバも深い業務知識が必要です。しかし、全員が深い業務知識を持っていなくても大丈夫。全体の半分弱くらいのメンバが深い業務知識を持っていれば大丈夫だと思います。案件の難易度にもよりますが、一人が業務を深く理解していれば大
「ふりかえり」が失敗する８つの理由：An Agile Way：オルタナティブ・ブログ
「アジャイルレトロスペクティブ」の著者、イースターダービーのStickymindsの短い記事です。 「ふりかえり」が失敗する８つの理由 Eight Reasons Retrospectives Fail ぼくは Retrospectives を「ふりかえり」、と訳している。オブジェクト倶楽部のプロジェクトファシリテーションのページに、天野さんが、日本語の「ふりかえりガイド」(PDF)もかいている。 簡単にまとめると、 「ふりかえり」が失敗する８つの理由 １．準備不足。 ⇒アジェンダをしっかり用意すること。 ２．焦点があいまい。 ⇒前回のイテレーションの改善に集中。 ３．データが集まっていない。 ⇒何かを変えようとするまえに、「実際に何が起きていたか」を話す。 ４．１人か２人が会議全体の会話を独占してしまう。 ⇒ペアにしたり、グループを作ったりして話あうアクティビティを持つ。 ５．自分たちで
ペアプログラミングってどうなの？
XPやアジャイルといった方法論によって有名になった「ペア・プログラミング」というものがある。その名の通り、二人でプログラミングを行うこと。これに僕は、ちょっと抵抗感がある。 まず、「ペアプログラミングは限定的なタイミングで威力を発揮する」と思っている。そもそもXPは「火消しのための方法論」をプロジェクト全体に適用しようと試みられた方法論である。僕はXPの流行前後の時期はまさに「ファイアーマン（火をつける人じゃなく消す人！）」だったため、特にXPに関しては興味を深く持った。例えば「不具合対応」という比較的細かな問題解決に対して、すでに大きなコードセットに立ち向かうためには、自分の知識だけでは足りない。つまり、コードセットの中で自分の知らない箇所や全体感などを把握している他人と共に「ここでもない、あそこでもない」とやり取りしながらコードを修正していくことは、バグ潰しという暗い作業を明るくしてく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
