私がここしばらく学んだ中で最も興味深い組織実践です。今日は、FAST アジャイルとは何かを共有し、それを実験する価値があるかどうかを探ります。 TL;DR?非常に説得力がありますが、まだ実験的です。 FAST アジャイルは、 ファストアジャイルとは何ですか? はアジャイル ソフトウェアのバリアントです。 FAST は、非常に大規模なチーム内の自己組織化に焦点を当てています。このような大規模なチームはコレクティブと呼ばれます。数名から最大 150 名までの場合があります [1]。 FAST Agile 週に 2 回、コレクティブは集まります。ミーティングにて： 。 チームメンバーは、自分たちがどのような進歩を遂げたかを示し、伝えます 。これらはトッププロジェクトに関するコンテキストを提供します。作業が完了するか、優先順位が変更されると、新しい優先順位が導入されます。そして通常、優先順位は壁や仮想的な同等物に視覚的に表示されます。 プロダクト リーダーはビジョンを繰り返し説明し、方向性を設定します 、自己選択して小さなチームを作ります。 コレクティブ内の人々は、最優先の仕事を遂行するために自己組織化し FAST アジャイルの最も興味深い部分は、これらの自己組織化チームです。そのため、これについてもう少し詳しく説明します。 会議ごとに、人々は自発的にチームをリードし、人々は自発的にそれらのチームに参加します。誰かがチームの管理者を志願するとき、彼らは前に出て、「私は（トッププロジェクトの1つ）に取り組むつもりです」と言います。その後、人々は作成されたチームに参加し、その分野で作業します。チームの最小人数は 2 人であるため、チームを結成するには「自分の足で投票」する人が必要です。 結成されたチームは次のことを行います 製品が定めた優先順位に従う必要があります。たとえば、デプロイ パイプラインの改善や不安定なサービスの監視の改善を中心にチームを結成できます。 いいえ 人々は、週に 1 時間の会議以外の時間のほとんどを、自分で選択し、自分で組織したチームで過ごします。理論的には、週に 2 回チームを変更することもできます。しかし実際には、人々は最終的に誰と一緒に働きたいのかを見つけ、チームは 傾向があります。 最初の 1 か月ほどで落ち着く ビジネスニーズの変化や、さまざまな分野で専門知識を持つ人材が必要になったときに人材が移動できるよう、十分な流動性を維持しています。チームの移動は予期された、労力の少ない変更です。これが意味するのは、コレクティブ ミーティング中に、人々が自分のチームを再構築するパターンはあるものの、その構成は想像しているほど変わらない傾向があるということです。 バグやオンコールの処理方法など、他にも多くの詳細があります。これらのトピックのいくつかについては後ほど説明します。しかし、FAST アジャイルの基本的な核は、より大きな集団内でプロジェクトに取り組む、これらの自己選択チームです。コレクティブミーティングは構造化されており、ビジネスのニーズに関する背景を提供し、それらの優先事項に対する進捗状況を伝達することに重点を置いています。 相違点のまとめ FAST は、今日のほとんどのアジャイル ソフトウェア組織の運営方法とは大きく異なります。私が見た違いは次のとおりです。 (SCRUM、カンバン、または「軽量アジャイル」) 一般的なプラクティス ファストアジャイル 会議の密度 中～高 会社によって異なりますが、一般的には毎日のスタンドアップ、デモ、身だしなみ、見積もり、レトロなど)。 低い 週に 2 回、30 分のミーティング。その他ご希望に応じて。 拡張性 スケーリングの単位はチームです。 チーム (およびその責任領域) を成長させ、分割し、作成することは、管理の主要な焦点です。 ビジネスの優先順位が変わると、優先順位の変更を反映するために組織を再構築する必要があります。 スケーリングの単位は集合です。 実際には、作業トラックの数は一般的な慣例と同様に増加します。ただし、人を追加したり、仕事の流れを変更したりすることは、より流動的で自己組織化されます。 「小さすぎる」または「大きすぎる」チームによる課題が少なくなります。チームの存続可能性や、チームと責任分野のマッチングについての懸念が少なくなります。 非常に大規模な企業ではテストされていませんが、理論的には健全であると思われます。 コードの所有権と専門知識の連携 厳密なコード所有権。これは、世界を個人が習得できるものに分割するのに役立ちます。人々が自分の地域で働いているため、インセンティブが適切に調整されています。課題は、各チームがコードベースを確実に保守および運用できるようにすることです。 責任の移動は苦痛を伴う傾向があります。ビジネスの優先順位を変更すると、組織の再編が必要になることがよくあります。 実践は分散化され断片化する可能性がありますが、これにより課題が生じる可能性があります。たとえば、チームに独自のプログラミング言語を選択させたり、さまざまな作業方法やコーディング スタイルを選択させたりできます。 コードの所有権を共有します。優れた基準、熟練したチーム、または優れたレビュー慣行が必要です。優先順位の変更はそれほど難しくありません。 Collective の境界を変更しない限り、Reorg はほとんど存在しません。 (再組織化にどれだけの管理時間が費やされるかを考えてください!) 実践をもっと標準化する必要があります。そうしないと問題が発生します。プラクティスを標準化することは良いことであり、インセンティブは適切な場所にありますが、失敗モードはおそらくさらに悪いものです。 アーキテクチャパターン 理想的なアーキテクチャはマイクロサービスです。大きなモノリスは十分に因数分解する必要があります。一般に、マイクロサービス環境の外では乱雑になります。 私は、FAST がアーキテクチャについてもっとこだわることを期待しています。モノリシックなコードベースまたはマイクロサービス環境で動作する必要があります。しかもブレンドで。マイクロサービス環境への移行をより段階的に行う必要があります。 ロールアウトパターン コードの所有権を厳密に設定するには、どのチームが何を所有するかを組織全体で設計する必要がある傾向があります。これらの変更の実装は常にビッグバンです。破壊的な大規模な再組織が必要です。 段階的に実行できます。 1 つまたは 2 つのチームから始めて、うまくいったら徐々にチームを追加することができます。 再組織は頻繁に行わないでください。集団レベルでは引き続き発生しますが、その頻度は少なくなるはずです。 アライメント機構 通常、OKR、全員による会議、書面によるコミュニケーションを使用して人々の調整を行います。 コレクティブ ミーティングは、週に 2 回組み込まれた全員参加のミーティングで、目標を強化し、チームの背景を設定します。リーダーがその会議を真剣に扱っている場合、影響力は非常に高いと思われます。 従業員の定着率 実践は、 研削やトップダウンの高度に制御された環境から、 、ビジネスに価値を継続的に提供するパフォーマンスの高いチームまで多岐にわたります。 したがって、定着率は企業によって大きく異なります。 機能工場の ビジネスの背景と顧客を理解し 一般的なアジャイル プラクティスと同様に、プラクティスはさまざまである可能性があると思います。 ただし、FAST は と一致しているため、従業員の定着に役立ちます。従業員は、誰と働くか、何に取り組むかを選択し、自分の仕事が重要であるという確信を得ることができます。 これにより、全体的な満足度が向上することが期待されます。課題の 1 つは政治かもしれません。自治グループは紛争への対処が下手な場合があり、それが裏目に出る可能性があります。 内発的動機 ご覧のとおり、FAST は、現在ほとんどの企業が行っているアプローチとは大きく異なります。 では、トレードオフは何でしょうか? 私が見たところ、FAST アジャイルのトレードオフは次のとおりです。 FAST は組織の拡張性を向上させる可能性があります FAST は段階的に試すことができます FAST を使用すると、再組織化が少なくなるはずです FAST により、優先順位の変化への対応が容易になります 内発的動機付けと維持には FAST の方が優れている可能性がある しかし… 多くの環境は FAST と互換性がありません 自己管理が必要になるかも知れません FASTには多くの作業が必要です FAST の資料には専門用語がたくさんあります それぞれについて順番に説明します。 FAST は組織の拡張性を向上させる可能性があります 組織を拡大する場合、通常は「水平」に拡大します。組織は一度にチームごとに成長します。これらの各チームは製品の一部を所有しており、多くの場合、製品チームをより効果的にするためのプラットフォーム組織が存在します。 組織の複雑さは、人数が増えるにつれて爆発的に増加します。エンジニアリングに 10 人がいる場合、全員が相互にコミュニケーションをとることができます。エンジニアリングに携わる 100 人全員が互いに話すことはできません。そして、コードベースは誰の頭にも収まりません。そこで、この複雑さを複数のチームに分割し、各チームが注力できる領域を確保します。 FAST が興味深いのは、組織を「垂直」に拡張する試みであるためです。 FAST はチームを追加する代わりに、コレクティブと呼ばれるより を作成しようとします。コレクティブは依然としてコードを所有していますが、そのコレクティブ内の自己組織チームはコードを所有していません。そして、やはりコミュニケーションを細分化する必要があります。しかし、チームはよりダイナミックで、継続的に進化しています。再組織化を通じてチームを再構築するのではなく、それは継続的かつ運営方法の一部として期待されています。 大きなチーム チームの規模は、多くのエンジニアリング責任者にとってよく知られたトピックです。チームはどれくらいの規模にすべきでしょうか? FAST がどのように拡張性を向上させるかを理解するのに役立つので、このトピックを少し掘り下げてみましょう。 チームはどれくらいの規模にすべきでしょうか? エンジニアリング担当副社長の周りで時間を過ごしていると、エンジニアリング チームの規模についての話題が時々出ることがあります。小規模なチームに対する議論もあれば、大規模なチームに対する議論も聞くことができます。どちらの側にもメリットがあります。 小規模チームの利点 チーム内の調整とコミュニケーションのオーバーヘッドが軽減されます。 結果的に素早く動けるようになります。 作業の流れが少なくなるため、集中しやすくなり、成果が得られます。 管理が容易になります。 大規模チームの利点 よりフラットな組織。 150 人のエンジニアを擁するエンジニアリング組織の場合、10 人のチームには 3 ～ 4 人のディレクターが配置されます。 5人チームで6～8人のディレクターと1～2人の副社長で構成される。組織内の混乱はどこから来るのでしょうか?おそらくリーダーシップなので、大規模なチームは混乱を減らすことができます。 さらなる回復力。誰かが休暇を取っても、チームは問題なく継続できます。 したがって、小規模なチームはチーム内では優れていますが、チームの数が多すぎて組織が複雑になるため、あまり理想的ではありません。チームが大きいほど、組織全体の複雑さには優れていますが、各チーム内のパフォーマンスはあまり理想的ではありません。 多くのリーダーがとるアプローチは、より少ない作業の流れに集中する大規模なチームを作ることです。これにより、チーム内部の複雑さが軽減され、組織の複雑さも軽減されます。 FAST は、途方もなく大規模なチームを通じてさらに大きな組織の簡素化を達成しようとするアプローチとして見ることができます。そして、小規模な自己組織チームを持つことの利点も得ようとしました。 組織の拡大は困難な作業です 私のコンサルティング ビジネスの多くは、組織が規模に対処するのを支援することにあります。組織が直面するスケーリングの課題には、いくつかの段階があります。 通常、最初の障壁はエンジニア 15 ～ 25 人の位置にあります。これは、アメーバが大きくなりすぎたので、分割する必要があるときです。次のような種類の問題が発生します。 通信チャネルが無効になります。 エンジニアリング部門では納期や品質の問題が発生し始めます。 マネージャーやリーダーは圧倒されているように感じます。人を増やせば状況は改善されるどころか、さらに悪化するでしょう。 そして第二の壁はエンジニア約60名です。この時点で、さらに多くの 問題が発生し始めます。 調整の チーム間のプロジェクトが成功することはほとんどありません。 製品の作業がプラットフォーム チームに多忙になる、またはその逆。 大規模な取り組みを完了できない。 私は、優秀な人材が組織の複雑さの中で段階的に変化していく中で、何度も失敗するのを見てきました。私の予感としては、管理レイヤーを追加すると、これらのステップ順序が複雑になるのではないかと考えています。 エンジニアリング組織を成長させることは真のスキルです。組織と人々がどのように機能するかを深く理解する必要があります。次のようなことについて学びます。 人々のグループが協力するための 。 調整モデル と機能的に設計されたチーム。 ストリームに合わせたチーム ビジネスの優先順位の変化に応じて人材とコードを変更する再組織の方法。 製品投資と重複する技術的責任の領域に製品を分割する方法。 チーム周囲のコミュニケーション チャネルを設定する。 製品を効果的にサポートするためのオンコールおよび信頼性プログラムを設定します。 複雑さと闘うためにプラットフォーム組織と開発者エクスペリエンスへの取り組みを立ち上げる。 等。 たとえこの専門知識を持った人材がいたとしても、スケーリングに対処するには管理チームに多大な労力が必要です。したがって、FAST がより適切に拡張できれば、管理チームが別のことに集中できる可能性が大きく広がります。また、ステップ順序の変更の頻度がはるかに低いため、組織の管理が大幅に容易になる可能性があります。 FAST アジャイルに関する思考実験 そこで、チームの規模を拡大 想像してください。チームを 5 人や 10 人で構成するのではなく、効果的な 20 人のチームを編成できたらどうでしょうか?それとも60人チームでしょうか？ できると 一見すると、これはばかげた提案です。それほど大規模なチームは効果的ではありません。 12人チームでも無理がある。 20人、30人に報告をさせた人の履歴書を見ることもあります。私の即座の反応は、彼らがひどい会社で働いていたのではないかということです。これだけの直属の部下がいるのは「組織臭」です。 FAST アジャイルの中心的な前提は、この大きな集団内に自己組織化と自己選択のチームを追加すると、チームをより 拡張できるということです。各チーム (FAST ではコレクティブと呼んでいます) はさらに大きくなる可能性があります。そして、人々が日常的に一緒に働くチームは、それらの集合体内で自己組織化されます。 水平方向に 大規模なコレクティブが効果的であれば、組織の複雑さは大幅に軽減されるでしょう。典型的なソフトウェアスタートアップは、責任分野を分割しなければならないまでに何年もかかる可能性があります。コードベースを各チームが所有する領域に厳密に分割する必要はありません。これにより、マネージャーは管理時間が大幅に解放され、製品とチームに集中できるようになります。 したがって、これが私たちがテストする必要がある中心的なことです。自己組織化と自己組織化は、より小規模で設計されたチームと同じくらい効果的な運営方法を提供しますか? そうなれば、組織を拡張するのに一桁優れた方法が提供される可能性があります。なぜそこまで？サイズ 6 人のチームで成長する組織と、サイズ 60 人の「チーム/コレクティブ」で拡大する組織を比較してみましょう。 この議論には多くの仮定が組み込まれており、いくつかの穴を突くことができるかもしれません。しかし、そうするとしても、FAST では基本的に、より大きな組織単位が製品とコードベースの領域を所有できるようになります。 FAST は新しいものであるため、FAST チームが従来のアジャイル チームと同じくらい効果的に機能するかどうかについての証拠は現時点ではあまりありません。しかし、その質問に対する答えは「イエス」だと思います。私がそう信じられる理由はいくつかあります。まず第一に、ジム・ショア氏のこれに関する予備的な経験は非常にポジティブなものであり、彼は私が信頼できる人物です。 私が FAST に対して強気な 2 つ目の理由は、自己組織化を行う大規模なグループに携わった経験があるからです。そして、それがうまく機能したことに驚きました。 もちろん、中小企業では、多くの自己組織化が見られます。しかし、企業が成長するにつれて、物事は標準化され、チーム内を除いて自己組織化は排除されます。しかし、私が参加した中で最も興味深い実験の 1 つは、New Relic での大規模な自己組織化イベントでした。私たちはすべてのチームを再設計し、50 のソフトウェア チームの全員に、どのチームに所属したいかを選択するよう依頼しました。各チームに必要なスキルには制約があり、全員が所有する必要があるスキルを定義していました。それは、私たち主催者さえも予想していたよりもはるかに成功しました。 したがって、陪審はこれについては判断していませんが、私の直感では、この慣行は適切な状況下で多くの可能性を秘めていると思います。 FAST は段階的に試すことができます これは FAST の資料には記載されていませんが、FAST の興味深い点の 1 つは、段階的に実験できることです。 実験として 1 つのチームに FAST アジャイルを実装し、時間をかけて追加のチームを飲み込む BLOB アプローチを使用できます。それがうまくいけば、追加のチームを飲み込み続けます。そうでない場合は、実験を中止します。 FAST を使用すると、再組織化が少なくなるはずです 組織には変化が起こります。優先順位は変わり、人々は去り、製品の分野は予期せぬ成長を遂げます。以前の技術的な決定が邪魔になり、追加の作業が必要になります。投資を必要とする新たな機会が生まれます。 これらすべては組織の構造に影響を与えます。一連のチームがあり、それぞれが独自の所有領域を持っています。この変化が起こると、時間をかけて組織をリファクタリングして、可能な限り最高のパフォーマンスを発揮します。これらのリファクタリングは「再組織化」であり、成長する組織では頻繁に発生する可能性があります。 FAST を使用すると、再組織化の頻度が大幅に減ります。再編成の単位は非常に大きいため、それほど頻繁に行う必要はありません。 これの潜在的な欠点は、定義された責任領域を持つチームが存在しないことです。そのため、責任が分散され、コードコモンズの管理が不十分になる可能性があります。 (これについては少し後で説明します) FAST により、優先順位の変化への対応が容易になります 従来の構造のチームで優先順位が変わると、その作業を行うためにチームをセットアップすることになります。そのチーム構造が新しい優先事項をサポートしていない場合は、組織をリファクタリングする必要があります。 FAST の場合、優先順位の変更はより流動的かつ継続的になります。責任がコレクティブ内にある限り、チームは仕事を中心に組織するだけで、まるで別の日のような気分になります。 また、集合的な会議の構造により、優先順位の変更があまり劇的に行われなくなります。基本的に、週に 2 回、オールハンズが組み込まれています。 Collective ミーティングでは、継続的に状況を伝え、顧客と市場についてチームを教育することができます。これは、チームの連携をより良く保つのに役立つはずです。 このアプローチを四半期ごとの OKR のようなものと比較すると、そのアプローチの方がより流動的で、人々の調整に効果があるように思えます。コンテキストと優先順位を継続的に共有するには、プロダクト リーダーの献身的な努力が必要です。しかし、私がこれまでに所属してきた最高のチームのいくつかには、プロダクト リーダーがこのようなやり方で行動していたので、これは有意義な時間を費やしたのではないかと思います。 内発的動機付けと維持には FAST の方が優れている可能性がある 多くのチームは、自分たちのプロセスが人々をコントロールするツールとして設計されていると感じることがあります。そして、それは組み立てラインで働いているように感じるかもしれません。 FAST は、設計の基本的な要素として自己組織化を採用しています。これは非常に基本的なものなので、自己組織化がなければ機能しません。管理にはまったく異なるツールキットが必要であり、トップダウンの階層的アプローチとはほとんど (完全ではありませんが) 互換性がありません。 ダニエル ピンクは、 概説したことで有名です。 内発的動機付けの 3 つの側面を – 自主性を持ちたいという欲求により、コンプライアンスよりもエンゲージメントが高まります。 自律性 – よりスキルを高めたいという衝動。 マスタリー – 意味があり重要なことをしたいという欲求。目的を重視せずに利益のみを重視する企業は、顧客サービスが低下し、従業員が不満を抱くことになります。 目的 FAST を使用すると、仕事を自主的に行うことができ、自主性を感じることができます。自分のスキルを向上させ、熟練した感覚を得る仕事に集中することを選択できます。また、自分の仕事がビジネスにとって重要なこととどのように結びついているかを常に思い出し、目的意識を感じることができます。したがって、保証されたものではありませんが、FAST を導入している組織では高い定着率が得られる可能性があると私は考えています。 自己組織化は、人々のコミュニティがより良く連携できるようにするための便利なシグナルも提供します。 「嫌なマネージャー」タイプの人は、自分の行動が歓迎されていないというシグナルを受け取ります。どうやって？彼らはチームを率いるために前に出て、自分がやりたい仕事を言います。誰もチームに参加しない場合、作業は行われず、チームは形成されません (チームには少なくとも 2 人か 3 人が含まれていなければ、チームは形成されません)。 自己組織化により、他の会社では注目されないような仕事のつらい側面にも対処できるようになります。たとえば、テストスイートがひどい場合、誰かがその問題を修正するチームを率いるために名乗り出ることができます。明らかにビジネス上の優先事項ではない仕事を行うのは完全に合理的です。しかし、それは公の場であり、それが起こるためには他の人も参加する必要があります。これにより、 にいるような気分を避けることができます。 機能ファクトリー 最後に、毎日一緒に仕事をする人を選択できるようになりました。過去に自己組織化チームを見てきたとき、これは予想外の利点でした。人々は一緒に働きたい人たちと働くことを選ぶのです。そしてそれらのチームは私が予想していたよりもはるかに強かったです。 これらすべてのバランスをとるのは、人々が FAST で経験するであろう新たな苦痛です。課題の 1 つは、非公式の権力関係、または潜在的な政治にあるかもしれません。 多くの環境は FAST と互換性がありません FAST は非常に新しいため、実装にはリスクが伴います。あらゆる状況で「速い」という言葉が意味を成すわけではありません。そして、さらに不明な点があります。実験的なアプローチとして考えるのが最善です。 FAST を試すのに最も適した環境はどれですか?では、FAST を避けるべき場所はどこでしょうか? このリストに含まれる品質があなたの会社にあるほど、FAST への適合性が高くなります。 経営革新と実験に興味がある。 信頼性が高く、恐怖が少ない環境。あるいは、少なくともリーダーシップにおける指揮統制を避けたいという願望。 プロセスの優れたガイドまたはファシリテーター。効果的な集合会議を運営し、プロセスを設定し、評価し、積極的に管理できる人。組織の力学と、グループ内の人間がどのように連携するかを理解している人。 （このために私を雇ってもいいでしょう）。 優先順位の変更率は中程度から高程度です。優先順位が変化していない場合、FAST はあまり役に立ちません。 協力的で自主性があり、高いパフォーマンスを発揮し、継続的に学習するチームです。 優先順位を理解できるリーダーシップチーム。 各 Collective ミーティングで優先順位やビジネスの背景について話すことができるプロダクト リーダーがいます。そして、彼らは効果的にコミュニケーションをとることができます。 これらの特性が当てはまらないほど、FAST でより多くの逆風に直面することになります。完璧な環境に身を置く必要はないと思います。ある意味、実際にそうなることよりも、これらになりたいと思うことの方が重要だと思います。したがって、おそらく最も重要な成功要因は、リーダーシップがそのためのスペースを作ることに協力していることです。 自己管理が必要になるかも知れません 自己組織化システムは効果的に機能します。しかし、それらは無料ではありません。彼らはコミュニティを管理することに似ています。 正しい行動を促すための制約と手段を作成する必要があります。そして、物事が軌道から外れないよう注意深く監視し、管理する必要があります。 どのような組織にも、悪意のある人物や、そのコミュニティの利益と一致しない人々が存在する可能性があります。かつてあるエンジニアと話したときのことを覚えています。そのエンジニアは、雇用主のために価値を生み出す義務があるとは思っていないと言いました（冗談ではありません）。エンジニアの中には、自分を雇用する会社にとって良いことよりも、自分のスキルを開発したり、自分をより価値のある従業員にすることに焦点を当てたいと考える人もいるかもしれません。 FAST では、人々の 管理するためにサインアップします。 コミュニティを 従来の状況では、階層構造により、誰がこの責任を負うのかが明確になります。 FAST では、衝突を避けて「メンバーに解決してもらう」のが簡単なのではないでしょうか。この結果、非公式の電力ネットワークが 支配することになる可能性があります。 FAST を使用する場合、これは避けるべきことです。 構造のない一種の専制政治を もう一方の極端な方法は、グループに問題を解明させず、経営陣に完全に対処させることです。これ 有害である可能性があります。 も したがって、FAST には、優れた促進、注意深い観察、および時折の介入が必要です。 FASTには多くの作業が必要です FAST を試したくない最大の理由は、FAST には隠れた作業がたくさんあるからです。組織内で不慣れな運営方法に多くの変更を加える必要があります。 FAST は、新しいコンピューター プログラミング言語で作業することに例えることができます。この新しい言語は、人間工学に基づいた新しい機能を多数備えており、これまでに見たものよりもはるかに優れているように見えるため、有望に思えます。しかし、この新しい言語で書かれたフレームワークやライブラリはありません。したがって、多くの部分を自分で構築する必要があります。 したがって、FAST の最大の欠点は、これが十分に確立された手法ではないことです。 FAST の動作方法と従来の慣行との間の非互換性に対処するには、多くのことを構成する必要があります。ここではいくつかの例を示します。 パフォーマンス管理はどのように機能しますか? 従来のチームでは、仕事を監督し、個人を指導するマネージャーがいます。業績評価があり、誰かが適さない場合は、マネージャーが介入することができます。業績評価には問題がありますが、ほとんどの人は自分の働き方を理解しており、組織内で目的を果たしています。 FAST チームでは、パフォーマンス レビューを行う明確な方法が実際にはありません。その人のマネージャーは、その人が何をしているのか、どのように働いているのかさえ知っていますか? 「チーム」は一時的なものなので、評価することもできません。 したがって、パフォーマンス管理の概念全体を再発明する必要があります。いずれにせよ、それは良いアイデアかもしれませんが、それは思考と発明を必要とするものです。 FAST におけるエンジニアリング マネージャーの役割は何ですか? エンジニアリングマネージャーの役割を構築する方法はたくさんあります。私は通常 ことをお勧めします。そうすることで、パワーの差が問題を引き起こす領域にエンジニアリング マネージャーを置くことなく、チームと協力して作業できるからです。エンジニアリングマネージャーの役割を定義する有効な方法はたくさんありますが、私はこれに惹かれる傾向があります。 、エンジニアリング マネージャーにプロジェクト管理を担当させる FAST では、エンジニアリング マネージャーの役割はそれほど明確ではありません。長く存続するチームは存在しないため、エンジニアリング マネージャーが直属の部下と協力して働くことは困難です。 エンジニアリング マネージャーに、自己組織化されたチームを率いてもらうこともできます。あるいは、彼らに純粋な人材のマネージャーになってもらうこともできます。あるいは、選手兼コーチになってもらうこともできます。 これらすべてにはトレードオフがあり、かなり大きな欠点もいくつかあります。 FAST により、エンジニアリング管理の必要性が軽減されるようです。雇用し、パフォーマンス管理を行い、プロセスを監督する人材が依然として必要です。しかし、従来の組織ほどではないでしょうか? 私は多くの組織が規律としての管理を重視していないために苦しんでいるのを見てきました。しかし、FAST 組織では管理の必要性はそれほど高くないと思います。 私はこれがうまくいくかどうか非常に興味があり、FAST を実験している組織から話を聞きたいと思っています。経営って何をするの？ 所有権の領域がない場合、コードの品質をどのようにして確保するのでしょうか? コードの所有権は、コードの品質を高く保つための自然なインセンティブをもたらします。将来の自分は現在のコードで動作する必要があるため、それはあなたの利益になります。 コードの所有権が共有されている状況では、コードの品質を確保するために、より多くの努力をする必要があります。私がお勧めするのは、必須の練習としてペアリングまたはモビングです。 コード パターンに関するより強力な標準も必要になります。コードのリンティングが必要になります。そして、ある種のアーキテクチャ上の意思決定が必要になります。フロントエンド コードで状態を処理する方法について 20 のパターンを用意する必要はありません。これらはほとんどのソフトウェア組織で発生する問題ですが、FAST を使用している組織ではより差し迫った問題になります。 多くの組織が投資が不足していることの 1 つは、効果的なソフトウェア設計パターンに関するトレーニングとコミュニケーションです。そして、どのアプローチをいつ使用するかについて全員の意見が一致していることを確認するための会話。これらは、FAST 組織ではおそらくさらに重要です。 コード所有権の共有は、いくつかの前例がある慣行です。 FAST で進める場合は、時間をかけて成功する方法を掘り下げる価値があります。 複数のコレクティブがあり、コレクティブの境界を越えるとどうなりますか? 集団の境界を越える作業は、FAST では基本的に定義されていません。また、高度な調整を必要とする大規模な取り組みも、FAST では十分に規定されていません。したがって、これらの状況に対する解決策を発明する必要があります。 FAST を使用する複数のコレクティブを持つほど大きな組織では、クロスコレクティブ プロジェクトが実行されます。これらの問題に対処するためのパターンは、より小規模な問題を解決する方法と類似または類似しています。しかし、私の知る限り、これはほとんど未知の領域です。したがって、これらの問題が発生した場合は、いくつかの 使用して解決する必要があります。発明行為になります。 調整モデルを FAST はオンコールにどのように対処しますか? オンコールについては、 では特に言及されていません。したがって、それに対処するためのスキームを考案する必要があります。 FAST ガイド 従来のチームでは、オンコールに関する標準的なアドバイスは、各チームに独自の業務の責任を持たせることです。そして、チームの全員が待機できるようにすることです。これは、負担がそれほど大きくないように、少なくとも 4 人のチームを構成する必要があることを意味します。チームが作業成果物のオンコールを行うことで、チームに信頼性を組み込む動機が与えられるという考え方です。これにより、適切なオンコール スケジュールを確実に確保することができます。 FAST を使用すると、段階的なオンコール ローテーションを作成できます (このランブックに従い、問題が解決しない場合はエスカレーションします)。そして、誰が何をサポートできるかのマップを明示的に保持する必要があります。これはあなたのチームにはマッピングされません。 これは非常に難しいことではありませんが、従来のオンコール業務に比べて一般的ではないため、管理者の注意が必要になります。 バグの修正やサポートのエスカレーションについてはどうですか? FAST には、「機能スチュワード」と呼ばれるオプションの役割があります。彼らは特定の機能の専門家のようなもので、その機能に関する利害関係者との連絡窓口となります。その機能に継続的に取り組む必要はありませんが、継続的にその機能を理解することが求められます。 オンコールと同様に、機能をその機能の専門知識を持つ担当者にマッピングする必要があります。これは、バグとサポートのエスカレーションの両方にとって重要です。また、オンコールと組み合わせることもできます。問題を適切な担当者に優先順位付けする何らかの方法が必要になります。 また、専門知識が 1 人か 2 人に孤立している場合に、知識のギャップを埋めるためのメカニズムを確保する必要もあります。 決定しなければならないことの 1 つは、バグを修正するためのポリシーです。それらを常に修正して、他の機能の動作を遅らせたいですか?バグは紹介者によって修正されたのでしょうか、それとも別の仕組みが必要ですか?また、バグの優先順位付けの責任者をどのように決定しますか?おそらく何らかの でしょうか？ ローテーション サポートのエスカレーションにもある程度の労力が必要です。連絡先は、エリアの機能スチュワードです。しかし、機能管理者が休暇中だったらどうなるでしょうか?おそらく、各分野に精通した人が複数人必要になるでしょう。そして、サポートの質問に作業が必要になった場合はどうすればよいでしょうか?仕事をただこなすだけですか、それとも中心的な優先事項に取り入れますか? これらはいずれも解決するのが難しい問題ではありませんが、管理作業です。そして、何をするにも、集中力と反応性のトレードオフが発生します。 信頼性に関するインシデントやインシデントの振り返りについてはどうですか? FAST はインシデントの処理方法を定義しません。オンコールのパターンによってインシデントの処理方法が大きく決まり、状況を解決する方法を知っている人が巻き込まれる可能性があります。 FAST では、インシデントの振り返りの処理方法については説明されていません。次のようなことを行うことをお勧めします。次の集団会議の前に、インシデントの振り返りをスケジュールすることです。回顧展の目的の 1 つは、インシデントの原因となった可能性や重大度を軽減するために実行できるいくつかの作業を特定することです。もう一つは、その出来事からできる限りのことを学ぶことです。 事件直後の集団ミーティングで、私は学んだことを共有し、また、振り返りで特定された作業の一部を実行することを次のサイクルで自動的に優先するようにしました。 New Relic では FAST を使用していませんでしたが、同様のポリシーがありました。私たちはそれを「事件を繰り返さない」（DRI）と名付けました。これは、信頼性に関して私たちがこれまでに行った中で最高のものの 1 つでした。 DRI 作業は自動的に他の優先事項よりも重要になるというルールがありました。したがって、インシデントが発生すると、常に範囲が狭くなるか、期限が延期されることになります。 デザイナーは FAST でどのように作業しますか? 多くのデザイナーが抱えている課題は、エンジニアリング チームとの共同作業、またはエンジニアリング チームよりも先に作業を行うことに集中することです。または、両方の方法で動作させることもできます。どちらの働き方についても強い議論があるでしょう。 FAST はこれがどのように機能するかを指定していないため、自分で決める必要があります。デザイナーは作業するチームにサインアップしますか?それとも、彼らは物事を先取りして取り組み、人々が何かを必要とするときに として機能するサービス組織なのでしょうか?決める必要があります。おそらくデザイナーにサインアップしてチームの一員になってもらうと思いますが、これも FAST を採用する際に必要な決定の種類の一例です。 コンサルタント プロダクト マネージャーは FAST でどのように機能しますか? FAST における製品の役割は主に、優先順位を付け、優先順位を伝達することです。それ以外の作業については、FAST マニュアルには実際には説明されていないことがたくさんあります。 FAST マニュアルでは、プロダクト マネージャーがインスピレーションを与えてコミュニケーションを図り、その後エンジニアが機能に取り組むという前提になっているようです。 できる限り、私はエンジニアに顧客と話をさせ、彼らが取り組んでいる製品分野の専門知識を習得してもらいます。理想的には、エンジニアが作業を実行し、顧客にデモを行い、顧客からそれに対するフィードバックを得ることができます。 。プロダクト マネージャーにそれを促進してもらい、それを効果的に行うエンジニアの能力をレベルアップすることは、彼らの仕事の貴重な部分となる可能性があります。 このモデルには多くの柔軟性があります。一般的な製品からエンジニアリングへの引き継ぎを行うこともできますし、顧客と一緒にスペースを発見して問題を解決してもらうこともできます。 ご覧のとおり、FAST には多くのギャップがあります。残りの問題を解決する必要があります。 FAST の資料には専門用語がたくさんあります FAST の Web サイトとマニュアルがわかりにくいと感じるかもしれません。 FAST アジャイルの極意を理解するには、多くの専門用語や煩わしい用語を理解する必要があります。例として、 で実践を定義しようとする FAST アジャイルのひどい定義を次に示します。 FAST ガイドのバージョン 2.12 「流体スケーリング技術とは何ですか？」 Fluid Scaling Technology は、Open Space Technology と Open Allocation を組み合わせて、仕事の周りで人々を組織するための軽量で理解しやすく、習得しやすい方法、つまりスケーリングを作成します。 FAST は、Fluid Scaling Technology の頭字語です。アジャイル向けの流体スケーリング テクノロジは、FAST アジャイルです。」 それで。悪い。そしてこれは非常に代表的なものです。コレクティブ、バリュー サイクル、オープン テクノロジー、ティール トランスフォーメーション、理論 Y などへの言及が数多く見られます。これらはすべて説明なしで提示されており、たとえ説明されたとしても役に立ちません。彼らはアジャイル理論家というニッチな聴衆に向けて話をしており、有用性よりも帰属に焦点を当てています。 結論 それでは、私たちはどうなるでしょうか？ FAST アジャイルは試してみる価値がありますか? その答えは「はい」であると私は信じていますが、適切な状況下で注意が必要です。個々のチーム内で試してみることができます。また、リーダーのサポートがある場合は、より大きな組織内で徐々に試してみてください。 実験した場合は私と共有してください。あなたの組織でそれを展開するのに協力が必要な場合は、私に連絡してください。私が直接あなたを助けるか、助けてくれる人をつないであげます。 ありがとう この投稿の初期バージョンは…本当にひどいものでした。批評してくださった と に感謝します。二人とも、この投稿に関するいくつかの大きな問題点を指摘したため、私は立ち直り、自分のアプローチを再考することになりました。そして、彼らはいくつかの優れた点を指摘し、私はそれを投稿の独自のセクションに組み込みました。結局、投稿の大部分を書き直しましたが、その結果にはとても満足しました。ありがとう！ Seth は 発行しているので、ぜひチェックしてみてください。Daviy は (私と同じように) を行っています。 セス・ファルコン氏 デイビー・スティーブンソン氏 エンジニアリングのリーダーシップに関するニュースレターを スタートアップのアドバイスやコーチング 私に FAST アジャイルを紹介してくれました。彼はその経験について をしています。そして私たちは何度か会って、FAST の意味と実装について話し合いました。 Jim は、 の著者です。 Jim Shore が 素晴らしい話 『The Art of Agile Development』 による からの画像 Kennon Pixabay 脚注 おそらくコレクティブにとって 150 人という人数は手に負えないと思います。最大人数は 60 名が適切だと思います。 でも公開されています。 ここ
