あなたとあなたのチームが日々取り組んでいることをどのように追跡しますか？
私自身やチームのメンバーが実際に毎日何をしているかを追跡する方法に苦労しています。毎週、完成したカードを確認することで全体像がよくわかりますが、スタンドアップは少しは役に立ちますが、チームの日々の業務をうまく処理できていないように感じます。カードは、毎日のスタンドアップで更新なしで何日も進行し続けます、そして何人かのエンジニアは私のチームが最もコミュニケーション能力がありません。
メーリングリストや共有のGoogleドキュメントを介して全員が記入するある種の毎日の記録を実装することを考えましたが、これはかなり面倒で手作業のようです。
GitHubアクティビティの監視は問題ありませんが、毎日送信するメールの数に少し圧倒される可能性があります。そのためのダイジェストシステムを構築しようと考えましたが、時間に余裕がありません。
「進行中」のタスクの作業を測定できるように、チームが毎日行っていることを常に把握するためにどのような戦略を実装しましたか？
私は彼らと話します。
テクノロジーは社会問題を解決できません。あなたは短い朝のスタンドアップがあります。あなたは昨日何をしましたか？今日は何をしますか？何か障害はありますか？
何かが怪しげに聞こえる（または私が気になる）場合は、立ち止まって質問します。「昨日XYZで作業していましたが、どうなったのですか？」これは人々に注意を払い、何が起こっているのかを実際に知ることを強います。また、チームのリードを維持します（そして注意を払い、何が起こっているのかを実際に把握します）。この必要は時間どおりに、短い（10分max）。それ以外のものや人々は仕事を「棚上げ」しません。彼らは立ち止まり、立ち上がるのを待ってから、再び始めるのに時間がかかります。とにかくそうする人もいますが、それは主に避けられません。
午後はみんなのデスクに立ち寄ります。毎日の午後ではない（ただし、新しい人にとっては毎日の午後よりも多いかもしれません）同時にではなく、ほぼ同じ時間です（したがって、非公式であり、定期的です）。 「何か問題？障害物は？」
人が1対1でいるときに問題に遭遇する頻度に驚くでしょう。
問題がなければ、すばらしいです。仕事に戻る。問題がなければ一週間？問題。あなたは彼らに十分に挑戦していない、または彼らは開放されていません。 XYZ（彼らがスタンドアップで言及した）がどうなっているかを尋ねます。彼らに説明してもらいます。
これはマイクロマネージメントではありません。あなたは彼らに彼らの仕事をする方法を教えていません。あなたはそれらをベビーシッターではありません。あなたは彼らの日常生活から障害を取り除くためにそこにいます。そのためには情報が必要です。チームが会議に参加せず、プロジェクトマネージャーがキューブに立たされない限り、1人が1日1回立ち寄って助けを求めても、彼らが悲しむことはありません。しかし、これらすべての相互作用は、「私はあなたを助けるためにここにいる」という脈から来る必要があります。
私がやるもう1つのことは、変更セットのレビューです（自分で、非公式に）。次に、人々がチェックインする頻度、変更セットの大きさ、報告された内容とどの程度一致するか、やり直しの頻度、バグ修正の数などを確認できます。ステータスを「完了」に変更するワークアイテムはほとんど意味がありません。コードを見てください。終わったように見えますか？
注： 1つの非常に深刻なサイドポイント：チームの大きさは？ 7人以上ですか？もちろん、チームが大きすぎると、進行中のすべてを追跡できなくなります。
開発者を細かく管理しないでください！
生産的なソフトウェア開発には、長期にわたる集中した精神的努力が必要です。それらが一定の出力を生成することを期待することは現実的ではありません。あなたが毎日それらを測定し始めると、彼らはあなたが毎日見ることができるいくつかの識別可能なアーチファクトを常に生成するように彼らの仕事を再構築します。これは、ソフトウェアの品質に良い影響を与える場合とそうでない場合があります。ほぼ間違いなく、開発者の効率に悪影響を及ぼします。
Robert Harveyの提案 のように、チームを細かく管理しないでください。具体的なビジネス価値を備えた優先順位の高いタスクをチームに与え、チームにこのビジネス価値を提供する最良の方法を見つけさせます。
チームがビジネス価値を提供するなら、あなたは幸せでなければなりません。要求された機能を確実に提供する方法は、彼ら次第です。
しかしながら：
カードは、毎日のスタンドアップでの更新なしで、何日も継続して進行します
このcouldは、プロセスに欠陥があることを示しています。
チームとして実際に機能しておらず、立ち往生しているときに互いに助け合うために介入していないのは、チームかもしれません。それはまた、ビジネスとのコミュニケーションかもしれません。タスクが大きすぎるため、何が必要かを理解することが難しくなります。仕様は明確ではありません。
また、まったく問題がないことも考えられます。たぶん、チームは、完了までに数日かかる主要な作業を表すカードを使用してうまく機能しているかもしれません。
ふりかえりをあなたの懸念を表明するためのプラットフォームとして使用することは妥当だと思います。時々、外部から観測を受け取るのは良いことです。
しかし、問題があるかどうか、およびその原因は何であるかをチームに理解させてください。そして、タスクがチームに配信される方法を調整する必要があることを受け入れる準備をしてください。
毎日のスタンドアップはチームが作業を整理するのに役立つツールであることを忘れないでください。これは、マネージャーがチームの活動を追跡するためのツールではありません。
「プッシュメッセージング」ではなく「プッシュメッセージング」
多くの場合、開発者は次のいずれかの状態になります。
- はい、私はXをしました！
- Xに取り組んでいますが、時間がかかるようです...
- 私は問題Yに行き詰まっています。調査していますが、アドバイスが必要な場合があります。
- A、B、Cを待っているのでブロックされます。
理想的には、実際の生産性を損なうことなく、これらのステータスに関する合理的に最新の情報を入手したいとします。コンスタント「もう着いてる？」逆効果ですが、youは状態2〜4に役立つことがあるため、状態について通知する必要があります。
機能するのは、自動化された方法で「プッシュメッセージング」を行う文化です。コミットログ全体を見る必要はないかもしれませんが、すべてのチームメンバーの最新のコミットまたは最新の解決されたチケット（バグまたは機能用）を表示する「ダッシュボード」を作成できます。残りの状況については、そのような更新を積極的に電子メールで送信するよう依頼するか（できれば、コミットよりもまれであることをお勧めします）、ダッシュボードに継続的な進捗状況が表示されていないかどうかを尋ねてください。行き詰まる必要があるという内部合意を上げる必要があります（8時間ではなく80時間かかることが判明した場合、一部の機能は必要ない可能性があります）。その場合、最新の状態を維持するか、煩わされることになります。
あるいは、 https://idonethis.com/ のような文化をチーム全体に発信することもできます-これにより、他のユーザーも同じページにいることが保証されます。
他のいくつかの回答（コミュニケーションに焦点を当てた）の代替案は、おそらくノートカードのタスクを細かく分割することができるということです。これにより、すぐにフィードバックを得ることができます。
小さめのピースを使用すると、チームはそのように感じます毎日何かを達成するこれは、スタンドアップに反映する必要があります。
欠点は、これらの個別のカードが互いに大きく依存している可能性があることです。互いに非常に簡単にコミュニケーションできるチームは、ここで有益です。または、ピースが本来のように結合しない場合があります。最初に特定の処理を行う必要がある場合は、一部のカードを保留する必要がある場合もあります。
そうは言っても、人々はまだ行き詰まるでしょうまたは、タスクは時々予想される彼らやあなたよりはるかに挑戦的であることがわかります。これが、他の人が問題を抱えている人を判断せずにアドバイスを提供できるスタンドアップで公然と問題を話し合うことが依然として役立つ理由です。
他のいくつかの答えが持ち出したように、マイクロ管理の問題に答えるには：人々は毎日小さなタスクを達成しますが、達成された仕事の幅広い見方一人一人が日々の成果で判断するのではなく、実際に行われています。
これは、コミュニケーションが非常に簡単で人々が非常に親しみやすい8人のチームで作業しているため、これをお勧めします。 2日以上の作業が予想されないタスクが与えられます。時々これらのタスクは密接に関連していて、私たちはお互いが私たち自身の作品にどう取り組むかについてお互いを更新し続ける必要があります。私たちはそれぞれ、2週間ごとに達成したことをマネージャーに報告する責任があります。
もう一度質問を読んだ後、リーダーではなくチームメンバーとしてこれを尋ねている可能性があり、タスクを制御できない可能性があります。
- あなたはあなたのリーダーにタスクをもっと分解するように提案することができます
- あなたの仕事がブロックされたり、他のチームメンバーの仕事に依存している場合は、自由に彼らに確認し、必要に応じて別のタスクを実行してください。
まず、時間とスキルの観点から自分を分析する必要があります。あなたが技術者である場合、以前にいくつかの実地経験を積んでいる場合、の場合とは異なることがあります。締め切りが守られていることを確認するだけでよいマネージャー（開発者が実際に取り組んでいることについての高度な技術的知識がない場合）。
どちらの場合も共通点は、チームを促進し、彼らを信頼する気持ちを生み出すことができる必要があるということです。あなたは彼らのパフォーマンスを評価していませんが、彼らの経験を楽しく簡単にするために共感を示し、助けようとしています。
さて、あなたが上で言ったようにあなたが単なるマネージャーであると仮定します。その場合、開発者が開発に関連する深刻な問題に本当に直面しているとしても、彼女/彼を助けることができないかもしれません。実際の問題は時間がかかり、集中力も要求されます。さらに、開発者が自分の仕事に本当に誠実であり、その問題を解決するためにフルタイム（余分な時間でさえ）を払っていると仮定しますが、残念ながらまだ解決できません。そして、そのような状況（問題を完全に理解することすらできない場合）では、毎日、そして非公式に1日2回進行することによって、問題について尋ね続けます。その結果、開発者にとって極度のフラストレーションと混乱が生じます。毎日の進捗状況を収集するためのアプリでも、毎日のスタンドアップミーティングでも、どちらもイライラすることがあります。
一方、他のすべての要因を同じに保ち、あなたが強い技術的背景を持ち、過去に同じテクノロジーに取り組んだと仮定してください。この場合、毎日進歩するか、スタンドアップ会議をすることは本当に役に立ちます。開発者はきっとあなたとあなたの専門知識を信頼し、彼らが直面している大きな課題について議論することに慣れるでしょう。あなたは役立つかもしれないいくつかの提案を提供します、またはそれらが直接役立つものではない場合でも、いくつかの代替アプローチを提供するのに役立ちます。
ただし、いずれの場合も毎日のスタンドアップミーティングは、ヘッド/リード/マネージャーではなくチームメンバーであるという感覚を生み出す必要があります。チームメンバーがあなたと同じレベルであなたを考慮しない限り、彼らは懸念事項/提案/問題/フィードバックなどを伝えることができません。
考慮すべきもう1つのポイントは、自動化された進捗状況を使用することを考える前の、チームの規模と管理に費やす時間です追跡ソフトウェアまたはあなたの相互作用を増やします。チームによって懸念事項が提起されても、できるだけ早く解決できることを確認する必要があります。チームメンバーの主な動機付けの要因は、彼らの懸念/提案/フィードバックが真剣に受け取られていないか、評価されていないことです。日々の進歩を知ることは重要ですが、チームワークに完全に関与している場合にのみです。一部の副業にも関与している場合は、チームとより多くのやり取りを行わないでください。チームの応答が圧倒的で、時間前にチームがタスクを提出し、懸念やクエリを提起しているが、タイムリーなフィードバックやレビューを提供できない状況を考えてみてください。このような状況では、チームリーダーとしての影響力が大幅に減少します。
さまざまな構成のさまざまなIMチャットルームを作成して活用します。 @engineersのように幅広いものもあれば、@ newFeatureAのように特定のものもあります。
毎日のスタンドアップには、機内チケットのレビューを含めることを検討してください。
コラボレーションをサポートするオープン環境を使用し、QEと主要な製品所有者が開発者の真ん中にいることを確認してください。あなたは多くのことを聞き、あなたの周りのスクリーンを見ることからアイデアを得ます。
Robertが指摘するように、何よりもマイクロマネージメントとは見なされません（「見える」の使用に注意してください。つまり、実際の意図とは関係ありません）。
最終的には、時間の経過に伴って達成された結果を追跡し、そこからの速度を確認します。人々が士気を喪失したり、退去したりするため、日中の進歩に焦点を当てることは逆効果です。
GitHubやBitBucketなどのシステムに組み込まれた「フォロー」または「スター付き」のリポジトリメッセージングについて、まだ誰も言及していないことに驚いています。
私たちの技術的利害関係者（プロジェクトリーダー、開発およびサポートマネージャー）はすべて私たちの問題を追跡し、関連プロジェクトの更新履歴をコミットします。私たちは小さなチーム（15 FTE +請負業者）を持っていますが、これは私たちにとってはうまくいくようです
これらの項目については誰も測定していませんが、PMからの毎週のステータスレポートに加えて、これによりプロジェクトを毎日見ることができ、少なくとも誰もが作業している領域を認識しておくことができるため、誰もが可視性を失うことはありません。
また、開発者や請負業者、および私たちのビジネスリエゾン全体の透明性を高めるのにも役立ち、成果物のスケジュールに誰もが責任を持つことができます。
特定のリポジトリまたは組織全体に関連付けられたRSSフィードと組み合わせると、電子メールを制限し（必要な場合）、RSSリーダーを介して同様のデータのセットをリアルタイムで要約して提供できます。一部のユーザーにとってこれはOutlookなので、基本的には電子メールですが、若干異なりますが、他のユーザーは本格的なRSSクライアントを使用し、必要なすべての追加フィルターを使用して、正確なニーズに合わせてカスタマイズする必要があります。
最初は電子メールの量に関する同様の懸念に遭遇しましたが、エンドユーザーはRSSシステムを思い付きました。エンジニアリング組織がOutlookを使用していないクライアントに提案する以外に多くのことをする必要はありませんでした。複数のオフィスとタイムゾーンにまたがって、年間を通して約20〜30人のFTE +請負業者が私たちのために働きました。 YMMV、明らかに。
これはごくわずかな追加です（そしてプログラマー固有ではありません）が、最近のプロジェクトでは Asana で大成功しました。
既存のオンラインコラボレーションツールとの統合については、 Slack をご覧ください。チャットルームを中心に構築されていますが、Asana、GitHub、Bitbucketなどのotherツールのかなりミニマルなハブとして機能します。 pre-made と community-made の両方のこれらの「統合」の適切なコレクションがあり、もちろん独自のAPIを使用して構築できます。