0

ビジネスロジックの量とコンポーネントの量の点で、私は非常に複雑なプロジェクトに取り組んでいます。

各開発者は、主に「自分の」コンポーネントで作業します。これが機能横断的ではないことは理解していますが、すべてのコンポーネントの詳細を知ることは不可能です。

チーム sostav は随時変更されます。そのため、ある人が「他の人のコンポーネント」に取り組まなければならない状況があります。そして、これは定期的な地下室にある可能性があるため、1 か月後に問題に戻ることができます。その瞬間に、コンポーネントのビジネス ロジックの所有者に同じ質問を何度も聞くことができます。後で。

この状況は時々迷惑です。

私たちは毎日スタンドアップ ミーティングを行っており、その人が自分が何をしたか、何をしようとしているのかを話します。プロジェクトのwiki FAQページがあります - 最もよく寄せられる質問を抽出します。

この問題についてどう思いますか。

また、どのように解決することをお勧めしますか?

4

1 に答える 1

3

私が行くコンポーネントの性質を考えると：

1.) アプリケーションの目的、セットアップ、要件などを指定するフレームワーク ドキュメント。 2.) 各コンポーネントのモジュール ドキュメント。共通の形式で、名前で索引付けされています。

一般的なドキュメントの良い例についてはhttp://docs.python.orgを、モジュール/コンポーネント ドキュメントの良い例についてはhttp://docs.python.org/modindex.htmlを見てください。

ああ、毎日の会議は一般的に悪いものです。多くの時間がかかり、答えが忘れられてしまいます。新参者や病気の人はミーティングに参加できず、再度説明を受ける必要があります。話し合いやフィードバックが必要な場合を除き、すべてを書き留めて紙やメールで記録しておく方が 100 倍優れています。

于 2009-05-19T11:52:29.140 に答える