A3用紙1枚に、簡潔に。 - Feel Like A Fallinstar
大人数だったり長期の開発プロジェクトでは、要件やエラー、出戻り等が複雑に絡み合い事情を把握しにくくなります。 そのため、ある開発領域やフェーズ単位で簡潔に情報をまとめないといけません。 しかも1枚で。 人間、みんながそうそう何枚も何枚も親切に資料なんぞ見てくれるわけではありません。 もう、何度失敗をしたことか！（汗 と、いうわけでそんなA3レポートを作るためのポイントが載っていたので頭の整理をかねてメモメモ、と。 （※出典：リーン開発の本質） A3用紙1枚レポートの作り方のポイント ※内はいまきのコメント できるだけ語数を減らす（※当たり前と思うでしょうが、心掛けて文章を書くと随分と影響します） 図やグラフを多用する。百聞は一見に如かず、ですね。 レポートはあくまで動的なドキュメントであり、利用後のフィードバックに応じてアップデートできるように。 A3のサイズが合わないなら、A4にしよう！
プロジェクトで要件変更の発生を避けるには
ほとんどのプロジェクトでは、「要件のクリープ（確定したはずの要件の変更）」が発生する。クリープは、予算やスケジュールの超過を招く大きな原因であり、これらの問題はストレスやミスにつながるほか、評判を傷つけてしまう。では、どうすれば要件のクリープとその影響を避けられるのか。 数十年にわたって要件定義が重要視されてきたにもかかわらず、クリープは依然としてプロジェクトトラブルのもととなっている。「システム分析」「構造化分析」「オブジェクト指向分析」「ビジネス分析」など、呼び名が何であれ、こうした「要件」分析手法は、要件定義を多少改善させただけであり、要件のクリープを大幅に減らすには至っていない。 クリープが相変わらず発生しているのは、こうした従来のアプローチでは、わたしが「本当の」ビジネス要件と呼んでいる重要な要素が見落とされているからだ。おなじみの例を見てみよう。 ATMの例 要件について講演し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ちょっとした構成案を作れば、あなたのドキュメントはもっとわかりやすくなる！
システム構築企画や要求仕様のまとめ方
