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