12

だから私は問題があります。というか、友人が問題を抱えています。インターネット フォーラムで自分の会社について書くことは決してないからです。

私の友人の会社では、仕様書の作成は、言うなれば、少し十分に活用されていません。最初にコードを書き、後で質問するという文化が深く根付いています。それがライブラリ ルーチンであろうと、新しいツールであろうと、長い間苦しんでいた設計者に影響を与えます。

もちろん、これは機能が部分的に正しい、間違っている、または完全に欠落している状況につながります（「元に戻したいことを試す前に保存してください」）。これは通常、貧弱な設計者の生産性の低下、またはバグ修正に主に物事を正しく実装するのに費やされるベータ期間につながります。

私の友人は、仕様を書く (そしてそれに対してテストする) という彼の提案が一般的に好評であることに気づきました。彼の同僚のほとんどは、ベータ版の最中の日曜日の午後 11 時ではなく、紙の上で誤った仮定を発見する素晴らしい感覚を受け入れています。ビバ・ラ・レボリューション！

ただし、自分のタスクとキーボードの間にあるものをうんちする人もいます。彼らは実際に何かを設計するという考えを笑い飛ばし、楽しく自由にコードを書きます。ほとんどの場合、これらは「時間を無駄にする」ことに消極的で、長期にわたって雇用されている上級開発者です。

問題は、異端者のこの 2 番目のグループは、常に最初のものよりも早く何か (または少なくとも何か) を生成することです。その後、これは、「画像リサイザーのような単純なものの仕様を書くのは無意味です!幅!=高さまたは画像が RLE を使用するバグには、いくつかの調整が必要です」という行に沿って正当化されます。

そして今、質問:)

プロジェクトの終わりに「そう言った」と言う以外に、機能的または技術的な仕様を書く練習が長期的により良いソフトウェアにどのようにつながるかを示す良い短期的な方法は何ですか?

乾杯！

4

11 に答える 11

15

目標は、適切なソフトウェアを作成することです...仕様は、何が正しいかを見つけて定義するための 1 つのツールにすぎません。

グループとして、適切なものを構築する方法と、それを全員に伝える方法を決定する必要があると思います。

つまり、実際の問題に焦点を合わせ、それを解決する方法について共通の合意を得ます。「これが問題の解決策です。やってみましょう!」と言うよりも、多くの場合、全員から賛同を得ることはできません。また、仕様が問題を解決するのに適切ではない可能性もあります。

于 2009-02-23T22:36:48.630 に答える
10

仕様がカウボーイを打ち負かす1つの領域は、「スコープクリープ」とそれに関連するコストです。

仕様は、お客様と開発者の間の契約です。明確な契約がない場合、契約がいつ履行されたかをどのようにして知ることができますか？

また、詳細な仕様があると、2人以上の開発者がプロ​​ジェクトのさまざまな部分に同時に取り組むことが容易になります。そして、それはテスターに​​、いまいましいことが機能することを確認するときにソフトウェアを比較するための何かを提供します！

于 2009-02-23T22:50:02.577 に答える
5

オフィスの文化や仕事の習慣を変えるのは非常に難しいため、これはかなり難しいことです。ただし、これについて真剣に考えている場合は、仕様が小さなプロジェクト/モジュールに使用され、メンテナンスコスト (時間、バグなど) が時間の経過とともに定量化されるトライアルに経営陣に同意してもらうようにしてください。

この方法では他の開発者を味方につけることができないかもしれませんが、$$ のほうがより抽象的な開発手法よりも理解しやすいものです。うんちの管理者は、そのグループの継続的な雇用とパフォーマンスの評価に責任があるため、これは、彼らを変えたり、別の場所で働かせたりするよう説得する1つの方法です.

于 2009-02-23T22:32:40.747 に答える
3

あなたに力があるなら、他の誰かのルーチンについて質問があるときは、すべての開発者に元のコーダーに直接尋ねてもらいましょう。仕様やドキュメントが重要ではないとまだ信じている少数のコーダーは、「初心者の質問」にいつも答えるのに行き詰まっている場合は、何度か試してみる気があるかもしれません。

これはまさに私が数年前に大規模な開発会社で働いていたシナリオであり、人々はコードを大量に文書化する必要があるか、多くの小さな問題に対応するために「時間を無駄にする」リスクがあることをすぐに学びました。

もちろん、これはあなたがそれを試すのに十分な人々を得ることができる場合にのみ実現可能です:)

于 2009-02-23T22:40:59.557 に答える
1

2つのカルチャを2つの異なるグループに分割し、好みのパフォーマンスメトリックを考え出し、それらを緩く設定します。最高のグループが勝ちます。

または、彼の主張を科学的に証明する千の異なる定量的/定性的研究のいずれかを彼らに指摘します。

または、代わりに、すべてのカウボーイを解雇するか、または他の賢明な方法で、誰が迷惑をかけるかに関係なく、最小レベルの仕様の使用を義務付けます。プロジェクトの複雑さによっては、元の開発者のほとんどがなんらかの方法で離れるまで、仕様やドキュメントの欠如が実際にどれほど有害であるかを理解するだけかもしれません。

または、アプリケーションモジュールを純粋にアウトソーシングされたチームに下請け契約し、仕様とドキュメントの欠如がパフォーマンスと主要な指標を満たす能力にどれほど悪影響を与えるかを確認します。

または、製品の品質/コストなどについて顧客に尋ねます。

彼らの雇用契約が適切に設計され、施行されていれば、プロジェクトの最後に友人が開発者に「そう言った」と言って立ち往生することはなく、代わりにピンクの伝票を渡すことができます。

それに加えて、問題があることを知ったり、個人的な変更を加えたりするために、プロジェクトが終了するまで待つ必要はありません。

または、友人に辞めて、彼の好みに沿った開発方法と実践がある店に参加するようにアドバイスしてください。「たぶん、彼はちょうど間違った場所にいます。」

于 2009-02-24T01:37:04.050 に答える
1

仕様とは、何が行われたかを知ることです。何が行われているのかわからない場合、どうやって家に帰る時間を知ることができますか？

最も単純なケースでは、開発者は利害関係者と話し合って、彼らが何を望んでいるのかを感じ取っていますか？もしそうなら、彼らが決定するものは何でも「スペック」です。

それを白くして-それを実装して-そして家に帰りなさい。

于 2009-02-24T01:48:36.313 に答える
1

通常は時間がかかりますが、それが常に問題です。

編集：

あなた自身の会社、つまりあなたの友人の場合、何かを変更する必要があり、仕様が利用できないときはいつでも文書化する必要があります。仕様やドキュメントで時間を節約できる場合はいつでも、そのイベントを記録してください。費やされた時間の量を記録します (調査している人と、質問されたり、助けられたりした人 (存在する場合) の両方)。次に、仕様を実行しないことで最初に時間が「節約された」かどうかの費用対効果分析を行う必要があります。必要なときに持っていない価値がありました。

場合によっては、それを書くことで利益が得られる可能性がありますが、それが「必要」でない場合もあります。実際には、見返りが非常に大きくなる可能性があるため、最初にそれを行うのが常に最善です.

今 - 警告：

  • 気が進まない人もいるでしょう。まだ彼らを説得しようとしないでください。
  • 標準的に使用されるリポジトリが必要です。場所や方法は問題ではありませんが、見つけられるように一貫性があり、よく知られている必要があります。
  • それらは最新の状態に保ち、維持する必要があります
于 2009-02-23T22:38:40.920 に答える
1

チーム全員でスペックを書いていただけると助かると思います。一緒に時間をかけて、グループで物事について話し合ってください。私たちは通常、すべてのイテレーションの開始時にチーム全体でこのようなミーティングを行い、必要に応じて数人の開発者と詳細について話し合います。私の経験では、すべての詳細について説明する必要はありません。

于 2009-02-23T22:37:22.750 に答える
0

スペックに時間をかけすぎるのは時間の無駄です。私はかつて、1回限りのプロフェッショナルサービスアプリを販売、作成、出荷するプロジェクトに取り組みました。その後、上司は仕様の作成を要求しました。重要なのは、仕様の作成に時間がかかり、より多くの人員が必要であり、元のアプリよりもコストがかかるということです。元のアプリは二度と使用されることはありません。

アジャイル手法では、ドキュメントに夢中になって自分自身に負担をかけるべきではないと言っています。代わりに、要件を明確に描写し、定期的なコードレビューを行って、個々のチームと開発者に割り当てる必要があります。これは、有能なアーキテクトが参加している場合はうまく機能しますが、プロジェクトリーダーシップが、チームのさまざまな部分によって進められたさまざまなアプローチの相対的な技術的メリットを判断する資格がない場合、悲惨な結果になる可能性があります。

コードは自己文書化する必要があります。コード標準を順守する必要があります。要件を慎重に検討して列挙する必要があります。しかし、必要のないのは、すべてのモジュールのすべてのフリークインコード行で何が起こるかを説明する200ページのドキュメント、またはコード自体よりも詳細なコメントです。開発者はこのようなものを読むことができるはずです。それができない場合、あなたの問題は他の場所にあります。

于 2010-03-16T21:00:28.170 に答える
0

スペックは時間の無駄です。ソフトウェアを使用する人のほとんどは、自分が何を望んでいるのかを知ることはできませんが、自分が得たものが十分に良いかどうかはわかります。

同じ理由でプロトタイピングが機能することはめったにありません。この機能がまだ実行されていないか、まったく実行されないかを判断できないため、すべてが間違っていることを弾道的に伝え、実際に必要なときにすべてをやり直す必要があります。ちょっとだけ微調整します。または、リリースポイントまではすべて問題がなく、最終的に使用できないことに気付くと言われます。

設計するための最良の方法は、そこに行って、彼らがどのように物事を行っていたかを確認し、アプリケーションを彼らのワークフローに適合させようとすることです。すべてのチームメンバーがそれを行う必要があります。

要件を書き留めることができないと言っているわけではありませんが、実際のユーザーに要件を示すことには意味がありません。また、この機能だけで作業している場合は、すべての仕様を頭の中でうまく保持できます。

簡単に言うと、仕様を書かないで、ユーザーをスパイしてください。すべてのチームメンバーがそれを行うようにしてください。

于 2009-02-24T01:30:56.293 に答える
0

ただ、仕様が完璧で 100% 完成するまで何もできない極端な状況に行くのは避けなければならないと友人に伝えてください。そして、誰かが仕様に何か他のものを追加したため、コーディングは毎週遅れました。このアプローチには 2 ～ 3 か月かかる場合があり、その後、管理職レベルの誰かが非常に腹を立てて「どうでもいい、製品を完成させたいだけだ」と言って、状況は最悪になります。

フローをアジャイルに保つことで、両方の長所を活かすことができます (毎週のレビュー、早期配信、クイック ルックアップなど)。

于 2009-02-23T23:19:14.987 に答える