あなたとあなたのチームが日々取り組んでいることをどのように追跡しますか？

私は自分自身とチームの人々が実際に毎日何をしているかを追跡する方法に苦労しています。完成したカードを毎週調べることで良い全体像が得られ、スタンドアップは少し助けになりますが、チームの日々の仕事をうまく扱えないと感じています。カードは毎日のスタンドアップで更新されることなく何日間も進行し続けます。一部のエンジニアは、私のチームは最もコミュニケーションが取れていません。

メーリングリストまたは共有のgoogleドキュメントを介してすべての人が記入する何らかの日次記録を実装することを考えましたが、これはかなり面倒で手作業のようです。

GitHubアクティビティを監視することは問題ありませんが、毎日送信する電子メールの数に少し圧倒される場合があります。私はそれのためにダイジェストシステムを構築しようと考えましたが、余裕がある時間はありません。

「進行中」のタスクの作業を測定できるように、チームが毎日行っていることを常に把握するためにどのような戦略を実施しましたか？

私は彼らに話します。

技術は社会問題を解決できません。朝の短い立ち上がりがあります。昨日は何をしましたか？今日は何をしますか？障害はありますか？

何かが怪しい（または興味がある）場合、私は立ち止まって質問します：「あなたは昨日XYZに取り組んでいましたが、どうでしたか？」これにより、人々は注意を払い、何が起こっているのかを実際に知るようになります。また、チームをループでリードし続けます（そして注意を払い、実際に何が起こっているかを把握します）。これは時間どおりに短くする必要があります（最大 10分）。他のことや人々は仕事を「棚上げ」しません。彼らは立ち止まって立ち上がりを待ってから、時間をかけて再び始めます。とにかくそれを行う人もいますが、それはほとんど避けられません。

それから午後、みんなの机に立ち寄る。毎日の午後ではなく（新しい人にとっては毎日の午後よりも多いかもしれませんが）、同時にではなく、ほぼ同じ時間です（非公式であり、定期的です）。「問題はありますか？障害はありませんか？」

人が1対1でいるときに問題に遭遇する頻度に驚かれることでしょう。

人々に問題がなければ、素晴らしい。仕事に戻る。彼らは一週間問題がない場合は？問題。あなたは彼らに十分に挑戦していないか、彼らは開かれていません。XYZ（彼らがスタンドアップで言及した）がどのように進んでいるかを尋ねます。彼らに物事を説明させます。

これは微細管理ではありません。あなたは彼らに彼らの仕事をする方法を教えていません。あなたはそれらをベビーシッターではありません。あなたは彼らの日々の生活から障害を取り除くためにそこにいます。そのためには情報が必要です。チームを会議から遠ざけ、プロジェクトマネージャーをキューブから遠ざける限り、1人が1日1回助けてくれるだけで悲しむことはありません。しかし、これらすべての相互作用は、「私はあなたを助けるためにここにいる」という脈から来る必要があります。

私がするもう一つのことは、チェンジセットをレビューすることです（自分で、非公式に）。その後、人々がチェックインする頻度、変更セットの大きさ、報告されたものと一致する頻度、やり直しの頻度、バグ修正の数などを確認できます。ステータスを「完了」に変更するワークアイテムはほとんど意味がありません。コードを見てください。完了したように見えますか？

注：非常に深刻な副次的なポイント：チームの大きさは？7人以上ですか？もちろん、チームが大きすぎる場合は、進行中のすべてを追跡することはできません。

開発者をマイクロ管理しないでください！

生産的なソフトウェア開発には、集中的な精神的努力が長時間必要です。それらが一定の出力を生成することを期待するのは現実的ではありません。日常的に測定を開始すると、彼らは仕事を再構築して、常に目に見えるアーティファクトを生成し、毎日見ることができるようにします。これは、ソフトウェアの品質にプラスの影響を与える場合と与えない場合があります。ほとんど間違いなく、開発者の効率に悪影響を及ぼします。

ロバート・ハーヴェイが示唆、マイクロあなたのチームを管理していません。具体的なビジネス価値を持つ優先順位付けされたタスクをチームに提供し、このビジネス価値を実現する最適な方法をチームが把握できるようにします。

チームがビジネス価値を提供する場合、あなたは幸せになるはずです。要求された機能を確実に提供する方法については、彼ら次第です。

しかしながら：

カードは、毎日のスタンドアップで更新することなく、何日間も継続して進行します

これは、プロセスに欠陥があることを示している可能性があります。

チームとして実際に機能しておらず、立ち往生しているときにお互いに助け合うために介入していないチームである可能性があります。それはまた、ビジネスとのコミュニケーションかもしれません。タスクが大きすぎるため、必要なものを把握することが困難になります。仕様は明確ではありません。

また、実際の問題がまったくないこともあります。チームは、完了までに数日かかる主要な作業を表すカードでうまく機能している可能性があり、チームはこれを達成するために正常に機能している可能性があります。

あなたの懸念を表現するためのプラットフォームとして回顧展を使用することは有効だと思います。時々、外部から観測を受け取ることは良いことです。

しかし、問題があるかどうか、そしてその原因は何かをチームに把握させてください。そして、おそらくタスクがチームに配信される方法を調整する必要があることを受け入れる準備ができています。

毎日の立ち上がりは、チームが作業を整理するためのツールであることに注意してください。チームが何をしているかを管理者が追跡するためのツールではありません。

「プッシュメッセージング」ではなく「プッシュメッセージング」

開発者は、多くの場合、あなたにとって重要な次のいずれかの状態になります。

1. うん、Xしたよ！
2. 私はXに取り組んでいますが、時間がかかるようです...
3. 私は問題Yで立ち往生しています。それを調査していますが、アドバイスが必要かもしれません。
4. A、B、Cを待っているため、ブロックされています。

理想的には、実際の生産性を損なうことなく、これらのステータスに関する合理的に最新の情報を取得する必要があります。定数「まだそこにいますか？」非生産的ですが、状態2〜4で何か便利なことができる可能性があるため、通知する必要があります。

動作するのは、「プッシュメッセージング」の文化であり、できれば自動化された方法です。コミットログ全体を見る必要はないかもしれませんが、すべてのチームメンバーの最新のコミットまたは最新の解決済みチケット（バグまたは機能）を表示する「ダッシュボード」を作成できます。残りの状況では、そのような更新を積極的に電子メールで送信するか（コミットよりもまれであることが望ましい）、ダッシュボードに継続的な進捗が表示されない場合は、それらに移動して尋ねることができます-立ち往生する必要があるという内部合意（8時間ではなく80時間かかることが判明した場合、一部の機能は不要である可能性があります）、その後、最新の状態を維持するか、ユーザーに煩わされます。

または、https：//idonethis.com/のような文化を作成して、チーム全体に日報を送信することもできます。これにより、他の人も同じページに表示されるようになります。

他のいくつかの回答（コミュニケーションに焦点を当てたもの）に代わる方法は、おそらくノートカードのタスクを小さな断片に分割して、より早くフィードバックできるようにすることです。

小さいピースを使用すると、チームは毎日何かを達成しているように感じます。

欠点は、これらの個別のカードが相互に多くを依存する可能性が高いことです。ここでは、互いに非常に簡単に通信できるチームが有益です。そうでないと、ピースが本来のように結合されない場合があります。また、特定のことを最初に行う必要がある場合は、いくつかのカードを保持する必要があります。

そうは言っても、人々はいまだに立ち往生するか、タスクが時々予想されるよりもはるかに困難です。だから、問題を抱えている人を判断せずに他の人がアドバイスを提供できるスタンドアップで問題をオープンに議論することが依然として役立つのはこのためです。

他のいくつかの答えがもたらしたように、マイクロ管理の問題に答えるには、人々は毎日小さなタスクを達成しますが、各人が実際にどれだけ達成されているかを理解するには、達成された仕事のより広い視野を取りますが、毎日の成果によって判断するのではなく。

これは、コミュニケーションが非常に簡単で、人々が非常に親しみやすい8人のチームで働いているためです。2日間以上の作業にかかることは決してないタスクが与えられます。これらのタスクは密接に関連している場合があり、それぞれが自分の作品をどのように処理するかについて、互いに最新の状態に保つ必要があります。私たちはそれぞれ、2週間ごとに達成したことをマネージャーに報告する責任があります。

質問をもう一度読んだ後、リーダーとしてではなくチームメンバーとしてこれを求めている可能性があることを理解しているため、タスクを制御できない可能性があります。

1. リーダーにタスクをさらに分割するよう提案することができます
2. 作業がブロックされたり、他のチームメンバーの作業に依存している場合は、チームメンバーに確認して、必要に応じて別のタスクを実行してください。

まず、時間とスキルの観点から自分自身を分析する必要があります。あなたが以前に実際の経験を積んだ技術者である場合、あなたがただ締め切りが守られていることを確認する必要があるだけのマネージャー（開発者が実際に取り組んでいるものに関する強力な技術的知識を持たない）の場合とは異なるかもしれません。

共通点の両方のケースでは、あなたのチームを促進し、あなたがそれらを信頼感を作成できるようにする必要があるということです。あなたは彼らのパフォーマンスを判断しているのではなく、彼らの経験を楽しく簡単にするために共感的で助けになろうとしています。

さて、あなたが上で言ったようにただのマネージャーであると仮定してください。その場合、開発者が深刻な開発関連の問題に本当に直面していても、あなたは彼女/彼を助けることができないかもしれません。実際の問題は時間がかかり、集中力も必要です。さらに、開発者が本当に自分の仕事に誠実であり、その問題を解決するためにフルタイム（余分な時間も）を払っていると仮定しますが、残念ながらまだ解決できません。そして、そのような状況（あなたが問題を完全に理解することすらできない場合）では、毎日、そして1日2回非公式に進捗状況を把握することで、問題について質問し続けます。その結果、開発者にとっては非常にフラストレーションと混乱が生じます。毎日の進捗状況を収集するアプリでも、毎日のスタンドアップミーティングでも、どちらもイライラすることがあります。

一方、他のすべての要素を同じに保つには、あなたが強力な技術的背景を持ち、過去に同じ技術に取り組んだことを想定してください。この場合、毎日の進捗状況を確認したり、スタンドアップミーティングを行うことは非常に役立ちます。開発者はあなたとあなたの専門知識を確実に信頼し、彼らが直面している大きな課題について議論することに安心するでしょう。あなたは役に立つかもしれないいくつかの提案を提供します、または彼らがいくつかの代替アプローチを提供するのに役立つ彼らが直接役に立たない場合でさえ。

ただし、どのような場合でも、毎日のスタンドアップミーティングは、ヘッド/リード/マネージャーではなく、チームメンバーであるという感覚を作り出す必要があります。彼らがそうであるように、あなたのチームメンバーが同じレベルであなたを検討していない限り、彼らは、などの懸念/提案/問題/フィードバックを通信することができません
考慮すべきもう一つのポイントを自動化された進行状況追跡ソフトウェアの使用や対話の増加を考える前に、チームの規模とそれらを管理する時間です。チームから懸念が提起された場合は、できるだけ早く解決できるようにする必要があります。チームメンバーの主な動機付けの要因は、彼らの懸念/提案/フィードバックが真剣に受け止められない、または評価されないことです。毎日の進捗状況を知ることは重要ですが、チームワークに完全に関与している場合のみです。いくつかの副業にも関わっている場合は、チームともっと交流しようとしないでください。チームの対応が圧倒的であり、チームが時間前にタスクを送信し、懸念や質問を提起しているが、タイムリーなフィードバックやレビューを提供できない状況を考えてください。そのような状況では、

さまざまな構成に合わせて、さまざまなIMチャットルームを作成して活用します。@engineersのように幅広いものもあれば、@ newFeatureAのように特定のものもあります

毎日のスタンドアップに、機内チケットのレビューを含めることを検討してください。

コラボレーションをサポートするオープンな環境を使用し、QEと主な製品所有者が開発者の真ん中にいることを確認してください。あなたは多くのことを聞き、あなたの周りの画面を見ることからアイデアを得ます。

ロバートが指摘するように、何よりもマイクロ管理とは見なされません（「見られる」、つまり実際の意図に関係なく）。

最終的には、時間の経過とともに何が達成されるかを追跡し、その速度がどの程度であるかを確認します。人々がやる気を失い、去るので、日中の進歩に焦点を合わせるのは逆効果です。

GitHubやBitBucketのようなシステムに組み込まれた「フォロー」または「スター付き」のリポジトリメッセージングについて、まだ誰も言及していないことに驚いています。

技術的な利害関係者（プロジェクトリーダー、開発およびサポートマネージャー）はすべて、私たちの問題をフォローし、関連するプロジェクトの更新履歴をコミットします。私たちには小さなチーム（15人のFTE +請負業者）がいますが、これは私たちにとってはうまくいくようです

これらのことについては誰も測定されませんが、PMからの毎週のステータスレポートに加えて、これによりプロジェクトの日常的なビューが提供され、少なくとも作業中の領域を誰もが把握できるため、誰も可視性を失うことはありません。

また、開発者と請負業者の透明性を高め、ビジネスの連絡窓口を提供して、全員が成果物のスケジュールを説明できるようにしました。

特定のリポジトリまたは組織全体に関連付けられたRSSフィードと組み合わせると、（必要に応じて）メールを制限し、RSSリーダーを介して同様のデータセットをリアルタイムでまとめて提供できます。一部のユーザーにとってこれはOutlookであるため、基本的にはわずかに異なりますが、電子メールですが、他のユーザーにとっては、必要に応じてカスタマイズするために必要なすべての追加フィルタリングを備えた本格的なRSSクライアントを使用します。

最初は電子メールの量について同様の懸念に遭遇しましたが、エンドユーザーはRSSシステムを思いつきました。Outlookを使用していない人のためにクライアントを提案する以外にエンジニアリング組織が多くのことをする必要はありません。複数のオフィスとタイムゾーンにまたがって年間を通じて約20〜30人のFTE +請負業者が再び働きました。YMMV、明らかに。

これは非常にわずかな追加です（プログラマ固有ではありません）が、最近のプロジェクトでAsanaで大成功を収めました。

既存のオンラインコラボレーションツールとの統合については、Slack以外にありません。チャットルームを中心に構築されていますが、Asana、GitHub、Bitbucketを含む他のツールのかなり最小限のハブとして機能します。もちろん、独自のAPIを使用して、これらの "統合"が事前に作成されたものとコミュニティで作成されたもののまともなコレクションを持っています。