私の名前はエカテリーナシャラパノバです。2008年からDataArtで働いており、主にプロジェクト管理に携わっています。 ただし、この役割をシステムアナリストの役割と組み合わせることもあります。 2000年以降、この業界でプログラマーとしてのキャリアをスタートし、関連分野の処理に関心のあるマネージャーに静かに退化しました。 私の意見は、私がここで代表する会社の立場と一致しないかもしれないことをすぐに明確にします。
アジャイルとは基本的にスクラムという意味ですが、他の亜種の存在は知っていますが、すぐに言わなければなりません。 私の意見では、これらの考慮事項は、すべての柔軟なプロセス、つまり、作業の開始時に固定範囲を持たないプロジェクト、およびチームが後でタクシーアウトするという自信を持って行われます。 チームが必ずしもタクシーで出ない理由を以下で説明します。
私はカスタム開発の業界で多くの経験を持っていますが、他の人の回顧展に座ってみたいです。
それでは、なぜアジャイルが機能しないのですか？
実際、各プロジェクトは独自の方法で不幸ですが、さらに深く掘り下げると、すべてを3つの主な理由に減らすことができます。
- これは間違ったコマンドであり、間違ったアジャイルを行っています。
- アジャイルは、プロジェクト環境（つまり、会社）との互換性が不十分です。
- このプロジェクトは本質的にアジャイルと互換性がありません。
多くの場合、アジャイルプロジェクトの存続を妨げるのに十分な理由が1つありますが、いくつかの組み合わせがある場合、終了は少し予測可能です。
次に-これらの各理由について数行。
これはあなたのアジャイルの間違いです
もちろん、「間違ったアジャイル」は矛盾した言い方のように聞こえます-柔軟性の概念に基づいて、明確に正しいまたは間違ったアプローチがあるのはなぜですか？
簡単です-チームはアプローチの本質を十分に理解しておらず、プロジェクトの成功に必要なこともしていません。
先に進む前に、「チーム」とは、テスターやその他の技術を持つ開発者だけでなく、何らかの形でプロジェクトに関与しているすべての人を意味します。エンドユーザーとその代表者、さまざまなレベルのマネージャー、プロダクトオーナー、プロジェクトスポンサー、など
プロジェクトを成功させるには、クールなプログラマー（テスター、デザイナー、DBAなど）が十分ではありませんが、まずユーザーの関与と健全な製品所有者が必要です。 第二に、適切な実践（これらすべてのバードダウン、タスクボード、デモ、連続体の統合および回顧）の適用、および各ユーザーストーリーの進捗状況、およびプロジェクト自体の意味に関する情報の普及に表明された、取り組みの明確な同期。
アジャイルは考え方であると言うなら、それは哀れに聞こえますが、おそらく完全に間違っているわけではありません。 奇妙なことに、参加者がアジャイルマニフェストのアイデアを共有しない（マニフェスト自体を読まないこともある）単一の成功したアジャイルプロジェクトを覚えていません。
言及しなければならないもう1つの要素は、チームメンバー全員の相互尊重です。 私たちは顧客を尊重しなければなりません、顧客は私たちを尊重しなければなりません、チームは各メンバーの意見に耳を傾け、彼の興味に留意しなければなりません。
しかし、チームが共通の目標と成功の共通の基準を理解していない場合、これらはすべて役に立ちません。 そして、グローバルな目標と短期的な目標。
プロジェクトの目的とその達成の兆候を理解することによってのみ、チームは日々の活動において正しい決定を下すことができます。 イテレーションに取り入れるストーリーから始まり、バグの優先順位（製品のユーザーにとってより重要なもの-外観または速度）、またはイテレーションの終わりまで2日しかかからない場合に完了するストーリー、および作業-3 。
チームメンバーにも個人的な目標があることを忘れないでください。同僚が目標を達成するのを手伝っても、一緒に仕事をする喜びが増えます。 例-2つのほぼ同等で、あまり馴染みのないテクノロジーから選択する場合、チームメンバーの1人が長い間勉強を望んでいたものを選択します。
そのため、「間違ったアジャイル」の感覚がある場合：
- 高レベルの目標設定から始めることは、私たちとユーザーの両方がプロジェクトの成功基準を明確に理解していることを確認することです（そして、合意された価格でプロジェクト全体を提供するのはタイムリーではありません。むしろ、ユーザーは本当にこの問題を解決する必要があります。これらのユースケースを可能にします ''）。 ドメイン開発者の少なくとも基本的な知識とユーザーの理解も非常に役立ちます。
- プロセスの実践と技術をチームと一緒に分解します。 毎日の正直なステータスの更新が、グローバルなプロジェクト目標の達成にどのように役立つかを示します。
- 念のため、受け入れ基準、初期のデモ、回顧、フィードバックなどの重要なことを忘れていないことを確認してください。
アジャイルはプロジェクト環境との互換性が低い（顧客企業）
人と相互作用は、プロセスとツールよりも重要です。
実用的な製品は、包括的なドキュメントよりも重要です。
顧客とのコラボレーションは、契約条件の交渉よりも重要です。
変化への意欲は、当初の計画に従うよりも重要です。
（アジャイルマニフェスト）
会社が長い間何らかの形で働いている場合、既存のプロセスを変更することは困難であり、多くの場合不可能です（たとえば、会社が法律で入札を発表し、要件とお金を修正する必要がある場合...）。 固定要件と価格はVモデルの明らかな兆候であり、たとえばロシアの国営企業で作業している場合、純粋なアジャイルは得られません。
「元の計画に従うよりも変更の準備が重要」および「契約の条件に同意するよりも顧客との協力が 重要」であるかのように行動した場合、プロジェクトの終了時に未提供の機能に対するペナルティが課せられます。
時にはそれほど難しくなく、外部の力ではなく、仕様を記述するときにテンプレートに従う（ユーザーストーリーの概念と互換性がない）要件や特定の方法でプロジェクトの進捗状況に関する月次レポートを発行するなどの内部制限があります。 このような手順では、 「実用的な製品は網羅的な文書よりも重要」という宣言は、経営者の間で混乱を招く可能性があります。
一方、古いルールは「アジャイルではない」ため、取り除いて捨てる価値はありません。 退屈で費用のかかる手続きではありますが、サポートのコードを転送したり、製品のセキュリティに関する何らかの内部監査または外部監査を行うなど、あらゆる種類の便利な手順があります...
環境がアジャイルにあまり馴染みがないという認識がある場合の合計：
- プロセスを3つのグループに分けます： 有用なもの （コードが後で既存のインフラストラクチャで生き残るために必要です：セキュリティテスト、構成ガイドなど）、 あなたが仲良くできるもの（いくつかのレポート、テンプレート、設計要件） GOSTまたは手続き型言語から継承された企業標準に基づくコード）、およびアジャイルとまったく互換性のないコード。
- 最初のタスクをタスクに追加し、バックログに追加し、評価し、スコープが突然わずかに成長したことをため息をつき、それを光の中に引き込んだことを喜ばせます。
- 2番目については、会社の責任者と交渉します。 妥協点を見つけることができます。より便利なテンプレートに同意するか、より適切なKPIに同意してください。
- もちろん、最大の問題は3番目の問題です。 アジャイルプロジェクトに関与し、紙の上のいくつかの堅固なフレームワークを修正したことが起こった場合、災害の規模を認識したらすぐに、被害を最小限に抑えて損失を最小限に抑える方法を把握するために、顧客を含む利害関係者を集める必要があります。 最終的に奇跡が起こる可能性があり、最終的に判明したものの範囲と条件を変更するような追加の契約書を書くことができます。
このプロジェクトは本質的にアジャイルと互換性がありません。
アジャイルの伝道者がどれほど困難に気づいても、アジャイルが働かない世界には多くの課題があります。
もちろん、最も印象的なのは、宇宙船を管理するソフトウェアの作成例です。2週間に1回、彗星にプローブを着陸させ、物理学者の観点から異なることをする価値があるというコメントを受け取った顧客を表示するのは困難です。
別の顕著な例は、ある種のテレコムです。 電話機用のファームウェアを作成する場合、新しい電話機の潜在的なユーザーへのGSMプロトコルメッセージの次の各クラスのデモ実装は絶対に必要ありません。
スクラムが適用できないことを示すもう1つの良い例は、優先度がゼロのユーザーからチケットが突然到着し、全員がすべてを破棄して修正する、あらゆる種類のサポートコマンドです。 予測可能性とリズムはなくなります。
一方、宇宙船や携帯電話を開発したり、家電製品をプログラムしたりしても、アジャイルが実行できるタスクと実行すべきタスクがあり、潜在的なユーザーに中間結果を示します。
そのため、アイデアと互換性のないアジャイルモードでプロジェクトを開始しました。
- アジャイルをやろうとするのをやめて、より適切なプロセスの構築を開始してください。 同時に、アジャイルに関連付けられているプロセス要素を放棄する必要はありませんが、どこでも動作します。
- コードとコードからテストケースまでの要件の表面上は一見怪しいトレースを備えたVモデルは、意図されているケースでは正常に機能します。 iPhoneのスタートアップに適さないものがあったとしても、それが悪いという意味ではありません。
- ITILの概念について読むのは理にかなっているかもしれません。それらはすでに20年前であり、多くの作業が行われています。 場合によっては、サービスデスクをかんばんと組み合わせて、実際に機能する真のアジャイルプロセスを取得できます。
- 特にあらゆる目的で作成されたものと同様の問題を解決する場合、あらゆる種類の産業慣行と、適切な大企業の独自の開発があります。
最後に、銀の弾丸はもちろん存在しないことを付け加えたいと思います。 確かに特定のケースでは、すべてが少し間違っているかもしれません。
ご清聴ありがとうございました。