アカウント名:
パスワード:
(一切、邪魔されない) ドキュメント書く工数を入れてくれ。そもそも開発の途中でドキュメントと合わなくなってしまう現象があるなら当然工数の最後に「ドキュメント書き直し期間」が含まれてなきゃダメなんじゃないか?
結局、開発工数の中に溶けこまそうと無理させているんじゃないか。開発止めて、ドキュメント作りなおしてから開発再開ってところもあったけど、1度しか経験がない。大体「議事録にあったはず・・・」とか「イツイツそういう話が出てきた・・・」とかそんな話になってる。
ついでに。関係者と話していて、「あ。この話ブレそうだな」とか「相手が協力的な態度じゃないな」と思うとドキュメント書くの一気に萎えません? 私は萎えます。
最初にちゃんと仕様書を作り、手順まで含めてレビューしておかないから、時間が無くなるんだ。そもそも、なんでドキュメントが無いのにモノ作りが始まるのだ?先ずはそこから疑問として提示した方が良い。
>ついでに。>関係者と話していて、「あ。この話ブレそうだな」とか「相手が協力的な態度じゃないな」と思うと>ドキュメント書くの一気に萎えません? 私は萎えます。私はそういう時こそちゃんと事前にドキュメントの工数を入れ、検印を貰ってからでないと作成開始しませんが。そういう客はちゃんと言質を取って置かないと危ないったら無いですから。#下手すると「頼んでないからお金は出さない」とか言い出すかもよ?
>(#2082129)私だって怖いですよ。流石に、仕様書無い状態からってのはアレですが。(経験0と言えないのが嫌だ)乖離してるのは良くある話です。
>(#2082259)私が感じるのは、乖離が多いのは内設。 記載不足が多いのは外設。「あっち参照」「こっち参照」を避けるために、ベターと同じ内容書いて、直したつもりが記述コピーされていた別のドキュメントも・・・というパターンも割りと経験しているような。(先日恐ろしいことに、レイアウトが違うだけで内容は同一の内部設計が別ディレクトリの別ファイルで4つ存在していたというケースに遭遇したばかりです)外設の記載不足は、テストケース作成時に「あれ?」と気づくべきなのですが。テスト仕様書を充足させてしまって、外設に反映できていないパターンがあるのかないのか。ちと不安です。
----先日から始まったプロジェクトで、最後の2日間はドキュメント総点検デーと提案してみようかな。でもそのプロジェクトメンバー。 お客さんもガッチリしてるし。開発連中もドキュメント喜んで直すから乖離そうそう無いんだよなぁ。 ~_~;
責任うんぬんとは別ですね。そういうブレブレになっている場合は、仕様書や設計書に取り込まれずに、別に作られていたりするんですよ。
そう。「懸念事項確認一覧」とかね。しかも分かりにくい階層に放り込まれてたり。
それを、すぐにドキュメントに反映させられないのは、何故かって話です。懸念事項確認一覧なんて表をやめて、BTSに入れとくって人も居るでしょうし私の場合は、最後に総点検する時間が欲しいと思ってるわけです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
スケジュールの最後に、ドキュメント書く時間をくれ。 (スコア:4, 興味深い)
(一切、邪魔されない) ドキュメント書く工数を入れてくれ。
そもそも開発の途中でドキュメントと合わなくなってしまう現象があるなら
当然工数の最後に「ドキュメント書き直し期間」が含まれてなきゃダメなんじゃないか?
結局、開発工数の中に溶けこまそうと無理させているんじゃないか。
開発止めて、ドキュメント作りなおしてから開発再開ってところもあったけど、1度しか経験がない。
大体「議事録にあったはず・・・」とか「イツイツそういう話が出てきた・・・」とかそんな話になってる。
ついでに。
関係者と話していて、「あ。この話ブレそうだな」とか「相手が協力的な態度じゃないな」と思うと
ドキュメント書くの一気に萎えません? 私は萎えます。
==========================================
投稿処理前プレビュー確認後書込処理検証処理前反映可否確認処理後……
逆では? (スコア:1)
最初にちゃんと仕様書を作り、手順まで含めてレビューしておかないから、時間が無くなるんだ。
そもそも、なんでドキュメントが無いのにモノ作りが始まるのだ?
先ずはそこから疑問として提示した方が良い。
>ついでに。
>関係者と話していて、「あ。この話ブレそうだな」とか「相手が協力的な態度じゃないな」と思うと
>ドキュメント書くの一気に萎えません? 私は萎えます。
私はそういう時こそちゃんと事前にドキュメントの工数を入れ、検印を貰ってからでないと作成
開始しませんが。
そういう客はちゃんと言質を取って置かないと危ないったら無いですから。
#下手すると「頼んでないからお金は出さない」とか言い出すかもよ?
Re: (スコア:0)
っていうか、そもそも仕様書を修正して内容がコミットしてからの開発着手でないと恐くないですか?
ということでちょっと考えてみた。
ドキュメントとひとくくりにしてしまうからいけないんじゃないかなと。
開発工程別にドキュメントを考えましょうよ。
要件定義、基本設計、外部設計ここまでは必ず必須でしょ?
これがなければできあがったコードの妥当性を評価できませんよね。
逆に内
Re:逆では? (スコア:1)
>(#2082129)
私だって怖いですよ。
流石に、仕様書無い状態からってのはアレですが。(経験0と言えないのが嫌だ)
乖離してるのは良くある話です。
>(#2082259)
私が感じるのは、乖離が多いのは内設。 記載不足が多いのは外設。
「あっち参照」「こっち参照」を避けるために、ベターと同じ内容書いて、
直したつもりが記述コピーされていた別のドキュメントも・・・というパターンも割りと経験しているような。
(先日恐ろしいことに、レイアウトが違うだけで内容は同一の内部設計が別ディレクトリの別ファイルで4つ存在していたというケースに遭遇したばかりです)
外設の記載不足は、テストケース作成時に「あれ?」と気づくべきなのですが。
テスト仕様書を充足させてしまって、外設に反映できていないパターンがあるのかないのか。ちと不安です。
----
先日から始まったプロジェクトで、最後の2日間はドキュメント総点検デーと提案してみようかな。
でもそのプロジェクトメンバー。 お客さんもガッチリしてるし。
開発連中もドキュメント喜んで直すから乖離そうそう無いんだよなぁ。 ~_~;
==========================================
投稿処理前プレビュー確認後書込処理検証処理前反映可否確認処理後……
Re: (スコア:0)
>ドキュメント書くの一気に萎えません? 私は萎えます。
私の場合は逆にドキュメントをきっちり書いて、ドキュメントの通りで問題がないか念を押して確認したくなります。後で違うことを言われてもこちらの責任にならないように。
Re:スケジュールの最後に、ドキュメント書く時間をくれ。 (スコア:1)
責任うんぬんとは別ですね。
そういうブレブレになっている場合は、
仕様書や設計書に取り込まれずに、別に作られていたりするんですよ。
そう。「懸念事項確認一覧」とかね。
しかも分かりにくい階層に放り込まれてたり。
それを、すぐにドキュメントに反映させられないのは、何故かって話です。
懸念事項確認一覧なんて表をやめて、BTSに入れとくって人も居るでしょうし
私の場合は、最後に総点検する時間が欲しいと思ってるわけです。
==========================================
投稿処理前プレビュー確認後書込処理検証処理前反映可否確認処理後……