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

スクラムチーム 3 x開発者 2 xテスター 1 x自動化テストアナリスト 開発者がテストせず、テスターが開発しないという点で、私たちは多機能チームではありません。これが問題の根本原因だと思います。 現在、2週間のスプリントを行っています。 スプリントの開始時には誰もが忙しく、開発者は開発作業を開始し、テスターはテストの準備（テストケースの作成など）を行っています。 テスターが準備を完了すると、開発作業が完了するのを待っているか、開発作業が完了して開発者がフィードバック/バグを待っています。 開発者はここでitい足を踏み入れ、現在のスプリントの範囲外にあるバックログのアイテムの作業を開始します。これにより、現在のスプリントで常に次のスプリントを開発するという奇妙な影響が生まれています。私にはこれは正しくないと思う。 経営者の観点からは、彼らは開発者が机に座って何もしないよりはむしろ仕事をすることを望んでいますが、同時に、スクラムチームの目標と焦点は現在のスプリントのみにあるべきだと感じています。私たちのチームが多機能であることを願っていますが、残念ながらそれは達成できません。テスターに​​は開発作業を行うのに必要なスキルがなく、開発者の大多数はテストが彼らの下にあるという意見を持っています。 これはスクラムの問題と見なされますか？これに対する解決策はありますか？スクラムは多機能チームでのみ機能しますか？ 可能であれば、これに関する他の人々の経験を知りたいです:)

11 agile  scrum 

スクラムチームは、通常のスクラムの役割で構成されています。UI / UXデザイナーはおらず、開発者は製品所有者とUI / UXを操作します。ここに問題があります。バックログを作成しようとするたびに、スプリントの開始前に正確なUI / UXデザインを定義していないため、スプリント中にUI / UXデザインを完成させようとして時間がかかりすぎます。 これは、機能の分析とアーキテクチャにも当てはまります。機能に関するすべての可能な詳細は、スプリントの開始前に開発者に提供されるべきか、それとも機能内のタスクであると考えますか？私たちはこれを経験しており、基準を持たないいくつかの未定義の機能をもたらします。

11 agile  scrum 

スクラムの製品所有者は、自分がすぐに答えられない、実装している機能に関するチームからの非常に詳細な質問にどのように対処する必要がありますか？開発者が顧客自身と直接話をするのが明らかに高速なソリューションになるのはいつですか？ チームと顧客間の直接的なコミュニケーションが製品所有者の役割を損なうのではないかと思います。POは顧客のみを代表するものであるため、要件に関するすべての質問に回答する必要があります。彼を迂回することは彼を弱め、最終的に彼を不必要にさせるようです... スクラムにはベストプラクティスがありますか？

11 scrum  communication  product-owner 

技術的なユーザーストーリーはスクラムで許可されていますか？もしそうなら、技術的なユーザーストーリーをスクラムで書くための標準テンプレートは何ですか？同じAs a <user> I want to do <task> so that I can <goal>ですか？ 私はいくつかのブログでas-a- de -veloper-is-not-a-user-storyを読んだことがありますが、スクラムはこれらを義務付けていないことも読んでいます。彼らは共有しているいくつかのブログがあるユーザーとしてシステムにユーザーストーリーを、そのようにas a <user who is not end user> i want to <system functionality> so that <some techinical thing>。それで、どれが標準ですか？ たとえば、次のようなユーザーストーリーがあります。 レビュー担当者として、ホテルや食べ物の写真をアップロードして、他のユーザーが見たり気に入ったりできるようにします ユーザーとして、写真のコメントを追加して、自分の意見をよりよく説明できるようにします これら両方のユーザーストーリーには、大きな技術項目があります-画像の保存と取得 次の説明とともに、「画像の保存と取得のメカニズム」というタイトルの技術的なストーリーを追加できますか？ 開発者として、ユーザーが必要に応じて画像を追加/表示できるように、画像を保存および取得するメカニズムを開発したい

11 project-management  agile  scrum  project  user-story 

アジャイル/スクラムを使用している新しいチームに参加しました。開発プロセスは次のとおりです。 1）開発者は各スプリントの前に各ストーリーを確認し、重要なことを見逃さないようにします。ワークフローにはそのための正式な状態があります。 2）スプリントのキックオフ中に、チーム全体が各ストーリーにかかるストーリーポイント数の見積もり（ポーカープランニング）を行います。 3）最後に、各スプリントが開始された直後に、各開発者は割り当てられたすべてのストーリーを、各ストーリーを開始する前のサブタスクとは対照的に、時間の見積もりとともにサブタスクに熱心に分解する必要があります。 最後のステップの主な論点は、ストーリーの実装に予想よりも時間がかかるかどうかを発見し、スクラムマスターにスプリント期限の欠落の潜在的なリスクについて警告することです。 しかし、主に次の理由により、この逆効果になります。 目的が大まかな見積もりを提供することである場合、ストーリーポイント（ステップ＃2）は仕事をするものです。それ以外の場合、なぜストーリーポイントに悩まされるのでしょうか？-早めにサブタスクを実行します。 目的が正確な推定値を提供することである場合、これは有害と見なされるヒューマンタスクスイッチで説明されている内容の明確な例です。これは、特に、大規模プロジェクトで既存のチームに参加し、何をする必要があるかを理解するのに最大50％の時間がかかる新​​しい開発者の場合に当てはまると思います。ストーリー＃1、次にストーリー＃2、＃3などの詳細を取得する必要があります。これにより、大量の情報が大量に生成されます。 また、そのような慣行は「本による」と言われていますが、これについて議論するつもりはありません。誰でもそのような実践への参照を提供できますか？これがスクラム聖書で明確に定義されているかどうか、および/または多分余分な洞察を提供しますか？

11 agile  scrum 

製品所有者はユーザーストーリーをスクラムで書くべきだと思います。 ユーザーストーリーは、エンドユーザーの機能を説明しています。 しかし、誰が技術的に開発する必要があるのか​​、それをどのように実装する必要があるのか​​を説明します スクラムに関する情報はどこに保存されていますか？ それは本当に私に興味があるでしょう！ 開発者がストーリーを実装し始めたとき、私たちの会社には知識が非常に不足していますが、実装する方法がわかりません！ たとえば、従来のCOM APIを処理する必要があり、その処理方法がわからない場合や、WPF / WEBなどの技術的なスキルがない場合です。 スクラムは、ユーザーがユーザーストーリーから始めるのにどのように役立ちますか？

11 scrum 

私はスクラム文書を読んでいて、スプリントのタスクは「潜在的に出荷可能」でなければならないと言っています。 これが何を意味するのか混乱しています。Sprint 1の目標が「ユーザー登録フォーム」だったとします。 何かを出荷する準備をするために、どのくらい詳細を追加する必要がありますか？例えば： 派手なスタイリングなしでフィールドを持つシンプルなフォームを表示し、完了マークを付けることができます 完了マークとしてクライアント側の検証を行うことができますが、サーバー側もオプションまたは両方です また、jQueryの便利なツールヒント、ホバーオーバー、キャプチャ、色、フォームのラベルを追加することもできます。 次に、画面にエラーメッセージを表示する方法についてのスタイリングがたくさんあります 私は1つのトピックで無限に行うことができます。それで、それをどのように分割し、私はそれを出荷準備完了と考えることができます。 または、エラー、ポップアップ、またはライトボックステキストをサブタスクとして表示し、それらをスプリントとして配置するなど、できるだけ小さいものをそれぞれ記述する必要がありますか。これにより、プロジェクト全体で数千のタスクが発生します。 Internet Explorerで動作するものとFirefoxで動作するものがあれば、それらをタスクとして分割する必要があります。それらに時間を費やす必要があり、その時間にマネージャーがあなたに何をしたかを尋ねられたとき、私は伝えるべきタスクはありませんが、実際にはそれらはすべてユーザー登録の一部です

11 web-development  agile  project-management  scrum 

スクラムのアイテムが予想よりも時間がかかる場合はどうすればよいですか？開発者が最初に考えたよりもずっと厳しいので、開発者が完了するのに苦労しているアイテムに気付いているので、私はこれを尋ねています。 そのような状況では スプリントのタイムラインを満たすために、アイテムをスプリントから製品カタログに戻しますか？ より簡単なスプリントアイテムに移動し、タイムラインの最後まで問題のあるスプリントを残す スプリントレビューで、現在のスプリントで利害関係者にアイテムを完成できない理由を正当化する 今後、このような状況をどのように回避できますか？それは事前の計画の欠如によるものですか、それともスプリントアイテムを小さなアイテムに分解する努力をしなかったのですか？

11 scrum  sprint 

チームの燃焼度チャートと反復ごとの速度をプロットしました。私にはそれは本当に悪いように見えます（速度は大きく変動します）。この振る舞いの根本原因を診断するために何を探すべきですか？

11 agile  scrum 

私は最近スクラムに移った6人のチームを管理しています。 スクラムマスター（チームの開発者の1人）とプロダクトオーナーがいます。 かなりの空き時間があるため（以前は多くの管理作業がスクラムマスターとプロダクトオーナーによって行われていたため）、技術的に関連性を保ちたいため、技術開発作業を行っています。 私は開発チームの一員として行動し、各スプリントのストーリーの一部にコミットし、チームの一員としてすべての会議に参加します。 それは良い考えだと思いますか？チームの「自己組織化」と矛盾することはありますか？

11 scrum  management 

すべてのチームメンバーに共通の言語が1つもないチームがあります。チームは2つの場所に分かれています（ただし、地理的な問題は主要な問題ではありません）。各場所のすべてのチームメンバーは同じ言語を話し、両方の場所で両方を話すことができるメンバーがいます。スクラムを紹介したいのですが、言語の問題に対処するためのロジスティックスに苦労しています。 これはオフショアチームではありません。すべてのチームメンバーは会社の従業員ですが、異なる国の2つの異なるオフィスにいます。幸いなことに、タイムゾーンに関する問題はありません。言語が第一の障壁です。各場所の人々の規模とスキルセット、およびその他の外部要因を考慮して、チームを2つのチームに分割することもできますが、単一のチームとして統合することがより望ましいです。 コミュニケーションを豊かにし、チームが団結してお互いを見て真のスタンドアップアプローチを行えるようにするには、ビデオ会議を使用することが望ましいと思います。しかし、これは言語間でのコミュニケーションが困難になると思います。チームのバイリンガルメンバーは口頭で翻訳する必要がありますか？代わりに、分散スクラムの言語の問題に関する唯一のリファレンスで推奨されているインスタントメッセージを使用することもできます。私は「貧しい」コミュニケーションを心配しており、おそらくそれはスクラムの概念への不十分な紹介です。 チーム内で言語の違いに対処した経験のある人から、問題にどのように対処し、どの程度うまく機能しましたか？

11 agile  scrum  team  spoken-languages  distributed-development 

私たちは、新しいプロジェクトを開始しようとしている5人の小さなグループです。これは、スクラムでオールインする最初のプロジェクトです。 プロジェクト（フレームワークなど）のベースをどのように確立するかについて、少し苦労しています。このようなタスクは、ユーザーが直接恩恵を受けるものではないため、ユーザーストーリーをどのように書くかを考えるのに苦労しています。 それで、一般に、フレームワークもベースライブラリも配置されていない状態でプロジェクトをゼロから開始する場合、スクラムをどのように使用しますか？

11 scrum  user-story  sprint 

スクラムは、ジェネラリストメンバーがいるチーム、つまり、少なくとも2人が同じタスクを実行できるチームに最適です。私の主な関心事は、専門家で構成されたチームのためにスクラムを適応させるための優れたソリューション（何を保持し、何を削除し、改善するか）を見つけることです。 5人の開発者からなるチームがあると仮定します（実例ではなく、単なる例です）。 Cの強力なスキルを持つ1人の数学者。 1人のDB開発者。 1人のWeb開発者。 UX / GUI開発者1人。 1人のソフトウェアアーキテクト。 ここでは、すべてがスペシャリストであり、誰も他の誰かを置き換えることはできません（このようなチームを構築するリスクは気にしません。スクラムに集中したいと思います）。だから、スクラムの文脈で、ここに私の考えがあります： 役に立たない春の計画：実際、数学者が特定のタスクに2ポイントの価値があると言ったとき、誰も彼に反対することはできません。 役に立たないチーム速度メトリック：誰もが自分のタスクに任意の数のポイントを割り当てることができるため、速度の計算は意味がありません。 毎日のスクラム会議を毎週（より長い）スクラム会議に置き換えます。チームの各メンバーが自分のタスクに取り組んでいるため、毎日のスクラム会議は「チームスピリット」を維持するために非常に重要です。ただし、毎日のスクラム会議は約15分間続くことになっています。これは明らかに、他の人が何をしていて何をするのかを理解するには不十分です。さらに、数学者はほとんどの場合、同じことを答えます。「私はまだ％＆Lo（+？$$ +＆）をやっています」...毎週のミーティングでより多くの時間が与えられます。「最初の」スクラム会議と「毎週の」スクラム会議の間で同じ会議時間を維持するには、各週のスクラム会議を継続する必要があります（週5日、4週間のスプリント、スプリント会議は4時間、毎日の会議は15分）。 （4 * 60 + 20 * 15）/ 4 => または、スクラムはまだ使用可能ですか？たぶん別のアジャイル技術を使用する必要がありますか？

11 agile  scrum 

よると、この、「スクラムは非常に意欲的、密接に協力し、クロスファンクショナルと自己組織化チームに依存しています。」それでは、コードの所有権を取得する意欲がない同僚をどのように処理しますか？所有権の取得に興味がある人をどのように獲得しますか？

11 scrum  teamwork 

私は比較的新しい開発チームの一員です。Scrumスプリントの終わりに、いくつかの大きなストーリーがPOによってin progress行わacceptedれたか、行われなかったとします。 まず、これらのユーザーストーリーはどうなりますか？次のスプリントに引き継ぐだけですか？ もしそうなら、それらは再評価されるべきですか？私の考えでは、これらのユーザーストーリーに残っている作業は最小限で済むのでしょうか？そうでない場合は、なぜですか？ 編集：私の特定のケースでは、ユーザーストーリーの過小評価のためではなく、数日にわたる障害のためにストーリーは完了しませんでした。それが役立つかもしれないあなたのために、私たちは使用していますVersionOne

11 agile  scrum