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