作業中のルール - ページ 5

新しいコメント
 
Yedelkin:
ここでは、最後に別のアプローチで問題を解決しています :)
バザーはありません。)))
 
pronych:

ソースは、余分な機能やクラスなどがたくさんある、よく設計されたテンプレートにすることができます。ブロックの束（inludesなど）で構成され、その中の一部の条件だけが変化することがあります。シグナルモジュール（1つのクラス（ファイル））だけが異なる1つのシステム（相互作用という意味でのシステム）の12個の異なるファイルのソースコードに、（単純なケースで）6ヶ月を費やす覚悟はあるか？

標準ツールでマスクのクラッシュができるのは理解できますし、残念でなりません。しかし、テンプレートに膨大な労力が投入されるのであれば、どうすればいいのでしょうか。いいえ、準備はいいですか？

このような場合、テンプレートはコンパイル済みのファイルとして提供し、シグナルモジュールはお客様の判断で提供した方が良いことがわかりました。そのような選択肢（すでに言われていることですが）は、誰にでも通用するのでしょうか？

...しかし、その場合、「新築」のリスクは施主に移り、そのリスクを排除する保証は請負業者の良心に委ねられることになる。

 
Yedelkin:

ここには根本的な間違いがある。契約とは、2人以上の当事者間で交わされる合意です。申込書は、あくまでも一方の当事者からの提案であり、それ自体では契約と見なすことはできません。審議中のルールの本質を踏まえれば、契約関係の成立（契約の締結）は、Terms of Referenceが作成された後でなければ判断できないことになります。この委託契約は、両者が 合意した業務の詳細をすべて反映することを意図しています。


私は、我々の場合、申請書が契約書であると主張したのではなく、それに近いものであるべきであり（つまり、私の意見では、申請書にはいくつかの必須項目／チェック項目が含まれるべきである）、ToRは業務の詳細を開示し、契約者が遵守すべき特定のポイントを定義すべきであるという希望を述べただけである。

とはいえ、ノンプログラマーのトレーダーの少なくとも6割は、ToRの半分を無視するのではないでしょうか。

 
Interesting:

私たちの場合、アプリケーションが契約であることを主張したわけではないのですが・・・。

面白いですね。

... 私は、通常であれば、契約（アプリケーションを読む）は...

例によって、ハイライトさ れた部分についてコメントしています :)
 
Interesting:

とはいえ、ノンプログラマーのトレーダーの少なくとも6割は、ToRの半分を無視するのではないでしょうか。

だからこそ、私は、（具体的なルールを踏まえて）ToRを作成する際には、請負業者が主体的に業務の詳細を調整し、文書に反映させることを主張し、今もその主張を続けています。クライアントの苦情に対応しなければならないのは、契約者である。契約 者に非があるようなToRの作成は、不必要な紛争を引き起こすだけである。
 
Yedelkin:
このような場合、テンプレートはコンパイル済みのファイルで渡し、シグナルモジュールはお客様の判断で作成した方が良いことがわかりました。この選択肢（既出）は、誰にでも通用するのでしょうか？
なかなか、みんなに)) しかし、もちろん、それも選択肢の一つではありますが...。私としては、既成のファイルが1つある方が便利なんです。これはタスクを複雑にする（-「コスト」と読む） しかし、話はそれについてでさえない。 このようなアプローチはアイデアを分割し、顧客はそのようなことに鋭い（または鋭い！彼らは異なるかもしれない）、馬鹿ではないが )) 。私は、「ソースが欲しい」というチェックボックスで十分だと思いますし、規約の合意以前に、ほとんどの問題を解決するだけです。この問題で理解されるなら、あなたは仕事の議論を続けることができます。そしてそこに、草が成長し、全く別のステージ。
 
pronych:
全員に、とはいきませんが)) しかし、選択肢のひとつであることは確かです...。私にとっては、1つのファイルを用意しておく方が便利なんです。これはタスクを複雑にする（-「コスト」と読む） しかし、話はそれについてでさえない。 このようなアプローチはアイデアを分割し、顧客はそのようなことに鋭い（または鋭い！彼らは異なるかもしれない）、馬鹿ではないが )) 。私は、「ソースが欲しい」というチェックボックスで十分だと思いますし、規約の合意以前に、ほとんどの問題を解決するだけです。この問題で理解されるのであれば、仕事の話を続けることができます。

では、どうするのか？問題を解決するための実行可能なオプションは、次のようになります。

1.フォーマルな面では、ルールに新しい条項が 加わったこと。

2.技術的な面では、アプリケーションのフォームで、デフォルトの "Not required" と "Source code required" のオプションを導入することは可能でしょうか？

 
Yedelkin:
だから私は、（具体的なルールに照らして）ToRを作成する際には、コントラクターが主体的に仕事の内容を調整し、文書に反映させることが必要だと主張してきたし、今も主張しているのだ。クライアントの苦情に対応しなければならないのは、契約者である。契約 者の過失によって不器用に作成された要求仕様書は、不必要な紛争を助長するだけである。

そうですね。ありそうですね。では、「作品」にどんな追加をお願いするか、一気に（開発者が寝ている間に、静かに）考えてみましょうか。でも、私が先よ！

箱をチェック!'Sources'（情報源）。

:))

 
Yedelkin:

では、どうするのか？問題を解決するための実行可能なオプションは、次のようになります。

1.フォーマルな面では、ルールズに新しい条項が 追加されました。

2.技術的な面では、アプリケーションフォームに「ソースコードが必要」というオプションを導入し、デフォルトを「必要なし」にしてみてはいかがでしょうか。

コレクト
 

私の考えでは、もう一つ別の方法があります。請負業者と顧客の間に調停者-仲裁者（私たちの場合はMQ）がいて、請負業者は材料＋ソースのパッケージ全体を調停者に渡し（調停者はTORと照合）、その後、顧客は調停者から仕事が完了した旨の通知を受け取り、代金を支払う必要があります。

仕事の独占性と支払い後の最初の取り決めにより、クライアントは最大限のオープンソースコードまたはコンパイルされたファイルのみを受け取ります。

この場合、仲介者は一定の報酬を受け取ることはご承知の通りです。

追記

MQはあまり好きではないようですが...。

123456789101112...20
新しいコメント