どのプログラミング方法が私たちに適しているでしょうか？

残念なことに、誰かが私たちの経営陣に「アジャイル」という言葉を教えてくれました。私は（原則として）アジャイルの周辺的な理解を持っていますが、実際にアジャイルを使ったことはありません。私が知っていることから、それは私たちの組織によく合いません。今のところ、物事はかなり不潔です。その方法は次のとおりです。

私たちは非常に小さなチームです。2人の開発者、1人のDBA、1人のデザイナーです。私が働いている会社は、その規模に比べて不釣合いに多額のお金を稼ぎ、その95％近くが純粋なオンライン販売です。

開発の観点から、私たちは通常の日に多くのデスクの侵入を受けます（私たちは技術サポートであり、開発者でもあります）。営業チームのメンバーが誰かに何かを約束した場合、すぐに定期的に仕事が空から落ちます。私たちはより大きなプロジェクトにも着手していますが、それらは絶え間ない中断を伴う悪夢です。私たちの何人かは私たちの髪を引き裂き始めています！プロジェクト計画は、技術担当でない管理者がExcelスプレッドシートで作成します。そこでは、タスクを一口サイズの文に分解して、理解し、それぞれの横に日付を入れます。これらの日付は常にひどく非現実的で見逃されることが多く、私たちのミーティング（毎週開催）には、「なぜこれがまだ行われていないのか」と人々が尋ねる厄介な瞬間が定期的にあります。

アジャイルは私たちにとっては間違いないと思います。今、（そして私が試した）この会社はその方法を変えないことを考えると、開発チームだけが喜んで変更しますが、採用することができる開発方法論はありますか？

アジャイルは、実際にあなたが抱えている多くの正確な問題に対処するように設計されています。経営陣が本当に賛同し、プロセスを歪めない場合、大きな改善を見ることができます。ポイントごとに問題に対処しましょう。私の経験はスクラムに関するものなので、その観点から話をしますが、他の実装にも同様の利点があると確信しています。

• 空から落ちる仕事これらの話は、製品所有者とチームが会議を進めて合意するまで、バックログの一番下に置かれます。その優先順位は、チームの他のすべてのコミットメントに関連して決定され、その優先順位は、関心のあるすべての利害関係者に表示されます。スプリントの途中で新しい機能を追加することは非常にまれであり、スプリントを中断できるのは最も優先度の高いバグのみです。来週の終わりまで定期的に予想される「緊急事態」がどれだけ多く待っているかは驚くべきことです。
• 大規模プロジェクトの実施短期的な優先事項が長期的なプロジェクトに与える影響を示す可視性が得られます。人々があなたの長期プロジェクトの前でユーザーストーリーを絶えず動かしているなら、その決定を下すために誰もがそれが長期プロジェクトのスケジュールに与える影響を知っているでしょう。
• プロジェクト計画は非技術マネージャーによって作成されますユーザーストーリーは非技術的な観点から書かれているはずですが、スクラムチームは見積もりを行い、実装の詳細を決定する権限を与えられるべきです。
• 日付はひどく非現実的ですあなたのチームはすべての見積もりを処理します。なぜならあなたはあなたが何をしているのかを知っているからです。これらの見積もりがビジネスに受け入れられない場合、機能を優先する方法を決定する必要があります。彼らがあなたが扱うことができるより多くの仕事を必要とするならば、より多くの人々を雇う必要性ははっきりと見えるでしょう。
• 日付が見落とされることがよく あります最初に、見積もりがより現実的になります。また、小さなチャンクを噛み締めて実際に仕上げているため、機能が完全ではなくても有用なものを作成したように感じられます。
• 厄介な瞬間に満ちた会議 アジャイルには、製品の所有者が深く関わっているため、より多くの可視性とより迅速なフィードバックサイクルがあります。ブロッキングの問題と遅延の理由は驚くことではありません。
• 技術サポートも行っています 一般的な考えに反して、アジャイルは分割されたスケジュールと互換性がありません。スクラムは、チームの速度の中断を考慮します。通常、時間の半分をテクニカルサポートに費やす場合、速度は半分になります。

マネジメントとセールスが認識しなければならないのは、アジャイルは開発チームをより厳密に制御する方法ではなく、チームに自分の得意なことを行う自律性を高め、仕事を割り当てるたびにビジネスがすべての優先順位を現実的に考慮するのを助けることですチーム。

私はあなたの経営者の気まぐれを利用すると言うでしょう！彼らはあなたに好意を与えており、あなたの作業方法を改善するためにいくつかのレバレッジを与えているようです。

彼らにOKと言ってください、私たちは他のものの中で必要なアジャイルに行きます：

• 開発とサポートの分離
• 正式な要件収集プロセス-ITチームの管理下。「ストーリー」などは非常に曖昧に聞こえますが、実際には非公式に見えるようにドレスアップされた「正式な」方法です。
• スケジューリングはITチームの管理下にあります。

彼らがこれを受け入れない場合は、アジャイルに行けないことを伝えます。

アジャイルはプログラミング手法ではなく、アジャイルはプロジェクト管理手法です。上級管理職が本当に見つけたこの新しい流行語を試してほしい場合、彼らはアジャイル手法が上から始まり、あらゆる段階の管理を伴うことを理解できる必要があります。ハードな現実感を与える必要がある場合は、アジャイルに関する30分間のPowerpointプレゼンテーションを開催して、彼らに少しの教育を提供してください。マネージャーはパワーポイントが大好きです。

ただし、あなたが言うように、開発チームだけが変更を希望する人々である場合、開発方法論はあなたを助けることができません。残りの職務を軽減しなければ、中断が発生し続け、単に満たすことができない期限に間に合うように求められ続けます。

このシナリオでの私のアドバイスは、最前線で実際にどのように行われているのかについて、管理者をbeるのではなく教育することです。

営業担当者が日々のスケジュールを決定する組織では、ソフトウェア開発とプロジェクト管理の方法論は役に立ちません。このような混chaとした気晴らしの作業週の中でプロジェクトをどのように管理することになっていますか？

多くの上級管理職はアジャイルの価値を理解し、その利点を望んでいますが、移動が成功したことを確認するために必要な内部的な変更を行うことはほとんどできません。私が知っている唯一の成功したアジャイルショップは、そのように始まっていました。文化の根本的な変化を必要とするため、営業管理またはウォーターフォールソフトウェア開発のショップが移動したという私の専門的な経験では、1つのインスタンスを思い出せません。

文化のこの変化は可能ですか？はい、しかしあなたの場合、ほぼ確実にそうではありません。

文化の変化は通常、競合他社が会社の存在を脅かすか、メイクまたはブレイクの状況、または再編成を正当化する他の同様に関与する状況によって必要になります。あなたの状況では、あなたの会社は、今のお金は簡単で、誰もが太っているという完全に反対の端にいます。

お金が簡単なとき、会社は決して内部から変更しません。 ソフトウェア開発の成功ではなく、ソフトウェア開発の失敗にもかかわらず成功するのはなぜですか。

私の最後のアドバイスは、私があなただったらもっと良いものを探すだろうということです。ここの人々は素晴らしいアドバイスを持っていますが、私はこの歌とダンスを見たことがありますが、あなたの状況ではうまくいきません。

見extremeprogramming.org - XPはあなたが選ぶとアラカルトを選択することができ、容易に理解態様とアジャイルの一形態です。始めるのにとても良い場所

交流中に心を変えないという顧客のコミットメントは、その音からあなたの環境の良い出発点になるでしょう;-)

従来の方法論と現代の方法論の両方を考慮すると、「アジャイル」は方法論というよりも「反方法論」であることがわかります。パターンは、特定のコンテキスト内の特定の問題に対する「ベストケース」ソリューションを描くことを目的としています。このようなソリューションまたはパターンに直接違反する試みは、一般に「アンチパターン」または最悪の場合のプラクティスと呼ばれます。同様に、真のソフトウェア開発方法論は、ソリューション開発のベストケースプラクティスを規定しようとしますが、「アジャイル」（スクラム、XPなど）は、無計画で混oticとし、ソフトウェア開発プロセス内のすべての構造に直接違反しようとしますアプローチ-（最近の）これは、（素朴な）見物人からの拍手も要求しているようです。

そうは言っても、アジャイル哲学が生まれた背景を念頭に置くことが適切です。当時は洗練された反復手法（統合プロセスなど）が存在していましたが、主な手法は依然として古いウォーターフォールアプローチでした。ソリューション。明らかに、このソフトウェア開発への工学的アプローチは賢明ではありませんでした。そして、実行可能なソリューションを見る前に（そして時にはそれまでに）書類の山をもたらしました。

しかし、アジャイルの魔術師の場合のように、お風呂の水で赤ちゃんを捨てることはまだ保証されていません。アジャイルのアプローチは、ソリューションの実際のコーディングを除いて、それ以前に使用されていたもののほとんどを直接否定します。明らかに、これはその発信者側の洞察が限られていることを示しているか、単に「見たくない人ほど盲目な人はいない」という場合です。

それにもかかわらず、アジャイルのメリットは、プロセスの合理化を促進し、実行可能なコードに集中することです。これは必然的に最終的な成果物です。

今、あなたの質問にもっと直接答える：

環境の概要を考えると、まずアジャイル実装（つまり、スクラム、XPなど）を選択することをお勧めします。次に、環境を最適化するためのアプローチをカスタマイズし、チームがどのように機能するかの明確なプロセスを描きます。例：

• ユーザーからリクエストを受信します。

• ユーザーリクエストに優先順位を付けます。

• 既存のシステムに対する強化のゲージの影響（おそらく、毎日/毎週のスタンドアップミーティング中）;

• 各拡張機能の開発時間を見積もる-これらをさまざまな要求ユーザーに伝えます。

• 既存のシステムで実際の拡張を実行します（コーディングなど）。

• ユーザーテストを実施し、要求された変更が正常に実装されたというコミットメントをユーザーから（電子メールなどで）取得します。

これにより、ある程度の構造（および順序）が提供されると同時に、アジャイルアプローチの類似性も維持されます。

上記のことを踏まえて、「英語のようにアジャイルとして」という古い英語のスピーチの図は、理由なく作られたものではないことを思い出してください！

アジャイルがチームにとって不可欠であるなどの方法論が必要だと思います。あなたの会社は非常に混乱しているので、あなたはあなた自身の開発チーム内でより組織化される必要があります。しかし、あなたの非技術管理者がそれと関係があるとは思わない。

営業担当者を押し戻して現実的な期限を要求する場合は、組織的な計画でそれを正当化する必要があります。

また、別の注意事項として、技術的な相談をせずに見積もりを受け取った場合は、空白を拒否してください。

おそらく、インクリメンタル/反復的な側面に焦点を当てることが、チームと空から落ちた利害関係者の両方が定期的かつ一貫して提供できる必要があるものです。時間が経つにつれて、営業チームと経営陣は、新しい機能のリクエストを提出したときに、チームが適切な時間枠で納品できることを確信できるようになります。

もちろん、ユニット/システム/回帰テスト、自動ビルド、ドッグフードなどに投資する必要があります。

まず、いくつかのデータを収集することをお勧めします。静かな時間に座って、現状が何であるかを把握してください。経営陣がアジャイルと呼ぶことができるものを実装することに苦労しているなら、あなたのチームのために働くものを見つけ、ドキュメントを作成し、名前に「アジャイル」を平手打ちし、あなたは行ってもいいです。彼らがアジャイルについて本当に知っているのは単語だけであり、英語での通常の定義の素早さとの曖昧な関連があることに留意してください。だから私が提唱しているのは、あなたのチームが問題の前に出て、あなたに合ったフレーバーを見つけて、それをアジャイル（tm）のやり方としてあなたの経営陣に提示するということです。そうしないと、PHBが本を手に取り、四角い釘を丸い穴に収めようとしますが、誰も満足しません。

「純粋な」形式のアジャイルを使用する場合、チームもサポートの役割を果たさなければならないのは難しいかもしれません。それに直面して、上司は、「バックログアイテムを作成してください。スプリントの終了までに数週間以内に行きます」と言って、ヘルプデスクのリクエストに応答するチームのメンバーを受け入れることが難しい場合があります。

最大のハードルはお金です。すべてがグリーングレービーである場合、何かが間違っているため変更する必要があると言うのははるかに困難です。

幸運を祈ります。

それどころか、締め切りの遅れ、非現実的な期待、および計画が不十分なプロジェクトに対処するために、アジャイル手法がまさに必要なものであるように思えます。

あなたの経営陣は、彼らがこの新しいバズワードに興味があることを示しています。ほとんどの場合、彼らはあなたの製品のマーケティングを誇張するためにそれを使用したいと思うでしょう。これは必ずしも悪いことではありませんが、あなたはアジャイルメソッドの仕事をしたい場合は、それは非常に慎重に管理する必要がありますため、あなた。

戦いの半分は経営陣から賛同を得ています。彼らにアジャイルのアイデアを受け入れてもらうことは、ほとんどの戦いです。残りは、彼らの期待が管理されていることを確認して、あなたがアジャイルであることを引き続き望み、マネージャーがプロジェクト管理に対する彼らのコントロールがほとんど指からすり抜けているように感じるとき、彼らが幻滅するのを避けることです。

あなたの会社が何かを決める前に、アジャイルのコーチになって半日のセミナーとワークショップをすることをお勧めします。マネージャーも開発者も同様に、チームとして考えてもらいましょう。あなたにとってアジャイルの利点は何なのか、そしてあなたは役に立たないのか。一方、経営陣があなたの判断を信頼している場合、アジャイルの実践と方法のいくつかに非常に精通し、セミナーまたは独自のセミナーを作成する必要があります。個人的には、多くの時間を無駄にせず、その勢いを維持するために、経験豊富なコーチを獲得する方向に進みます。それまでの間、いくつかの優れたアジャイルの本のコピーを参照として入手し、それらを徹底的に読んでください。また、管理者がそれらを見ることができるあなたの机にぶら下げておいてください。サブリミナル心理学は、あなたが説明したような状況で驚異を働かせることができます。

少なくとも以下を読むことをお勧めします。

• リーンソフトウェア開発 -Mary＆Tom Poppendieck
• アジャイルソフトウェア開発-Robert C. Martin

そして、追加のクレジットのために（私が言及した他の本の素晴らしい仲間だと思うので）：

• クリーンコード -ロバートC.マーティン