アジャイルがすべて-2：アジャイル実装機能

実際に発生するアジャイル開発のニュアンスについて続けます。 アジャイルが正しく実装されているか、どのタスクおよび業界に適しているか、社内の誰が作業を「アジャイルレール」に移すべきかを理解する方法は？ ScrumTrekのアジャイルコーチであるVasile Savunovは、Mail.Ru Cloud Solutions ブログの編集者と経験を共有し続けています。



前回、 Vasilyはアジャイルとは何か、どのアジャイルに含まれているのか、アジャイルはどのようなステレオタイプを形成していたのかを話しました。 それでは、その実装について話しましょう。

アジャイル企業について

-柔軟な方法論に「業界の好み」はありますか？



2年連続で実施しているアジャイルロシアの調査では、スクラムは主にソフトウェア開発、金融機関のかんばん、および通信業界の両方で使用されていることが示されています。



収集されたデータを直接分析し、多くの回答者と協力した人物として、この状況は次の2つの理由によるものと考えています。

• ITの変化率は、財務の変化率よりも大幅に高くなっています。 したがって、スクラムは、迅速な実験により、優先順位を柔軟に管理し、入り口の外部環境や条件の変化に応じて方向を変えることができるアプローチとして望ましいものです。 金融はより保守的です。
• 金融におけるミスのコストは、IT開発の場合よりもはるかに高くなります。 そのため、実験よりも数学に基づいたかんばんの方がより価値があり、小さなながらも絶え間ない変更を通じてワークフロー全体を改善することができます。

テレコムかんばんも適しています。 業界の開発ベクトルがデジタル化だからという理由だけで。 ただし、これまでのところ、具体的にどのように見えるかを理解している人はほとんどいません。 さらに、テレコムでは、作業の「高速」部分（ソフトウェア開発）が「低速」部分（ハードウェアインフラストラクチャのサポートと開発）に隣接しています。 したがって、スクラムで行われた実験とともに、かんばんを使用して現在のプロセスを進化的に加速することは理にかなっています。





さまざまな業界で採用されているアジャイル開発プラクティス。 複数のアイテムを選択できるため、金額は100％に等しくありません。 画像/スクラムトレック



-そして、モバイル開発者はどうですか？ アジャイルにはモバイル開発の仕様がありますか？



私の観点から見ると、モバイルアプリケーションを開発する際の主な難題は、アプリケーションの要件を特定することです。なぜなら、利害関係者を特定することは難しいからです。 これらの問題は、顧客開発を使用して顧客ニーズを調査し、スクラムを使用して製品仮説を迅速にテストすることで克服できます。





一般に、アジャイルはモバイル開発に適しています。さまざまな専門家の迅速な対応、関与、調整作業、結果を迅速に提供し、必要に応じて変更する能力が必要です。



ここでは、スクラムに加えて、モバイル開発アプローチに直接焦点を当てて使用できます。 たとえば、Mobile-DはXP、Crystal、およびRUPに基づいています-アプローチは非常に古く、確立されています。 Mobile-Dとスクラムの主な違い：明確なフェーズの存在と製品開発のエンジニアリング側の主な焦点。 スクラムは製品の管理と提供により注意を払っていますが、Mobile-Dは製造プロセスに焦点を当てており、最終製品の品質を大幅に向上させるXPプラクティスを含んでいます。 同時に、RUPの影響も影響を受けるため、プロセスは非常に形式化されています。



モバイル開発に対するもう1つの最も現代的なアプローチは、スクラムとリーンシックスシグマを組み合わせたSLeSSです。 最初に、彼はスクラムワークフローの設定を実装し、次にリーンシックスシグマアプローチを統計的品質管理に適用します。 SLeSSは、必要な柔軟性と統計に基づく情報に基づいた意思決定のメカニズムを組み合わせているように思えます。



同時に、スクラムガイドは、製品開発に役立つ可能性のある他のアプローチやツールをスクラムワークフローに含めることを最初は禁止していません。 したがって、上記のすべてを「クラシック」スクラムのフレームワークで実装できます。



-特定の条件下での修正の方法論はどの程度柔軟性がありますか？



スクラムとかんばんを別々に考慮する必要があります。



スクラムはフレームワーク、つまりフレームワークであり、そのすべての要素（イベント、ロール、アーティファクト）が必要です。 捨てることはできません。 しかし、これらの要素をどのように正確に実装するかについての厳密な要件はありません-必要に応じて実行してください。 また、スクラムは、会議、アーティファクト、作業する必要があり、プロセスをスピードアップするために必要な役割など、新しい要素の追加を禁止していません。



かんばんは、ツールとメトリックのセットです。 彼は既存のシステムの長い進化の変化に対応するように設計されているため、どの特定のツールとどの組み合わせを使用するかについての厳密なガイドラインを示していません。 しかし同時に、かんばんの成功は、作業プロセスに関するデータの収集と定期的な分析によって決まります。 これを行わないと、時間が経つにつれてすべてが消滅し、それ以上の改善はありません。 しかし、それは大丈夫です。エドワード・デミングが言ったように、あなたは変える必要はありません。生存は任意です。



-スクラムがビジネスを行う際の典型的なミスは何ですか？



柔軟な方法論を実装する際の主な間違いは、ツールを具体的に使用する理由を理解せずにツールを使用することです。



たとえば、大規模な組織では、スクラムを実装するときに、プロジェクトマネージャーの名前を製品の所有者に、プロジェクトチームをスクラムチームに変更し、2週間で完成した結果を要求することがよくあります。 しかし、これは機能せず、非常に単純な理由により、スクラムが機能する条件が満たされていません。

• プロジェクトマネージャーはプロダクトオーナーと呼ばれていますが、必要な権限を受け取っていないため、プロダクトビジョンを策定したり、実装の優先順位を変更したりする権利はありません。 前と同じように、彼はすべてのステップをリーダーシップと調整することを余儀なくされ、作業のタイミングと量の要件の枠組みにとらわれています。 そのため、意思決定の速度は同じままです。 変化する条件への加速または適応なし。
• プロジェクトチームはスクラムチームと呼ばれていましたが、プロジェクトチームに含まれる人々は各部門にリストされ、ラインマネージャーに直接報告できます。 したがって、各チームメンバーはまず、プロダクトオーナーではなく、ラインマネージャーに任せます。 その結果、製品タスクの優先度は常に低くなります。つまり、スクラムチームが「組み立てられる」製品実装の速度はまったく向上しません。
• おそらく、以前と同様に、チームメンバーは他のプロジェクトで忙しいでしょう。 スクラムは次のように直接述べています。チームメンバーは、作業時間の100％をスクラムチームに割り当て、プロダクトオーナーがリードする製品のみを処理する必要があります。 人々がプロジェクト/製品間で「割合で分けられている」場合、彼らはそれらを切り替えます。これにより、特定のプロジェクト/製品に対する作業の関与と有効性の両方が大幅に減少します。

このような不適切な「実装」には多くの否定的な結果がありますが、それらはメカニズムを再現しようとする試みから始まりますが、スクラムの本質ではありません。 スクラムの実装における主な誤りは、CodeFest 2017カンファレンスでの私のレポート「 Stop Signals for Agile 」で詳細に説明されました。



-社内での柔軟な方法論の導入方法を評価する方法



スクラムオープンテストがありますが、理論的知識のテストとしてより役立ちます。 実際に何が起こるか、彼は理解していません。 スクラムの基礎はチームワークであり、その優先順位は製品の配送速度と消費者にとっての価値であることを考えると、 360の調査が最も適切です。 したがって、チームの成熟度と顧客満足度を確立する方が信頼性が高くなります。



ScrumTrek診断ツールサービスで実装された独自の方法論を使用します。 彼女はそのように働いています。 チームとそれ以外の関係者には、チームの相互作用のレベルの評価、作業の計画、顧客に提供される結果の価値、他のチームとの相互作用などについて一連の質問が行われます。 各パラメーターについて、意見の中央値が計算され、複雑な円グラフが作成されます。レーダーは、チーム内と外部の両方からの外観を表示します。





レーダースクラムトレック。 評価の散布図を見る





レーダースクラムトレック。 中央値を見る



図には多くの有用な情報が含まれています。

• 個人の原子推定値とその平均値はそれ自体興味深いものであり、ここでは説明は不要です。
• チーム内の成績のばらつきは興味深いものです。 非常に大きい場合、チームとしての私たちの仕事の1つまたは別の側面が意味するものに同意する理由があります。 たとえば、「顧客価値」とはどういう意味ですか？ そして、「配信速度」はどうですか？ 大きな広がりは、チームが多くの問題について単一のポジションを形成していないことを示しています。

小さな広がりは、コンセンサスと優れたチームワークを示しています。

• 評価は分類されます。 文化はすべて順調ですが、場所によっては生産性が低下していることがわかります。 「掘る」場所は明らかです。
• チーム内外での評価の違いは最も重要な指標の1つであり、顧客と他の利害関係者のチームからの期待とチームがそれ自体をどのように認識しているかの違いを示します。 アジャイルは、ビジネスと製品を販売する人との間の密接な相互作用に関するものであるため、これらの不一致は、これら2つの領域間の「クロックをチェック」し、チームの再構築方法に同意する優れた理由です。

データを収集した後、チーム全体と利害関係者の関与を伴うチャートの分析が必須です。 チームの作業が異なる角度からどのように見えるかを示し、分析の結果を具体的な手順に処理して作業を改善するためのすべて。

スクラム実装チームについて

-会社は誰からアジャイル開発方法論の実装を開始すべきですか？



スクラムの実装は常にビジネス目標に基づいています。 したがって、顧客は、内部または外部の加速について最初に考える必要があります。 次に、繰り返し実行できるように、製品の概念を練る必要があります。 そして、チームを結成するだけです。 スクラムのためのスクラムは機能しません。 さらに、特定の問題を解決するには費用がかかりすぎる可能性があります。



会社の「アジャイルガイド」となるのは、唯一の正しい答えのない質問です。 テクニカルディレクターが変化の「刺激者」になるのを見ました。 イニシアチブがビジネスからもたらされたケースがあり、そのようなイニシアチブが「下から」どのように発生したかを見ました。 それはすべて、その人のエネルギーとモチベーション、柔軟なアプローチを使用した開発のビジョンを製品またはユニットのビジネスコンテキストに組み込むことができるかどうかに依存します。



イニシアチブがトップマネジメントから来る場合に理想的です。 この方向の進歩はロシア市場で顕著です。



-柔軟な方法論の導入により、組織またはチームでどのような新しい役割と機能が生まれますか？ どれが必須で、どれがオプションですか？



スクラムの場合、これらはスクラムマスター、製品所有者、開発チームの役割です。 それらはすべて必須です。 開発チームは、開発者だけでなく、製品を原則として表示する必要があるすべての人（アナリスト、デザイナーなど）も結合するため、開発チームも「役割」と見なされます。



結果の責任はスクラムマスターまたは製品の所有者にありますが、スクラムマスターおよび製品の所有者には、職務の一部を引き継ぐアシスタントがいる場合があります。



製品の所有者は、多くの場合、ビジネスの人です。 ただし、必ずしもそうではありません。たとえば、生産用の何らかのエンジニアリングソリューションを作成する場合、この役割はチーフエンジニアが果たすことができます。 最終的に、これは私たちが製品を作っている消費者、そもそもどのような問題を解決するか、製品を作成するときに優先順位をどのように構築するかを最もよく理解している人です。 製品所有者が、市場および消費者からのデータに基づいて製品の構成を独立して決定する権限を持っていることが非常に重要です。 彼は、彼が対話する利害関係者にノーと言う権利を持っているべきです。 これは、優先順位が合意され、迅速に決定が下されるようにするために必要です。



スクラムマスターは、強く、団結し、責任を持ち、理想的には自己組織化されたチームを作ることを任務とする人物です。 重要なのはチームリーダーではない 、つまりリーダーではない。 スクラムマスターは、ガイダンスを提供したり、製品開発に直接介入したりすることはできません。 彼はオーガナイザー、ファシリテーター、コーチ、アジャイルプラクティショナーです。 私の経験では、最高のスクラムマスターはプロジェクトマネージャーから取得します-彼らが訓練され、指示形式からコーチングに移行することができれば。





コミュニケーションのコーチングスタイルといえば。 アジャイルコーチもいます。 彼の仕事は、ワークフローを設定し、人々を教育し、アジャイル内での日々の活動のためのツールを提供することです。 競合解決ツールを含む。 他のすべてはその範囲を超えています。 理想的には、アジャイルのコーチはすべてが独自に機能するようにチームまたは部門を設定する必要があり、アジャイルのコーチはもはや必要ありません。



移行期間は常に不快感に関連付けられています。 アジャイルコーチは、チームが最小限の摩擦でこの期間を通過し、新しい-便利で効果的な-作業方法を開発できるように設計されています。



たとえば、 SAFeフレームワークで説明されているように、スケーリングの際に追加の役割を導入できますが、それでもスクラムマスターまたは製品所有者の参照条件と作業原則に基づいています：製品に関する階層レベルは単に表示されます。





-プロダクトオーナーとスクラムマスターの機能は、「理想的な世界で」どのように差別化されていますか？



スケールの一方には、製品所有者が代表するビジネスの利益があり、もう一方には、スクラムマスターが責任を負うチームの活力と有効性があります。 チームが結果を迅速に達成するには、システムのバランスが取れている必要があります。 製品の所有者が「ピンチ」すると、チームは夜と週末に働き、すぐに彼はうまく調整されたチームではなく、一握りのやる気のない、関係のない人々に直面します。 スクラムマスターが自分の上に毛布を引っ張った場合、開発は不安定でもスワスでもなく、絶え間ない紛争と必要以上に長くなります。





-前述の役割のいずれかを引き受けようとしている人にとって、どの方法論と管理モデルを習得する価値がありますか？



ビジネスのコンピテンシーに関しては、ステージごとに優先順位を決定し、チームとより密接にやり取りする必要があることを除き、通常の管理と同様にすべてが「古典的」です。



製品の所有者は、リーンスタートアップ、顧客開発、および製品を作成するための他の現代的なアプローチを学ぶ必要があります。



スクラムマスターにとって、能力の範囲はより広くなります：円滑化、紛争解決、グループダイナミクス、コーチング、そしてもちろん、アジャイルプラクティス。 むしろ、これらは心理学の分野のスキルであるため、マネージャーをトレーニングする際にその不足が感じられます。



-コードの共同所有権により、スター開発者への依存度は本当に減りますか？ 彼らのモチベーションは低下していますか？



柔軟な方法論がなくても、コードの一括所有は可能です。 十分なコードレビュー契約とその他の正式なルール、および開発者は原子的に行動できます。



多くの場合、会社自体がエンジニアの「恒星」的な行動を引き起こします。一見したところ、中小農民のチームを編成し、エラーによるリスクを体系的に減らし、プロフェッショナリズムを高めるよりも、結果に対して全責任を負い、スーパースペシャリストに任せて全方向を彼に任せる方が、一見有利です。



これはジレンマです。短期的または長期的な成功です。 「スター」を雇うことはビジネスに良いようです。 しかし、そのようなプロが入社してから3年後、5年後、7年後にはどうなるのでしょうか？ 彼は不可欠になります。 そして、少なくとも3つのマイナスの結果があります。



第一に、そのような人にはほとんど自由時間がなく 、会社は概して無関心です。 彼女の論理：「あなたが休めるように、私たちはあなたに多額の給料を支払っていません。」 同様の状況に陥ると、人々はすぐに燃え尽き、皮肉に陥り、自分の立場から最大限の利益を得ようとします。



第二に、かけがえのない従業員が会社の優先事項に燃料を供給し始めます。 事業計画を具体化する代わりに、何が必要で何が不要であるかを独自に決定できます。 そして、彼に影響を与える手段はありません 。数年間、彼は製品とシステムについてすべてを学びました 。そして、恐ろしいことに、原則として、他の誰も彼を知りません。 そのような専門家は、解雇または低賃金に対する保険としての知識、専門知識を慎重に保護します。



第三に、そのような人の業績は「スケーリング」できません 。 開発チームの拡大を計画している場合は、大きな転換期に備える必要があります。経験や知識を共有することは「オールディーズ」にとって有益ではないため、新規参入者は引き裂かれ、ヘイズは2色になります。 また、開発を加速することは不可能です。すべてに満足し、何も変えない、誰もがかけがえのないVasya Pupkinのパフォーマンスにすべてがかかっています。



-チームアプローチに移行するには何をすべきですか？

• 現在の「スター」チームの一部を必然的に失うリスクを受け入れます。すべての人が新しいアプローチに同意するわけではありません。 これは避けられません。
• 報酬の構造を変更します。 たとえば、ドキュメントの作成や新入社員のトレーニングにボーナスを導入し、徐々にボーナスになるようにします。
• 「スター」の中に成長したい人を見つけて、彼らが管理、促進、コーチングのスキルを習得するのを助けます。 それらに新しい視野を開きます。 誰もがこれに同意するわけではありません。 しかし、同意する人は、新しい仕事の原則を最もよく支持する人になります。
• かすみの文化を侵食する。 たとえば、「星」を通常の環境から引き離すこと、「1人の老人に対して4〜5人の新人」という原則に基づいて新しいチームを形成することを含みます。 さらに、このようなチームでは、賢明で熟練したスクラムマスターを任命する必要があります。彼は、「老人」に彼を脅かすものがないことを明らかにし、同時に「新人」を設定して、彼らよりも詳しい人を尊重します。 。 そして、そのようなチームが「老人」が働いていた場所に座っていなければいいのです。

私たちは企業文化の変革を扱っていることを忘れないでください。これは大変な作業です。 ピーター・ドラッカーが言ったように、「文化は朝食戦略を食べています。」 どんなに洗練された形式化された戦略を提案しても、人々が適切な行動を「採用」しない限り、それを実装することはできません。 この問題をよりよく理解するために、ダニエル・ブラウンとイツケ・クレイマーの本「 企業の部族 」を読むことをお勧めします。 人類学者がトップマネージャーに教えることができるもの 。」



この資料は、 Mail.Ru Cloud Solutionsチームによって準備されました。