私は最近、会社でアジャイル手法を使い始めました。私はアジャイルにかなり慣れていないので、アジャイルの基本原則に従って、実装方法が正しいかどうか疑問に思います。
以前は、ビジネスアナリスト、QAテスター、ソフトウェア開発者などの役割がありました。しかし現在、経営陣はこれらの役割を削除する必要があると決定し、誰もがソフトウェア開発者として働くことになります。
実際には、これは、1人のソフトウェア開発者が以前に3つの別々の役割（つまり、1人のビジネスアナリスト、1人のQAテスター、および1人のソフトウェア開発者）と同じ責任を持つことを意味します。
彼らはこれがアジャイルであるという事実で変更を正当化します。これは他の企業もアジャイルを実装する方法ですか？
回答:
いいえ、これは明らかにアジャイルではありません。それも良い考えではありません。
機能横断型のチーム、つまり、機能するソフトウェアを正常に提供するために必要なすべての役割（アナリスト、サーバー管理者、データベース管理者、UXデザイナー、QAテスター、テクニカルライター、グラフィックデザイナー）を含むチームは、多くのアジャイル手法の中心です。実際、多くの方法論では、顧客自体もチームの一部と見なされます。
実際には、これはアジャイルに直交しています。部門を超えたチームは、アジャイルを行っているかどうかに関係なく、単に優れたアイデアです。
何で真の、しかし、自動テスト、開発テスト、一方では、テスト駆動とビヘイビア駆動開発、およびソフトウェア定義のインフラストラクチャの一定の上昇で、高度に自動化されたということです試運転、構成、および展開、DevOpsチーム、およびクラウドホスティングでは、一部のワークロードが管理者からDevOpsエンジニアに、QAから開発に移行した可能性があります。しかし、それはそれらの役割が絶滅しているという意味ではありません。ほんの些細なバグが開発者のテストで発見されたため、QAには追跡すべき興味深いバグがあり、管理者はDevOpsがインフラストラクチャを自動ツールで管理できるようにすることに重点を置いています。
何かがアジャイルかどうかを確認する簡単なテストがあります。誰かが「アジャイルだからあなたがこれをやる」と言ったとき、それはアジャイルではありません。アジャイルとは、プロセスを常に反省して適応させる自己管理チームのことです。誰かが「あなたがこれをする」と言うときはいつでも、それは俊敏ではありません。チームが「私たちがこれを行うのは、過去の経験を反映した後、それが機能することを確認し、機能しないと判断したらすぐにそれをやめる」ため、それは俊敏です。
これは他の企業もアジャイルを実装する方法ですか？
残念ながらそうです。アジャイルが経営陣によって課せられている企業はたくさんありますが、少なくとも彼らがアジャイルだと考えるものはもちろんです（もちろんそうではありません）。
おそらくあなたの経営者がアイデアを見つけたところからのスクラムガイドを見ると、これが見つかります：
スクラムは、その人が実行している作業に関係なく、開発者以外の開発チームメンバーの役職を認識しません。
しかし、チームの全員が「開発者」であるという考えは、彼らの役割（QA、プログラマー、デザイナーなど）を問わず、それらすべてが一緒になって、同じ努力と責任と責任をもってアプリケーションの開発に貢献するということです。 。プログラマーはテスターよりも重要ではありません。コードを書いてテスターがそれをテストするだけだから、デザイナーはワイヤーフレームを作成せず、フロントエンド開発者がそれらを実装している間はなくなります。誰もが重要です。誰もが貢献します。ですから、この点では誰もが同じです。役職は関係ありません。だからこそ、誰もが「開発者」です。
しかし、それは突然、デザイナーがアプリケーションのアーキテクチャーやコードの記述を始めたという意味ではありません。同じ考えのもと、経営陣が言ったようにあなたがすべて「開発者」になったからといって、それはあなたがアジャイルをしているという意味ではありません。
彼らがしていることはナンセンスです。たとえば、ソフトウェア開発者にQAの役割を任せると、次のようになります。
1つは、ソフトウェア開発者に必要な経験がないことです。学べることはすべてですが、私は個人的にはジュニアQAエンジニアから始め、ソフトウェア開発作業よりもはるかに効果的ではありません。
2つ目は、人によって才能が異なり、その才能が重要視される立場に立つことです。人材はソフトウェア開発者になり、QAエンジニアはその才能があるからです。そして、どちらも他の仕事ではあまり良くなかったでしょう。
第3に、同じ人がソフトウェア開発とQAの両方を行う場合、両者は対立します。QAは、ソフトウェア開発者の仕事を増やす原因となる問題を見つけます。誰もがそうであるように、ソフトウェア開発者もこれ以上の仕事は嫌いです。では、QAとして働いているソフトウェア開発者は何を期待していますか？
アジャイルの起源はソフトウェア開発の分野にありますが、開発への反復的なアプローチは50年代後半からあり、NASAの初期に使用されていました（https://en.wikipedia.org/wiki/Iterative_and_incremental_developmentを参照）。これらのチームは明らかにソフトウェアエンジニアだけでした。
私たちの会社やロボット工学チームでは、メンターとしてさまざまなアジャイルアプローチを使用して成功しています。スプリント、スパイク、および包括的な叙事詩による反復設計のコンセプトは、ソフトウェア、ハードウェア、CAD、マーケティングなど、チーム全体で非常に成功していることが証明されています。 2週間のスプリントで学んだことの正直なプロトタイピングとデモンストレーション。そこから進行方法の決定が行われますが、核となるのは、各スプリントが徐々に良くなるロボットです。役割的には、「ソフトウェア開発者」、「CAD担当者」、「ビルダー」、「アウトリーチ」で構成されます。このチームの大部分は、ソフトウェアのコーディングに直接関与していません。
私のソフトウェア会社の場合、チームは通常、開発者、テスター、開発者、設計者、およびサポートで構成されています。
一般に、アジャイルは1つのものではなく、哲学を実装するための多くのアプローチがあります。しかし、その核となるのは、反復的な開発、作業を短いタスクに分解し、継続的に再評価するというアイデアです。毎日のスクラムミーティング、バックログ、ユーザーストーリーなどがよく使用されますが、「アジャイル」である必要はありません。アジャイルは常に適応することであり、特定のチームがアジャイル自体を実装する方法も含まれます。
つまり、簡単に言えば、経営陣はアジャイルを理解していないか、アジャイルをある種の正当化として使用して、お金の無駄だと感じているものを排除します。変更を加えることは正当化されるかもしれませんが、アジャイルはプログラマー専用であるためではありません。