コンポーネントを統合する準備ができたら、どうすればチームに通知できますか？
私のチームは、組み込みコンポーネントとWindowsコンポーネントを備えたシステムを開発しています。現在、Windowsと組み込みプラットフォーム用に別々のリポジトリがあります。
チームの他のメンバーは、ユーザーストーリーの完全性について評価するために、現在のブランチステータスの十分な可視性がないことを懸念しています。目標は、テストのための最終的な統合をできるだけ早く実行することです。
この問題の解決策は、Windowsコードを組み込みリポジトリにロールインし、提供されるソフトウェア全体に対して単一のリポジトリを用意することです。これは必ずしも悪いことだとは思いませんが、ビルドプラン全体で物事を移植し、いじくるのに必要な作業に必要な価値を得るつもりでもありません。
私たちはスクラムチームを目指し、BambooやBitbucketと一緒にJIRAを運営しています。アジャイル哲学、スクラム手法、および既存のツールは、プロジェクト全体のプルリクエスト、ブランチ、ワークフローの進捗状況を監視するために必要なすべての情報を提供すると思います。
チームの問題を解決するために、私は常に行動ソリューションを好みます-それは長期的にはよりも少ないソフトウェアよりもコストがかかる傾向があります。私は朝起きて、その後の瞬間を使って実際に話し合うという考えをすぐに打ち破りましたが、それはあまり受け入れられませんでした...
ユーザーストーリーの成果物の統合の準備状況を伝えるために、チームはどの戦略を使用できますか？
新しいツールを追加したくない場合は、お持ちのものを使用してください。タスクの説明がほとんどのチケットツールで編集できるのが好きです。
タスク：54328-「扶養家族の数」スピナーがネガの許可を停止するようにします。
説明
スピナーは負の入力を防ぐことができません。ユーザーが[OK]をクリックする前に、これを禁止してください。
[x] Find relevant source code: TaxGUI.asp
[x] Correct behavior: added guard code to onclick method
[x] Tested and Peer reviewed: by CO2
[x] Pull request: issued against v1.1 bugfix branch
[ ] Integration: pending
付箋が貼られたボード（またはJiraボード）は、できるだけシンプルです。 ボードを垣間見ると、チームの進捗状況について十分な情報が得られるはずですそうでない場合は、ボードが間違っているため、修正する必要があります。
通常、実際の物理的なボードの方が優れています。理由は次のとおりです。
これまでに見たどのソフトウェアチケットツールよりも視覚的です。誤解しないでください。私は日常的にJiraを使用しており、楽しんで使用していますが、進行状況の視覚化に関しては、実際のボードの方が優れていることがわかります。
Any人はあなたのオフィススペースを物理的に通過するだけで、あなたの進捗状況を見ることができます。 PCを起動する必要はありません。Jiraのボードへのリンク（チーム外の全員のリンクの1つalwaysは失われます）を探し、認証などを行います。さらに、チームの物理的な場所にいること、物理的なボードが明確でない場合、その人は質問をすることさえあります。 「ねえ、昨日、ETLで使用されるインターフェイスの変更が完了したとおっしゃいました。では、なぜタスクが進行中なのですか？」
それでも、それが実際のボードであるか仮想ボードであるかは、チーム外の誰かが理解できるようにする必要があります。
現在の進捗状況、つまり：
このスプリント中に何をしたか、
今、何に取り組んでいますか、
このスプリントのためにあなたがまだしなければならないこと、
優先順位、
ブロックポイント（ブロックの理由がボードに表示されている場合はボーナスポイント）。
それらのポイントを伝えることができるだけでなく、正確に表示するもできる必要があります。特に仮想ボードを使用する場合によく発生するのは、チケットが大きくなり、大きくなり、大きくなることです。誰かが1つのチケットで5日間を簡単に処理できます。これは、定義上、進捗状況を視覚化することを不可能にします。もちろん、開発者に特定のタスクの進捗状況を尋ねることはできますが、答えは関係ありません（たとえば、90対90の法則を参照）。
すべてのタスクを十分に小さくしてください。タスクに2時間かかる場合、それは素晴らしいことです。 1日かかるとしたら、それは非常に大きな作業です。数日かかる場合は、ボードをチームの進捗状況に反映させるために、タスクを小さなタスクに分割する必要があります。
十分にきめ細かいタスクを作成すると、タスクの「統合の準備状況を伝達する」ことが簡単になります。タスクが完了したかどうかありません42 ％完了または85％完了。
いくつかの追加のアドバイス：
統合が苦痛である場合、それは通常、インターフェースが十分に注意深く設計されていないことを意味します。このレベルでの雑な作業は、両方のチームにとって数時間、数日、または数か月の無駄な時間をもたらします。チームと外の世界との間のインターフェースの設計に十分な時間を費やしてください。
インターフェイスの設計が難しい場合、または両方のチームがすでにコードのそれぞれの部分で作業を開始しているときに変更する必要がある場合は、他のチームと一緒に作業してください。ただ電話をするだけではいけません。彼らに会いに行くか、一緒に来て一緒に働くように誘ってください。メンバーが怠惰すぎてオフィスビルの反対側に行くことができないチームによって浪費された時間、日、月の数を数えるのをやめ、電子メールで通信することにしました。
これに対処するために必要なすべてのツールを持っていると思います。何かを追加または削除する必要はありません。チームが進捗状況の伝達に関する提案を認識しなかった場合、採用されたアプローチをチームが適切に認識できなかった可能性があります。さらに、チームがすでに統合に問題を抱えている場合、同じリポジトリに両方のツールを配置しても、それ以上の効果はありません。
あなたのチームは複数の人間で構成されています。人間はコミュニケーションなしにグループで生き残ることはできません。そのグループ間で共有されるビジョンについても同じことが言えます。
ここでのビジョンは、ユーザーストーリー、または完全性のためにスプリントに具現化されています。より大きなシステムの一部である、生成されるアーティファクトの各小さな部分は、システムと通信するためのコントラクト（またはインターフェース）を提供する必要があります。
再びグループの例で人間を取り上げると、相互作用したり、交渉したり、おやつに気づいたりするために、グループ間の共通言語を知らなければなりません。
その点では、これら2つのシステム間の契約に焦点を当てることで、チームが統合の平和を見つけるのに役立つと思います。これが私の提案です：
- 別の方法で提案を再定式化し、それについて質問します
- 組み込みシステムとWindowsコンポーネントの両方が変更後に常に展開される統合サーバーを用意します。このシステムから、ユーザーストーリーの準備ができているかどうかに関係なく、監視/検証します。
- 統合テストをユーザーストーリーのDoD（完了の定義）の一部にします。自動または手動のいずれかで、別のチームメンバーから機能したことの証明を提供する必要があります。これにより、うまく統合されたピースが報われるポイントシステムを統合することができます