agile - アジャイル（スクラム）の採用-どうでしたか？

Question

組織にスクラムを実装したことのある人にとって、最大の障害は何でしたか。それを克服した場合、どのようにしたらよいでしょうか。

Answer 1

背景: 2006 年に、私が入社する数か月前にスクラム コールド ターキーを採用した大企業と契約しました。同社は、アジャイル/スクラムが巨大なエンタープライズ ソフトウェア製品を救うことを望んでいました。そこにいる 100 人以上のプログラマーのうち、私は約 12 人のチームと 1 年間緊密に連携し、彼らのアジャイル実験を観察し、参加しました。

まとめ: 私は、アジャイルは害よりも役に立ったと信じています。年末までに、チームは機能を一貫して見積もって作成できるようになりましたが、以前は生産性がかなり不安定でした。

実装: これは大きな組織と大きな製品であったため、プロジェクトは「スクラム オブ スクラム」として実行されました。約 15 人から 20 人の開発者ごとに 1 人のスクラム マスターが存在し、これらのチームは反復のために約 6 人から 8 人の小規模で緊密に連携するスクラムに分割されることがよくありました。チームは大部分が独立しており、イテレーションの頻度を独自に調整でき (1 か月から 1 週間まで)、アジャイルを最適な方法で実装するための多くの柔軟性が与えられました。同社は定期的にアジャイル コーチ (Object Mentor など) を招いて、スクラム マスター、チーム、および管理者のトレーニングを支援しました。

障害物：たくさん。アジャイルに関連するものもあれば、そうでないものもあります。順不同で学んだ教訓を以下に示します。

製品のバックログは、最初はあまりにも頻繁に修正されました。最終的に、チームと経営陣はすべての機能を調べ、見積もり、優先順位を付けるのに数日かかりました。大当たりでしたが、大変お世話になりました。得られた教訓: 製品のバックログを早期に整理し、維持します。製品の所有者は、自分が何を望んでいるかについて明確な考えを持っている必要があります。

私たちは流行や誇大宣伝を試したり対処したりするのに時間を費やしました。始めたばかりの頃は、自分のやり方が正しいかどうかを知る方法がありません。アジャイル プロセスを常にいじって、製品から焦点を外したくなる誘惑があります。教訓: 経験豊富なアジャイル コーチを持つことは、この学習曲線を短縮するのに役立ちます。どんな実験にも反対する人が必ずいるはずです。「スパイク」の数を制限します。

優れたスクラム マスターは非常に貴重です。確かに最初は正社員です。

時間がかかる。チームがこのプロセスに慣れるまでに数か月かかりました。

あなたの戦いを選んでください。一部のプログラマーは当然懐疑的であり、他のプログラマーは完全に嫌い、変更を逃れます。ある程度の柔軟性を考慮してください。たとえば、製品のバックログとイテレーション スケジュールの使用を強制しますが、全員がノート カードを使用する必要はありません。ペア プログラミングやテスト ファースト開発などのツールやプログラミング手法の導入には、特に注意を払ってください。

最後に、コミュニケーションをオープンに保ち、期待を管理します。

幸運を！

Answer 2

数年前に Delphi 開発者として働いていたとき、私はしばらくの間、開発チームにスクラムを採用させることができました。

プロセス全体は私たちにとって非常にうまく機能しました.バックログで優先順位の高いタスクをチームに見積もってもらうことで、目標とする有意義な時間枠が得られ、「管理の仕事は障害を取り除くことです」全体が素晴らしかった.

最大の問題は、このプロセスが常に「Bevan の優れたアイデア」として認識され、言及されていたことです。

チームは私たちが得た価値を高く評価し、喜んでスクラムを継続しましたが、チームはスクラムの方法論を独自のものとして採用しませんでした。しばらくすると、私は「プッシュ」することに飽きてしまい、スクラムのアプローチに従うことから「脱落」しました。

教訓:チームがスクラムを取り入れ、アプローチを所有していることを確認してください。

Answer 3

アジャイル（SCRUM-管理とXP-エンジニアリングプラクティスのセット）を、高度に統合された環境で大規模なプロジェクトを伴うウォーターフォールである環境に実装しました。滝の警察はいたるところにいました。ご想像のとおり、多くのプロジェクトが失敗しました。以前の雇用主でアジャイルを行った後、プロジェクトのアジャイルを試す許可を得ました。

チームの内部では、アジャイルプラクティスを使用しました。外部的には、アジャイルプラクティスをウォーターフォールプロセスでラップしました。これは主にレポートを意味します。このように、私たちは滝のプロジェクトのように外から見ました。しかし、大きな違いがありました。社内ではアジャイルを使用していたため、予算内で高品質で時間どおりに納品しました。

重要な成功要因は、組み込みコーチ（イテレーションマネージャーコーチ、開発リードコーチ、テストリードコーチ、およびソリューションアナリストコーチ）でした。高度に統合された環境では、依存システムからのコミットメントを事前に確保する必要がありました（依存システムとそれらのシステムに必要な作業を特定するために先を見越して行う必要があります）。開始する前に、チームの技術メンバーとビジネスメンバーをアジャイルブートキャンプに浸しました。これにより、主要なプレーヤー（製品所有者と技術チーム）がそこでの役割を認識し、効果的に実行できるようになりました。最後に、プロジェクトをウォーターフォールレポートでラップすることで、企業内の既存のすべてのレポート構造に結び付けることができました。

最終的な結果として、同社は現在、ウォーターフォールプロジェクトをアジャイルに移行しています。これはすべて、持続可能なペースで高品質のソフトウェアを提供できたためにのみ可能です。

Answer 4

私たちは主にお客様のサイトでスクラム プロジェクトを行います。私の経験で最も難しいのは、顧客組織で優れたプロダクト オーナーを見つけることです。

• 自分がプロダクトオーナーになるべきだと思っている人が多すぎます。
• プロダクト オーナーはチームのペースについていくのに苦労している
• プロダクト オーナーは、チームが必要とするすべての詳細情報を入手するのに苦労しています
• アイテムを製品バックログの下に移動して、優先度の高いものを追加することは困難です
• 等

スクラムを使用するように内部チームをトレーニングすることは実行可能であり、独自のスクラム マスターを導入することも実行可能ですが、優れたプロダクト オーナーはクライアント組織の一部である必要があります。この外部の人を訓練することはより困難です。顧客のプロダクト オーナーと一緒に働く代理プロダクト オーナーを持つことは、大きな助けになります。

Answer 5

すでに述べたように、私も経験した最大の問題は賛同を得られないことです。このプロセスに人々が真に帰属するようになることは非常に困難です。

もう 1 つの問題は、上記の問題に直接寄与するものでもあり、アジャイルの創設原因の大きな部分を占めているのは、アジャイルのマニフェストのアウトラインに固執する管理の欠如です。

スクラム、リーン、または使用しているアジャイルのどのバージョンでも、マニフェストのポイントから抜け出すことはできません。これらの優先事項から脱却するためにプロセスが使用されている場合、ほとんどの場合、経営陣が失敗し、賛同が崩壊します。マニフェストに従わなければなりません:

マニフェスト：

• プロセスとツールを介した個人と相互作用
• 包括的なドキュメントよりも動作するソフトウェア
• 契約交渉におけるお客様の協力
• 計画よりも変化への対応

いくつかのシナリオは、何らかの理由で上記のプロセスのいずれかからガント チャートが表示される場合です。ガント チャートは便利な場合がありますが、開発者が経営陣と一緒にガント チャートを突然レビューしている場合は、最後のポイントが壊れています。変化よりも計画の奨励が支持されているため、変化への対応が遅れています。代わりに、付箋付きのボードを使用する必要があります。現在作業中のアイテムとバックバーナー アイテムのみを使用して、ボード上にあるものを単純化します。これにより、変更が容易になります。「ツール」で何かが固まると、変更への応答が遅くなります。確かに、管理者は何らかの方法で物事を記録および追跡する必要がありますが、それを開発に押し付けることは、変更への対応を遅らせるだけであり、ツールを開発者に押し付けることは (開発のためにそれらを必要とし、適切に利用できる場合を除きます)、最初の点を台無しにします。

別の方法として、包括的なドキュメントを作成する目的で開発を停止しないでください。開発者が 1 人しかいない場合を除き、誰かが開発の役割から自律的にドキュメントの負荷を引き受ける必要があります。これらのものを一緒に押し込むと、開発が大幅に遅くなり、一定期間、実際に動作するソフトウェアを取得するためのすべての作業が停止する可能性があります。

最後のポイントは、顧客または見込み客と常に何らかの形で連絡を取り合うことです。彼らが何を望んでいるかについて、彼らと定期的に話し合ってください。毎日彼らと話し、できる限り多くの UI やデータ フローの作業を見せてください。彼らが理解できるものは何でも見るべきです。彼らと話し、アプリケーションに組み込まれるアーキテクチャとアイデアについて教育し、彼らのためにアプリケーションを構築していることを決して忘れないでください。

概要：

最大の問題は賛同です。2 つ目は、経営陣がマニフェスト ガイドラインに固執していることです。

この 2 つのリスクを軽減できれば、問題ありません。同意を得て、真に強力で、ミクロではない管理マネージャーになる必要があることを経営陣に理解してもらった後は、他のことは簡単です。具体的には、マネージャーがリーダーになる必要がある場合や、別のスタイルの役割を担う必要がある場合もあります。

...あまり的外れでないことを願っています。:)

Answer 6

私はいくつかのプロジェクトでスクラムを実行しています。私が思うに、最大​​の問題は、組織内の全員がプロセスに参加しているわけではないということです。誰もがコミットする必要があります。開発者チームだけではありません。多くの場合、マネージャーはプロセスを開始し、何もしなくても状況が改善されることを期待する人物です。

私の提案は、組織全体でワークショップを実施して、全員がプロセスの仕組みを理解できるようにすることです。開発者だけではありません。プロセスに本当に夢中になっている人がいることが不可欠です。チームや組織の疑問に答えられる人。メンター。

アジャイルであることは、変化を歓迎することです。プロセスが理にかなっているのを許してはいけません。組織に役立つことを行いますが、何かを捨てる前にプロセス全体を試す必要があります。

Answer 7

アジャイルを最初から採用している会社から、伝統的な方法論に従う別の会社に移りました。

おそらく、私が見た最大の違いは、2 番目の会社が優先順位を付けるのに苦労していることです。各人のプレートには非常に多くの作業があり、時間通りに納品できません。IMO、アジャイルは状況にある程度の透明性をもたらし、チーム全体で優先順位を付けることができます。

アジャイルの世界のスクラム マスターは、消火活動を担当し、(スプリント) チームの声になります。実際、最初の会社 (スクラム マスターとプログラム マネージャーが別々にいた) では、プログラム マネージャーが経営陣に虚偽の約束をした場合、スクラム マスターはプログラム マネージャーと争っていました。つまり、スクラム マスターは、数回のスプリント後にチームがどれだけ生産/提供できるかを知っているため、チームの予測可能性を特定するのに役立ちます。

また、R&D リソースは、各サイクルの終わりに達成感を持ち、次のサイクルを楽しみにしていることにも気付きました。ただし、優れたプロジェクト マネージャーであれば、従来のシナリオでもこれを行うことができます。

Answer 8

私が働いている場所では、しばらくの間スクラムを使用していますが、いくつかの段階を経たようです。障害に関して言えば、1 つの部分は、一度に多くの変更を加えるのを防ぎ、ゆっくりと物事を紹介することです。たとえば、1 週間は毎日のスタンドアップを行い、2 週間後にはストーリー ボードを行い、2 週間後にはペア プログラミングを行います。 . これにより、たまたま機能するさまざまな調整が可能になり、変更によって状況が改善された場合、これはいくつかの良い勢いを築くのに役立ちます. もう 1 つのポイントは、何かが行われる方法に変更があった場合、修正される人が軽視されたり嘲笑されたりしないようにすることです。時にはこれは、誰かの邪魔をしたり、「基本に戻れるか?」ということを意味する場合もあります。

コンサルタントを連れてきたことは、IMO で行われた最高のことの 1 つです。さて、これらの人たちは、ここで開発がどのように行われたかを進化させるのを助けるためにやって来ました. ペア プログラミング、TDD、壊れたウィンドウなどの概念の導入、プロジェクト フォルダーの整理、テスト用のモックの導入はすべて優れた追加機能であり、自分たちでそこにたどり着いたかもしれませんが、うまくいかないほど長い時間がかかった可能性があります。とてもよく出ます。