タグ付けされた質問 「scrum」

現在、私たちは過去1年間、独自の製品バックログを処理する5つのスクラムチームを抱えています。各チームは独自の専用システムで作業しますが、基盤となるテクノロジーは同じ.Netです。 単一のバックログから機能ベースのチームに移行することについては、多くの議論がありました。その理由は、私たちの主要なシステムの1つにかなりの量の作業があり、その年のすべての作業を実行するのに十分な容量がないためです。もう1つの重要な理由は、ポートフォリオの変化に迅速に対応できる柔軟性が高まることです。 1つのバックログで作業するように2つのチームを変更する決定が行われましたが、開発者は他のシステムでの経験がありません。私たちがしていることの1つは、エクスペリエンスシステム開発者をチームに移すことによるクロススキルです。 私の質問は、2つ以上の異なるシステムの単一のバックログへの移行を経験したことがありますか。あなたの課題は何でしたか？それを機能させるために何をする必要がありましたか？

9 agile  scrum 

最近、私は（スクラムを使用した）アジャイルプロジェクトに関与していて、各スプリントの最後にチームが開発者「MVP」とQA「MVP」を指名し、チーム。次にMVPは、小さな金銭的報酬と無料のランチ、およびトロフィーを彼の机に表示するために受け取ります。これまでのところ、この報酬システムを使用して2つのスプリントを達成しました。 これから私が見る良いことは次のとおりです： より多くのバグが修正されました（これは上級管理職が見たいものであり、彼らが望む方向への数の変化です） 各「チーム」のMVPが認識され、自尊心が高まります（または自我の高まりですか？） （少なくとも開発者の観点から）そのようなことをするのに悪い面をいくつか考えていることに気づきました。 バグ修正の品質が低下するほど、その数に非常に関心がある開発者が数人います。ある領域の修正により、別の領域で回帰が発生しています。 バグ数を増やすために、「より簡単でより速い」バグを厳選している開発者が数人います。私はここで悪いのは良いことだと思います。 より高い優先度（多くの場合、「修正するのがより困難/より長い」に関連する）の​​欠陥は、実際にはより低い優先度になります。 ブロッキングの欠陥は、通常より時間がかかり、QAとのより多くの調整を必要とするため、適時に対処されません。 開発チーム内のチームの側面が失われました。開発とQAが一体となって機能するチームの側面も改善されていませんが、以前と比べてあまり変わっていません。 バグ修正を超えて作業したり、その数に向けて作業したりすることは、簡単に認識/追跡することはできません。 私は、チームがそれぞれをどのように処理するかに応じて、上記の「悪い」のそれぞれにある程度対処できると信じています。 私の質問は、スプリントごとにMVPを認識しているこのようなものをうまく成功させた人はいますか？もしそうなら、あなたはその成功に何が貢献したと思いますか？

9 agile  scrum  teamwork  motivation 

スクラムとは何かについての議論で、アジャイルのことを完全に誤解しているのかもしれません。スクラム（確かにアジャイルプロセスと見なされます）は、TDD、ペアプログラミング、CI、リファクタリング、その他の開発者中心のテクニックやプラクティス（今まで）アジャイルの心臓部です。今、私は困難に直面しています！ 1）スクラムは、開発者がアジャイルプラクティスを行うかどうかにとらわれませんか？ 2）自動テストを利用しないチームにスクラムを実装できますか？リファクタリングを実行しないか、アジャイルプログラミングの実践に準拠していませんか？

9 agile  scrum  process 

開発されたアプリケーションの領域について、メニューから項目を削除する要求が出されました。 これは小さなことですが、スクラムでどのように扱いますか？ユーザーストーリーを使用して、機能を追加するのではなく、削除することに慣れています。 だから私の質問は、私はこれのためにユーザーストーリーを作成する必要がありますか？それとも、これに対処するより良い方法がありますか？

9 agile  scrum 

私のチームへの導入の可能性について、アジャイルスタイルの方法論を評価しています。スクラムでは、同じ人に複数の役割を任せることはできますか？4人の開発者とWebデザイナーの小さなチームがいます。私たちは実際にはリードを持っていません（私はこの役割を果たします）、QAテスターまたはビジネスアナリストであり、すべての開発タスクはCIOから行われます。自動テストは時間の無駄とみなされ、すべてが品質ではなく速度に焦点を合わせています。 何が起こるかは、CIOが開発タスク（機能かバグかに関係なく）を考え出し、それを開発者（チーム全体ではなく、個人、多くの場合は非公開または突然）に渡します。完成する予定です。CIOは当初のアイデアを超えて要件を収集しません（そして、これについて以前に私たちを悩ませてきました。なぜなら、エンドユーザーが相談または通知されていないため、機能を使用できないことを確認するためだけに実装するからです。開発する前に、そしてパニックの場合は変更を元に戻すように指示されます）が、私たちが行うすべてのことについて、/承認する必要があります。 まず最初に、いくつかの基準と実践を導入するためにスクラムスタイルを検討する必要がありますか？読書から、スクラムは少し信頼とコミュニケーションに依存しているようで、開発よりもプロジェクト管理に重点を置いています。これは、現在プロジェクト管理の類似点がないため、完全に欠けているものです。 第二に、それが機能する場合、誰かがスクラムマスターと開発者の両方として行動するのは無理でしょうか？または、開発者がプロ​​ダクトオーナーになることもできます（ただし、これは開発者ではないCIOになる可能性があります）。スクラムマスターとプロダクトオーナーは異なる人物であるべきだと思いますが、同時にプロダクトオーナーの資質を持っている人はいないと思います（たぶん、「これらすべてのストーリーが必要です。どうでもいいが、それを成し遂げる」というタイプの取引やフリーズは、気まぐれでフリーズ解除されます）。 メンタリティを変更できる可能性は非常に低いため、現在行われている方法を補正するために、スクラム/ XP /リーンの一部を選択する必要があるように思えます。たとえば、ペアプログラミングが飛ぶことは決してなく（無駄と見なされ、2人ですべてを行う必要がある場合、半分のタスクが完了します）、TDDは困難ですが、短いサイクルは歓迎されます。

9 agile  scrum 

私のチームはスクラムに慣れてきていますが、ほとんどの人は非アジャイルまたは「疑似」アジャイル手法に慣れています。私たちにとって最大のハードルは、効率的なスプリント計画会議を実行することです。この会議では、バックログ項目をタスクに分割し、時間を見積もります。（私はVS2010スクラムテンプレートの用語を使用しています。どこかで間違った単語を使用した場合はお詫びします。） タスクにかかる時間を把握しようとすると、コードレベル（テーブルレイアウト、インターフェイスなど）で機能を設計するという罠に陥ることがよくあります。 。 ここはそのようなデザインをするのに適した場所ではないと私は確信しています。スプリント中にこれらの設計会議のタスクをスケジュールする必要があります。ただし、タスクの意味のある推定値を他にどのように作成するかを理解するのに苦労しています。 実践的な習慣/テクニックなどはありますか？機能の実装計画を知らずに、機能の所要時間を判断するため 設計が完了した後で時間の見積もりが大幅に変更される場合、事前にスプリントバックログを適切に予算化するにはどうすればよいですか？ 編集： 明確にするために、コメント/回答のいくつかは非常に有効ですが、私は間違った質問に対処すると思います。 私たちがやっていることは正しくなく、このデザインのスプリントに時間を組み込む必要があることはわかっています。概念的には、すべての開発者がそれを理解しています。また、スクラムの経験を持つチームメンバーを招いて、雑草に入ってしまった場合でも順調に進んでいます。 問題は、この設計プロセスを実行しないと、何かの具体的な時間の見積もりを提供することが難しいことに気づいていることです。私たちは常に「このように設計すると8時間かかるかもしれませんが、代わりにこれを別の方法で行う必要がある場合、約32時間かかりますが、書き始めたらそれほど悪くはないかもしれません。 ...」 また、これから作業する歴史的な速度が得られれば、このプロセスはより良くなると思いますが、私たちが使用しているテクノロジーやアーキテクチャパターンの多くは、私たちにとって新しいものです。しかし、非常に間違っている可能性のある見積もりが、このプロセスの適応の自然な部分である場合は、それを受け入れるように自分自身を調整する必要があります:)

9 scrum 

私たちはスクラムではかなりグリーンな4人の開発者の小さなチームです。全国から来て、私たちは家に帰るためにしばしば奇数日休みまたは丸一週間休みます。したがって、私たちのチームのキャパシティは、年次休暇のために、反復ごとに劇的に変化します。これにより、反復ごとに速度が大きく異なります。計画会議で速度を推定するとき、チームのキャパシティをどのように説明しますか？過去のデータは非常に異なる容量を反映するため、推定速度の平均を導き出すのに1年待つことはできません。

9 agile  scrum  estimation 

最初のスプリントのストーリーを発見したときに、執筆を中止して前に進むタイミングをどのようにして知っていますか？ 私は知っている数人に尋ねましたが、基本的に私が得た反応は、プロジェクトが存在するコンテキストとプロジェクト全体のタイムボックス化の方法にも依存します。 ユーザーストーリーの作成をいつ停止するかを知るための標準的な方法はありますか。その場合、その根拠は何ですか。また、それは将来のスプリントにどのように適用されますか？

9 scrum  user-story 

過去5か月間、私たちはスクラムをかなりうまく実装してきました。しかし、我々はせずに3週間離れPRODからですこれまでの任意のエンドツーエンドの統合テストを行います。痛い！私は助けが必要です。これの原因に取り組むことなく（この時点で）、現在のイテレーションを計画する必要があります。これは、マイナーな改良と多くの未知のバグ修正で構成されています。このシナリオをどのように説明しますか？まだ発見されていないバグを修正するための反復をどのように計画しますか？

9 scrum  bug  planning 

ここでPOの責任について混乱しています。私はゲーム機能チームの開発者でしたが、POでもありました。開発者の毎日の仕事はほぼフルタイムなので、私は時間をかけてPOの義務に注意しなければならず、POの責任は開発者の考えに反するようです。 POとして、次のスプリントでより多くの機能を選択します。そうでなければ、私はそうしないように自分に言い聞かせます。私はそれらの機能を開発するチームメンバーだからです。この状況は私を混乱させますので、皆さんからいくつかのアイデアを聞きたいです。 私はスクラムとゲーム開発の初心者です（約1年半）。また、ここと英語も初めてです。

9 agile  scrum  game-development 

私のチームは数日前にスクラムを使い始めました。私たちのプロジェクトには、物理​​デバイス（ロボットやセンサーなど）とのインターフェイスとなるソフトウェアの構築が含まれており、通常の製品バックログは、通常、システム全体に制御デバイスを追加することを表しています。 ここでは、例に近いタスクを分割します。各デバイス統合機能は、コード、テスト、統合テスト、ピアレビューなどに分割されます。明らかに、各製品バックログアイテムに固有のシーケンスがあります。通常、スプリントは2週間続き、チームには4〜6人のメンバーがいます。 スプリントの最後に2つの問題が発生します。 1つは、スプリントの終了時に全員を忙しくしておくことです。 2番目の（関連する）1つはシステムの競合です。私たちはスプリントの最後の数日間でほとんど統合することになります。統合システムは1つしかありません。そのため、システムにアクセスできないため、多くの場合、作業の継続が妨げられます。これはスプリントの終わりなので、スプリントバックログで行う必要のある作業は多くありません。これらの人々は何に取り組むべきですか？現在のアイテムが完了していないため、商品のバックログの一番上からアイテムを受け取ることは、商品の所有者から十分に受け取られていません。取り組む技術的負債は、プロジェクト全体を支援しますが、スプリントを完了助けにはなりません。 これらの問題を回避するためにスプリントを構成するためのベストプラクティスはありますか？製品所有者と交渉するためのヒント？

9 agile  scrum 

OK。あなたが教科書スクラムプロジェクトに取り組んでいるとしましょう。あなたは、製品所有者と協力しているスクラムマスターを手に入れました。次のスプリントはUIが重いです。コーダーが画面の作成を開始する頃には、実際に彼らがどのように見えるかを考えている必要があります。 誰がいつワイヤーフレーミングを行うのですか？製品のオーナーは？製品の所有者をサポートしている人はいますか？スクラムマスター？UXのエキスパートがいる場合、スプリントの開始後にコーダーと一緒に作業しますか、それともストーリーカードと制約のそばに座って、開発者が行っている作業をガイドして通知するワイヤーフレームとモックアップを事前に提供しますか？ UXのヘルプが必要だと思いますが、どこに適用すればいいのか本当にわかりません... 編集：質問を言い換えましょう。 アジャイルプロジェクトで一貫した高品質のユーザーエクスペリエンスをどのように提供しますか？

9 agile  scrum  user-interface  user-experience 

私が現在取り組んでいる会社では、時々、いくつかの物語が互いに結び付いていることに気づきました（あまりに結合されているように）。これは、それらが同じ全体的な機能に属している、または異なる機能である可能性がありますが、次の機能を続行するために最初に完了する必要があるものなどがあります。 イテレーションのワークフローを停止することなく、このケースをどのように処理しますか？私たちは何か間違ったことをしていますか？

9 scrum  stories 

プロジェクトの最初にポーカーの計画を立てる方法が好きです。各ストーリーの詳細を互いに比較して話し合うことができます。 私がこれで気付いた問題の1つは、時間の経過とともに問題ドメインでより多くの経験を積むにつれて、各ストーリー（つまり、最初は5または8の価値があったストーリー）に投票するポイントが少なくなるということですプロジェクトの今の価値があるかもしれません3。 この問題を可能な限り最善の方法で回避または対処するにはどうすればよいですか？推定するより良い方法はありますか？ストーリーは常に同じである必要がありますか、それともこのストーリーポイントは減少しますか？

9 agile  scrum  estimation 

私はスクラムを使用していて、本当に気に入っています。ただし、私のショップは、開発作業の期間が2週間または4週間のプロジェクトに含まれています。私たちはすでにスプリントの長さを2週間に変更しました。ここの誰もが「それは1つ半のスプリントがあれば、スクラムになるでしょう」と言っています。 １年半のスプリントから多くの価値を得ることができるとは思いません。1回、2回、または1.5回の反復のみで反復的な開発プロセスの利点を得るにはどうすればよいでしょうか。

9 agile  scrum  sprint  iterative-development