スクラム方法論について
スクラムはアジャイルのアジャイル手法の1つであり、変化する外部要件にすばやく対応できます。 スクラムの主な概念は、反復とスプリントです。 ワークフロー全体は、反復と呼ばれる期間に分割されます。 反復には、計画、直接開発（スプリント）、およびテストが含まれます。 反復には厳しい時間制限があります。 したがって、スクラムは主にタスクのタイミングに焦点を合わせています。
プロセスについて
では、チーム内でスクラムがどのように実装されたかを正確に見てみましょう。 まず、プロセス全体を概観し、次に各段階を詳細に検討します。 各反復は1か月続きました。 タスクの計画と評価から始まり、その後、スプリントがあり、その間、必要に応じて毎日5分間の議事録とその他の会議が開催されました。 開発の最後に、新しい機能のデモと回顧がありました。
計画中
すべては、製品マネージャーが製品の目標とユーザーのフィードバックに基づいてタスクのリストを作成したという事実から始まりました。 次に、このリストから優先タスクを選択し、評価のために私たちにくれました。 このリストは、奇跡が起こった場合に備えて、1か月で実際にできることより少し多かったです。 私たちは、タスクが細部まで詳細に記述されていないことに多くの不満を述べました。 しかし、今では、他のどのチームにも、PMからのこのような高品質のタスク設計を見たことはない、と言うことができます。
さらに、チームは各タスクを評価し、今後のスプリントに含まれるものを評価する必要がありました。 評価については、より詳細に伝える必要があります。 最初の段階で、チームリーダーは次のように評価しました。チームリーダーが各タスクを各開発者に割り当て、開発者が評価を行いました。 開発者の評価が予想と非常に異なる場合、不一致の原因を理解しようとし、評価またはタスクのいずれかを修正しました。 これにはチームリーダーから多くの時間がかかり、彼は常にシステムを独立させようとしていたため、最終的にはプランニングポーカーを使用することになりました。 各開発者は、今後のスプリントについてチームのすべてのタスクを評価し、チームリーダーは各タスクの平均スコアを計算しました。 このアプローチの欠点は、さまざまなレベルの開発者が評価を行い、後で初心者にタスクが落ちた場合、もちろん彼はこの評価よりも長い時間タスクを実行したことです。 各開発者に係数を導入しようとしましたが、これにより事態はさらに複雑になりました。 その結果、新しいインセンティブシステムの出現により、彼らはタスクの個々の評価を完全に放棄しましたが、それについては以下で詳しく説明します。
すべてのタスクが評価された後、スプリントの長さに適合するすべてのタスクが優先順位によって選択され、開発プロセスが開始されました。 この瞬間の後、PMは反復が終了するまでリストに新しいものを追加できませんでした。
5分
反復の中で開発プロセスは最長でした。 この時点で、午前中に5分間の期間が毎日開催されました。 スタンドアップラリーと呼びました。 全員が輪になって、それぞれ昨日やったこと、今日やろうとしていることを話しました。
この会議の目的は、チームメンバー間でタスクを同期し、発生した問題を特定することでした。 さらに、心理的な瞬間もありました。 午前中に誰かがチームに何かをすることを約束した場合、彼がこの約束を守らないことはすでにより困難でした。 チームメンバーは、この集会に対して非常に異なる態度を示しました。 いわゆる「兵士」がいました。集会の本質を理解し、兵士たちが状況を報告しました。 「反逆者」もいました-モニターから離れて、みんなと一緒に輪になりたくない人。 しかし、仕事の一環として、ほとんどの人が冷静にそれを受け入れました。
スプリント
私たちの開発の興味深い特徴は、チームリーダーが専門分野への分割に断固として反対していたことです。 つまり、プログラマーは、他のプログラマーの後に何らかのタスクを実行したり、バグを修正したりする必要がありました。 このアプローチは非常に議論の余地があり、必要に応じてコメントで議論することができます...
タスクスケジューラとして、ターゲットプロセスシステムを使用しました。 最初は、実際のボードはなく、このシステムのタスクのリストだけがありました。 後にボードが登場しましたが、それはプロセスの中心部分ではなく、5分間の集会はその周りに構築されませんでした。 むしろ、それはタスクがスプリントセグメントのどこにあるかを視覚的に表現しただけでした。
チームリーダーはプログラマーが自分のタスクに間に合っているかどうかを何らかの方法で追跡しなければならなかったため、各タスクに費やした時間に関するレポートを作成しました。このタスク。
これらのデータに基づいて、経営陣はバーンダウン図を作成しました。この図に従って、私たちがうまくやっているかどうかを見ることができました。
特別なコードコラボレータープログラムでコードレビューを実施しました。 レビューにコードを送信する場合、1人のレビュアーと任意の数のオブザーバーのみを割り当てることができます。 このコードをコミットするかどうかを決定したのは、レビュー担当者のみです。 ブラウザのコメントは、本質的に助言にすぎません。 興味深いことに、チームメンバーがレビュアーとレビュアーのリストに載っていなかった場合、彼はこのコードを見ることさえできませんでした。
デモ
すべてのタスクが完了してテストされた後、「デモ」と呼ばれる集会の時が来ました。 この集会では、デザイナーから技術文書部門までのすべてのチームメンバーが集まって、開発者のスピーチを見ました。
大画面の各開発者は、現在のスプリントで何をしたかを示しました。 これはフロントエンド開発者にとって特に印象的でしたが、バックエンド開発者もコンソール画面を開き、新しいクールなAPIリクエストを示しました。
この集会の利点は、通常5分間、人々が何かをしていることを伝えるが、チームの誰かが結果を見ることがほとんどないことです。 そのため、デモは製品の新機能を知る良い機会です。 デモは一般的な士気を高め、私たちの船が航行していて静止していないという感覚を与えます。
副作用もあります。 デモ中にインシデントが発生し、何かがおかしくなったり、新しい動作の興味深い事例が発明されたりしたため、テストチームは常にバグの完全なノートを残していました。
回顧
回顧は、現在の問題を特定し、将来のプロセスを改善するために、反復の完了後に開催される集会です。 私たちのチームでは、この集会は事後分析と呼ばれていました。 チームリーダーは、この会議を最もリラックスした雰囲気で開催することを望んでいたため、ビールとスナックを購入し、テーブルに座って、反復の終了を祝い、同時に反復で何が起こったのが好きで、好きではなかったのかを話し合いました。 チームはほとんど無関心だったので、この宴会は通常非常に暑くて長くなりました。 製品マネージャーはプログラマーにタスクが時間通りに完了しなかったと不満を言い、テスターはプログラマーにタスクがテストのために遅すぎて提出され、反復の終了前にそれらをチェックする時間がないと不満を言いました。 プログラマーは、タスクが十分に考え出されず、特定の状況を考えるのに多くの時間を費やさなければならないと不満を漏らしました。
ある時点で、各回顧展で同じことについて不平を言っていることに気付き、すべての瞬間を記録することにしました。 その後、すべての回顧で同じことを記録していることに気付きました。 次に、記録するだけでなく、各問題の解決策を特定の人に割り当てることにし、彼は次の回顧展について報告しなければなりませんでした。 それから私たちは、誰もが報告する一方で、新しい問題を書き留めることに気づきました-飲む時間はもうないので、回顧展と酒を分けることにしました。 その後、それはもはやそれほど面白くなく、回顧展はドライで面白くない集会に変わりました。
私自身に代わって、その基本的な意味に加えて、レトロスペクティブには非常に重要なポイントである心理的リラクゼーションがあります。 これは、人が完全に免責をもって、1か月以上蓄積したすべてを表現し、静かに働き続けることができる時間です。 ラリー中の明らかな攻撃にもかかわらず、その完了後、チームは毎回さらに団結しました。
その他のイベント
また、「1対1」の集会もありました。 2週間に1回、チームリーダーはチームの各メンバーと話をし、振り返っては言えないことすべてを言うことができました。
オフィス外での非公式のイベントもありました。 たとえば、年に2回、バーベキューのためにチームに参加しました。
刺激
どのチームの人生においても、誰もが熱心で仕事が本格的である最初の期間がありますが、同じチームのチームが数年間働いている場合、生産性の低下の期間が始まります。 そしてここで問題となるのは、疲労が蓄積しているだけでなく、製品がより複雑になり、そのサポートと拡張により多くの時間が費やされているということです。
チームリーダーは、チームにそのような瞬間があることに気付いたとき、プロセス全体を変更し、追加の刺激を導入することにしました。 彼の主なアイデアは、プログラマーとチームのメンバーという概念は存在しなくなるということでした。 チームは分割不可能な最小単位になります。 各反復の終わりに、チームは次のスプリントでどのタスクセットを実行するかを決定します。 そして、これらのタスクを実行します。 スプリント終了の2日前にタスクが完了してテストされた場合、チームはこれらの残りの日数を自由裁量で使用できます。 たとえ仕事に行かなくても 残念ながら、チームリーダーは経済的に私たちを刺激することができなかったので、プロモーションは自由時間で表明されました。
図は次のようになりました。
| 22日間 | |||
| 10日間 | 8日間 | 2日間 | 2日間 |
| 開発 | テストとバグ修正 | 評価 | 休む |
これは、月に2日はプログラミングを行わなかったことを示しています。 部門全体が会議室に集まりました。 経営陣から提供されたすべてのタスクを取り上げ、すべての困難な点を検討し、各タスクの評価を行いました。
このアイデアは失敗だったと言えます。 これらのインセンティブは2日間で1回しか獲得できませんでした。 タスクの見積もりは非常に高く、次のように、チーム全体の参加を伴う各アクションに対して個別の集会が作成されました。 誰もが間に合わず、勇気づけられる2日間を失うことを恐れていました。 過大評価はこれらのタスクの実装中に緩和につながり、多くの集会がプログラミングへの集中を妨げ、その結果、部門全体の生産性が低下しました。 この時点で、チームはすでに一歩下がって前のシステムに戻る必要があることを理解していましたが、時間がありませんでした。 部門は、チームが制御できない理由で閉鎖されました。
おわりに
この実験の前にインセンティブシステムを導入できなかったにもかかわらず、上記の方法論は数年間優れた結果をもたらし、チームは高速を示し、製品は非常に迅速に開発されました。 結論として、初心者チームのリーダーにアドバイスをしたいと思います。
- さまざまなプロジェクト管理方法を学び、実験することを恐れないでください。
- 毎日5分間の集会に参加してください-プロジェクトの状況を理解するだけでなく、チームメンバーにも理解してもらう必要があります。
- 部下と話してください。 二人目の父親になります。 あなたやチームからの秘密を彼らに教えないでください。 振り返りと1つ＆1つはこれに最適です。 そして、アルコールはこれに少し役立ちます。
- 「デモ」と入力します。 チームは、製品の開発状況を常に確認する必要があります。
- あまりにも多くの集会や制限を入力しないでください。 複雑なプロセスは、効率的な操作を妨げます。