アジャイル カルチャを導入する

過去 10 年間の「アジャイル変革」から学ぶべき教訓が 1 つあるとすれば、アジャイル アプローチの採用または実装に万能の解決策はないということです。 どの組織もそれぞれ異なるニーズ、制約、および要件を持っています。 盲目的に処方箋に従っても成功にはつながりません。

アジャイル運動は、ソフトウェア構築の実践を改善する方法を継続的に見つけることです。 それは完璧な毎日のスタンドアップや振り返りに関するものではありません。 代わりに、正しいことが頻繁に起こる文化を作り出すことが重要です。 スタンドアップや振り返りのような活動にはそれなりの役割がありますが、組織の文化を変えることはできません。

この記事では、すべての組織がアジャイルの考え方と文化を構築するために必要な基本要素について詳しく説明します。 推奨事項は盲目的に従うべきではありません。 推奨事項は盲目的に従うべきではありません。

スケジュールとリズム

完璧なスプリントの長さはありません。 チームは 1 ～ 4 週間のスプリント期間で成功を収めています。 最も重要なのは一貫性です。

組織の文化、製品、および最新情報を提供したいという要望に応じて、スプリントの長さを選択してください。 たとえば、Microsoft の開発者ツール部門 (約 6,000 名) は 3 週間のスプリントで作業しています。 リーダーシップ チームがこのスプリントの長さを選択したわけではありません。 それはエンジニアリング チームからの直接のフィードバックから生まれました。 部門全体がこの 3 週間のスプリント スケジュールに基づいて運営されています。 それ以来、スプリントは組織の心臓となっています。 これで、すべてのチームが同じ太鼓のビートに合わせて行進します。

スプリントの長さを選択し、それを継続することが重要です。 複数のアジャイル チームがある場合は、すべてのチームが同じスプリント長を使用する必要があります。 フィードバックが変化を促す場合は、積極的に受け入れてください。 それは適切な用語が定められたときに明らかになるでしょう。

配送の文化

Microsoft のプリンシパル グループ プログラム マネージャーである Peter Provost 氏は、「出荷をごまかすことはできません」と述べました。 このステートメントのシンプルさと真実は、アジャイル文化の基礎です。 Peter が言いたいのは、ソフトウェアを出荷することで、実際にソフトウェアを出荷しないと理解できないことや理解できないことを学べるということです。

人間の性質として、絶対に必要になるまで、物事を遅らせたり避けたりするものです。 ソフトウェア開発に関しては、これがまさに当てはまります。 チームはバグをサイクルの最後までパントし、必要になるまでセットアップやアップグレードについて考えず、ローカリゼーションやアクセシビリティなどは可能な限り避けます。 このパターンが現れると、チームは後で支払う必要がある技術的負債を蓄積します。 発送にはすべての借金の支払いが必要です。 送料をごまかすことはできません。 アジャイル文化を確立するには、各スプリントの最後に製品を出荷することから始めます。 最初は簡単ではありませんが、チームがそれに挑戦すると、起こっているはずなのに起こっていないすべてのことがすぐにわかります。

健全なチーム

完璧なアジャイルチームを作るためのレシピはありません。 ただし、いくつかの重要な特性により、成功がはるかに簡単になります。

可能な限りチームを同じ場所に配置する

さまざまな地域に散らばる人々とともにチームは成功を収めることができるでしょうか? はい、でもそれはもっと難しいです。 人々が同じ場所にいて同じ部屋に座っていると、適切な会話が生まれる傾向があります。 世界中のさまざまなタイムゾーンに拠点を置くチームでも成功する可能性はあります。 しかし、それらの障害がすべてなければ、同じチームが有利になるのではないでしょうか?

妥当な期間、チームを無傷に保つ

チームが一緒にソフトウェアを構築する技術を習得できるようにします。 チームがスクランブル状態になると、チームが築いてきた化学反応が崩れてしまいます。 組織を再編成することが適切な場合もありますが、チームは通常、協力する方法を学ぶ時間を与えられたほうが生産性が高くなります。 ガイドラインとして、少なくとも 12 か月間はチームをそのままの状態に保つようにしてください。

人ではなく仕事の負荷を分散する

時にはチームが遅れをとり、助けが必要になることがあります。 これに対処する一般的な戦術は、あるチームから別のチームに人材を貸与することです。 ただし、それは逆効果になる可能性があります。 より良い解決策は、チーム間で人員の負荷を分散するのではなく、別のチームに作業の負荷を分散することです。 一方のチームから別のチームを助けるために人を引き抜くと、両方のチームに混乱が生じ、一時的であっても異動させられた人はイライラする可能性があります。 これらすべてがチームの生産性に影響を及ぼし、おそらくスケジュール通りに戻る能力に悪影響を及ぼします。

人の代わりに負荷分散作業を行うことで、すでに確立されているチームが介入して支援できるようになります。 それは人についての会話ではなく、優先事項についての会話になります。

アーキテクチャのレイヤーではなく、チームが機能領域を所有できるようにする

機能分野を所有する垂直チームの構築に努めてください。 これらのチームは、データベースからユーザー インターフェイスの変更に至るまで、自分たちの領域に機能を追加するために必要なすべての作業を担当します。 チームには、エンドツーエンドのエクスペリエンスを提供し、所有する権限が与えられます。

水平チームがアーキテクチャのレイヤーを所有している場合、エンドツーエンドのエクスペリエンスに責任を負う単一のチームはありません。 機能を追加するには、複数のチームが調整する必要があり、より高いレベルの依存関係管理が必要になります。 バグを解決するには、複数のチームがバグ修正に必要なコードを所有しているかどうかを調査する必要があります。 チームがそれが自分たちのバグではないと判断し、別のチームに割り当てるため、バグはやりくりされます。

フィーチャーチームにはこうした問題はありません。 所有権と責任が明確です。 アーキテクチャベースのチームが参加できる場所があるかもしれません。 ただし、垂直方向に焦点を当てたチームはより効果的です。

次のステップ

チームが独自のアジャイル変革に着手するときは、これらの基本原則を念頭に置いてください。 すべての組織に適用できる単一のレシピはないことに注意してください。 アジャイル変革は旅です。 変化を起こし、そこから学びましょう。 時間が経つにつれて、組織は必要なアジャイル文化を発展させていきます。

Microsoft は世界最大のアジャイル企業の 1 つです。 詳細については、Microsoft が DevOps 計画にアジャイル文化をどのように採用したかをご覧ください。

Azure DevOps によってチームがアジャイル文化を採用し、拡張できるようになる方法について学びましょう。