スクラムチームに複数の役割を持つ人々がいても大丈夫ですか？

私のチームへの導入の可能性について、アジャイルスタイルの方法論を評価しています。スクラムでは、同じ人に複数の役割を任せることはできますか？4人の開発者とWebデザイナーの小さなチームがいます。私たちは実際にはリードを持っていません（私はこの役割を果たします）、QAテスターまたはビジネスアナリストであり、すべての開発タスクはCIOから行われます。自動テストは時間の無駄とみなされ、すべてが品質ではなく速度に焦点を合わせています。

何が起こるかは、CIOが開発タスク（機能かバグかに関係なく）を考え出し、それを開発者（チーム全体ではなく、個人、多くの場合は非公開または突然）に渡します。完成する予定です。CIOは当初のアイデアを超えて要件を収集しません（そして、これについて以前に私たちを悩ませてきました。なぜなら、エンドユーザーが相談または通知されていないため、機能を使用できないことを確認するためだけに実装するからです。開発する前に、そしてパニックの場合は変更を元に戻すように指示されます）が、私たちが行うすべてのことについて、/承認する必要があります。

まず最初に、いくつかの基準と実践を導入するためにスクラムスタイルを検討する必要がありますか？読書から、スクラムは少し信頼とコミュニケーションに依存しているようで、開発よりもプロジェクト管理に重点を置いています。これは、現在プロジェクト管理の類似点がないため、完全に欠けているものです。

第二に、それが機能する場合、誰かがスクラムマスターと開発者の両方として行動するのは無理でしょうか？または、開発者がプロ​​ダクトオーナーになることもできます（ただし、これは開発者ではないCIOになる可能性があります）。スクラムマスターとプロダクトオーナーは異なる人物であるべきだと思いますが、同時にプロダクトオーナーの資質を持っている人はいないと思います（たぶん、「これらすべてのストーリーが必要です。どうでもいいが、それを成し遂げる」というタイプの取引やフリーズは、気まぐれでフリーズ解除されます）。

メンタリティを変更できる可能性は非常に低いため、現在行われている方法を補正するために、スクラム/ XP /リーンの一部を選択する必要があるように思えます。たとえば、ペアプログラミングが飛ぶことは決してなく（無駄と見なされ、2人ですべてを行う必要がある場合、半分のタスクが完了します）、TDDは困難ですが、短いサイクルは歓迎されます。

スクラム、カンバン、またはその他のアジャイル手法は、主にソフトウェア開発プロジェクトに焦点を当てた手法です。言い換えれば、それはまさにその性質上、プロジェクト管理の実践です。

あなたとあなたのチームにプロジェクトの仕事をしてもらいたいのと同じくらい、あなたが本当に「プロジェクト」の仕事をしていないか、チームとして自分自身を捧げていないという事実のために、あなたはアジャイルがあなたの組織で単に機能しないことに気付くでしょう。 「プロジェクトのコミットメント」。

複雑な機能を中心にミニプロジェクトを編成することもできますが、実際にはビジネスアナリストやエンドユーザーとは関係がないため、ユーザーが何であるかを本当に知る方法がないときに、ユーザーストーリーで配信していることを確認するにはどうすればよいでしょうか。望む？

あなたの唯一の利害関係者は上司であり、彼は基本的にプロジェクトの他の利害関係者にサービスを提供するチームが存在しないことを保証します。これは他の利害関係者にどのように影響するかに関係なく、彼と彼のニーズに対応するチームとして存在します。

それに加えて、彼は個人に個別のタスクを与え、おそらく彼らが行くべきであると決定したらすぐに物事の優先順位を付け直しています。個々のプロジェクトリソースがすぐに優先順位が変更される場合、またはスプリントが保留される場合、アジャイルプロジェクト方法論では機能できません。

それはそのように動作するはずではありません

スプリントは、コミットメントによって、チーム全体指定した日付でユーザーストーリーのサブセットを提供します。開始したら、優先順位付けや変更を行う前に、スプリントを完了する必要があります。このような無秩序なアドホック環境でプロジェクトを実行すると、プロジェクトはどのように管理されることになっていますか？

あなたはアジャイルプロジェクト管理方法論を助長する環境で働いていません。あなたはウォーターフォールの方法論を助長する環境で働いていません。あなたは君主制で働き、あなたはただ彼の入札をして火を消す王ポーンです。

これはソフトウェア開発プロジェクトチームの構成ではありません。

非常にあいまいな方法で、私はあなたの質問に答えます。あなたの状況では、個人が複数の役割を果たしているかどうかは本当に問題ではないということです。あなたの手にはもっと大きな問題があります。屋根のない家のカーペットから水の汚れを取り除く方法を尋ねています。

ここで述べたように、スクラムマスターまたはプロダクトオーナーのいずれかに実行可能なタスクがある場合、それらもチームのメンバーです。

とはいえ、CIOと顧客の両方からの真の賛同を得ない限り、アジャイルに移行するときに深刻な問題が発生します。あなたのCIOは、スプリントの途中で作業項目を追加できないが、次の作業まで待たなければならないという事実を喜んで受け入れますか？彼は開発するアイテムを優先する用意がありますか？あなたが書いたことからすると、彼はあなたの仕事を所有しているように思えるので、製品の所有者でなければなりません。彼が不本意だとしたら、あなたが現在している以上に成功することはないでしょう。

スクラムは、CIOがプロセスに賛同する場合にのみ、CIOがアドホックに作業を割り当てる問題の良い解決策になる可能性があります。あなたのCIOは直接の任務に就くのを嫌うのではないでしょうか。しかし、CIOにユーザーストーリーを書いて優先順位を付けるというアイデアを取り入れてもらえれば、CIOは非常に効果的な管理方法を見つけることができます。しかし、それは、CIOがプロセスに固執するよう説得することから始まります。

スクラムは考慮すべきことです。ただし、すべての関係者を同じページに参​​加させ、構造へのいくつかの変更を受け入れるとともに、この方法論を使用する際のさまざまな初期問題を解決するために少なくともいくつかのスプリントを取得するために、注意すべきことがいくつかあります。

プロダクトオーナーは、開発チームの外にいる必要があります。そうしないと、ここに示すような悪い利益相反が発生します。スクラムマスターは開発者である可能性がありますが、この場合の競合はそれほど深刻ではありません。