問題タブ [scrum]

最近、同僚と、スクラムプロジェクトでバージョン管理を整理する方法について話し合っていました。より具体的には、ブランチ作成の基準（開発者ごと、タスクごと、ストーリーごと、スプリントごと？）と統合の方法。

私の意見では、それを整理するための便利な方法は、ユーザーストーリーごとにブランチを作成することです。これにより、各ストーリーが完成したらリリース可能なトランクに統合でき、アプリケーションの「配信可能なバージョン」を常に使用できるようになります。どんな瞬間にも。

したがって、ストーリーを完成させることができない場合は、それを省略して、スプリントのリリースを損なうことはありません。（集中型ツールを検討する場合、分散型ツールを使用する場合は考慮事項が異なる可能性があります）

あなた自身のアプローチ、あなたが好むツールの種類、そしてあなたが経験と学んだ教訓で見た賛否両論を知りたいです。

スクラムでは、ユーザー ストーリーの原則があり、これらのステミング タスクなどが最終製品まで繰り返されます。これは問題ありません。

しかし、実装が必要な機能が 100 個あるとしましょう。現実の世界では、通常の補助的な作業の多くが完了するまで、これらの機能に開発者を配置することはできません。このための機能の全体的なアイデア?)、または必ずしも機能として現れるとは限らない基礎となるものを構築します。

それで、これはどこで起こりますか？

スクラムについて学び始めており、開発チームと一緒に試してみたいと思っています。それについてはたくさんの質問があります... しかし、私の最大の精神的障害は、実際のグラフィック デザインにあります。

現在の開発サイクル [waterfall-esque] では、グラフィカル デザイナーは、緩やかな PRD に基づいて、すべての画像などを含むページをレイアウトします。スクラムの手法を利用するとしたら、この開発はどのように行われるのでしょうか? 私たちは、全体像を見てそこに向かって突き進むことに慣れていると思います...視覚的な部分を組み合わせていくのではなく、グラフィックデザインのスクラムポリシーがそうであることを期待しています。

少なくともバックログのすべての機能をワイヤーフレーム化することは前例のないことでしょうか? それとも、最初のスプリントでは、他のスプリントの新機能を追加できるように機能を設計する方が賢明でしょうか? (つまり、新機能の時期になったら、「これは現在の設計のどこに収まるか?」について話し合います)。

私が働いている会社は、プロジェクトでスクラムを試行しており、現在、3 つまたは 4 つの異なるプロジェクト チームにスカムを展開しようとしています。これらのチームは別々の機能ブランチで作業することを想定しています (SVN を使用しています)。

異なるチームのスプリントを同時に終了する必要があるのか​​、それともスプリントの終了とリリースが別々になるようにスプリントをずらすべきなのかはわかりません。製品は Web サイトなので、展開は問題ありません。

3 つのチームが同時にコードを統合すると、競合が発生する可能性があるので、コードの統合について懸念しています。しかし、リリースがずらされている場合、この負荷はスプリントの途中にあるチームに移されるだけかもしれません。

どちらかのアプローチを試した人はいますか?

スクラム開発のサンプル チャートはどこにありますか?

例: バーンダウンまたはバックログ チャート。

私たちは、オンライン アプリケーションで作業している小さな開発チーム (3 人半の開発者) のために SCRUM を実行しようとしていますが、製品所有者、ユーザー テストなどの非開発リソースから時間を得るのに苦労しています。

私は、開発以外のリソースをより多く獲得し、彼らの関与に対する私たちの要求により迅速に対応できるようにするためのビジネス ケースに取り組んでいます。

現在の状況：

• プロダクト オーナーは 5 人のチームであり、その半分は開発チームから大西洋を隔てたところにあります (これは、オーナーがまったくいなかった以前の状況よりも優れています)。
• プロダクト オーナーの「チーム」は、事実上、月に 2 回しかミーティングを行いません
• 専用のユーザー テストや QA リソースはありません
• ユーザー テストを完了するまでの最短時間は 3 週間で、約 2 人日のテストでした。
• 私たちは毎月のスプリントに取り組んでいます

具体的な質問:

• プロダクト オーナー (彼らが 1 人の場合) は、週にどれくらいの時間をプロダクト オーナーの役割に費やすべきですか?
• プロダクトオーナーが「毎日一日中」対応できることを期待しますか?
• 毎月どれだけの専用のテスト/QA リソースを利用できると予想しますか?

「信頼できる」回答、またはチーム リソース レベルに関するレポートについて Google を試しましたが、何も見つかりませんでした。

誰かがこのようなことを知っているので、私のビジネスケースは「私は思う....」だけではなく、専門家の意見や現実世界の統計を参考にすることができますか?

私の組織は、より多くの「アジャイル」手法の導入を試みてきました。私たちはしばらくスクラムのアプローチを試してきましたが、ほとんどのチームは多かれ少なかれそれに適応しています。全体としては気に入っていますが、方法論の潜在的に重大な影響が 1 つあります。チームは一貫して機能とバックログ項目に焦点を合わせており、テスターは開発プロセス全体とより統合されているため、スキル セットがぼやけ、人々は自分の能力に対する敬意が薄れていると感じています。

当社の開発者の中には、サーバー側の技術と重量データ プロビジョニングの最適化に優れている人もいます。また、キャリアの多くを GUI テクノロジの学習に投資し、ユーザーとアプリケーションの使いやすさについての基本的な理解を深めた人もいます。どちらのスキルセットも優れていますが、確かに異なります。

これはスクラムプロセスの必然的な結果ですか? チームの全員が (私が理解しているように) 次の機能/要件、バックログ項目、または目前のテスト目標を満たすことに貢献しているため、根底にある哲学は「誰でもできる」ということのようです。私の経験では、これは単に真実ではありません。ほとんどのエンジニア (開発者、テスターなど) は、何年にもわたって磨いてきた特定のスキル セットを持っています。私の考えでは、スクラムの方法論は、以前は彼らが尊重されていた能力そのものを過小評価する傾向があります。

明確にするための例を次に示します。

サーバー側のデータ プロビジョニングで技術の突然の変更が発生し、スプリントの to-do リストのすべての項目がこの新しい変更に基づいている場合、GUI 開発者 (おそらく、その変更に慣れる時間がなかった)新技術）はスプリントに貢献できないかもしれません。少なくとも、彼らは成長するために時間を投資する必要があり、そうすると彼らのコードは経験不足のために疑わしいものになります.

「役割のサイロ化」を思いとどまらせるために迅速な開発が必要であることは理解していますが、これは 1 つの基本的な現実を軽視しているわけではありません。それは、人々は必要性、興味、経験に応じてスキルを開発するということです。人は、自分の立場が「プラグアビリティ」の 1 つであることを認識すると、やる気が低下するようです (たとえば、この特定のタスクを実行するために誰でも「プラグイン」できる)。スクラムはこれにどのように対処しますか? そうでない場合、スクラム方法論を採用するときに誰かがこれに対処しましたか?