今回初めてなのだが、納品物がソースのみで
ドキュメントを含まない。
ここらへんは顧客側もスピードを優先させたいらしく
きちんとしたソースを提供できればＯＫになっている。
期間も短いし、工程の概念も無い（顧客側）し、
オンサイト顧客（オンサイトデベロッパ？）なので
アジャイルっぽくやろうかなと考えている。
で、ふと悩んだのがドキュメントって何が必要なのかだ。
メンバーがMAX３人程度とかなり小規模なので
コミュニケーションはとりやすいと思うので
そこそこのものがあればよさげな気がする。
今、作成＆必要だと考えているのは
・スケジュール
・画面遷移図
・モックアップ（ドキュメントじゃないけど）
・ＥＲ図
・ＤＢ設計書（テーブルの列とか書いてるやつ）
ってな感じ。
スケジュールは今回はじめての導入となるが
ストーリーカードをバーンダウンチャートで
管理しようかなと。
画面遷移図についてはモックアップとかぶるけど
全体を見渡せるのでやっぱ欲しいな。
ＤＢに関してはとりあえずこの２つあれば
開発には問題ないと思う。
実際納品ドキュメントが決まっていないアジャイル開発で
どんなドキュメントを作っているかすごく知りたい。
まさかゼロって事はないですよね？
プラス「ユースケース記述」「シーケンス図」があると比較的実装＆保守が楽です。あとは要件定義書／一覧表かな。
コメントありがとうございます。
「ユースケース記述」は必要ですね。
「シーケンス図」は代表的なものだけ書くかな。工数的に全部は厳しいな。
やっぱりドキュメントはいろいろ必要になってきますね。
しかし「自分が必要なもの」と認識して作るので「書くだけで読まれない設計書」より品質が高くなりますね。
もうちょっと補足すると、ドキュメントは
– 作成時に必須かどうか（ないと始められないドキュメント）
– 誰かに説明＆保守に必須かどうか（形式知として残しておくドキュメント）
に分かれるわけで、それぞれ必要な時期が異なるんですよね。
ユースケース記述は、前提条件／結果／内容を箇条書きにするに留め、
例外処理は随時付け足す。
シーケンス図は、主要な部分に留め、細かい例外は省く。
ただし、保守に必要であればプロジェクト終了時に補足していく。
とすると結構手間が省けるし、時間＆予算がなくなっても
主要な部分のドキュメントだけが残ります。
「ドキュメント」とひと括りにするとごっちゃになりやすいので、
– 設計書
– 操作マニュアル、保守マニュアル
と分けると考え易いと思います。
そうですね。開発の為に必要なものと稼動後に為に必要なドキュメントはべつ物ですね。
私が必要としていたのは開発の為のものでそこら辺がきっちりしていませんでしたね。
t.masudaさんのおかげですっきりしました。
個人的な意見で恐縮ですが。。。
何故ドキュメント化するのかはプロジェクトの規模や企業の特性によって変化するため、理由をひとつに定めることはできないような気がします。
しかし、以下のことは言えるのではないでしょうか？
・何故その処理になったかコードだけでは説明できない場合、説明するドキュメントが必要。
・自分が作成したものも数ヵ月後には忘れているため、形式知として残す必要がある。
・共通のルールを設け、明文化することでコミュニケーションが円滑になる。
すべての処理に対してシーケンス図を用意する必要はないと思います。
これがないと困ると思ったらドキュメントを作成する時かもしれませんね。
個人的な意見大歓迎です。
確かにプロジェクトによって必要なドキュメント、不必要なドキュメントは違いますね。
「これがないと困る」の時期も確かに良い指針かもしれません
またご指摘下さった３つのルールも参考にさせて頂きます。
momoさんコメントありがとうございました。