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

私は近い将来に職場を動かす予定です。彼らは私のスクラムの経験とそれが彼らのビジネスにどのように関係するかについて非常に興味があると思います。私はそれが彼らの環境で機能するかどうかを理解しようとしています。 私の現在の仕事場には、2つの製品/ 2つのバックログ/ 2つの別々のチームがあります。これらのバックログは、明らかに、私たちが開発するプラットフォームにビジネスが最も必要と考えていることに基づいて優先順位が付けられています。しかし、私が移動する場所には、外出先で多くのプロジェクトが同時にあり（2/3の担当者がそれぞれ作業している）、少量の作業が入り、毎日修正され、すべての顧客の成果物を想像しますほぼ同じくらい重要です。 それで、誰かが同じような環境でスクラムの経験を持っているのではないかと思いますが、実際に機能した例は何ですか？何がうまくいかなかったのですか？スクラムがこの状況で機能するためには、どのような考慮事項が必要ですか？ どのようにうまく機能するかわからないいくつかの側面があります： チームのメンバーはプロジェクト全体で作業するため、分解するとスクラムチーム全体で作業する可能性があると思います。 おそらく頻繁に変更され、独自のタイムスケールを持つ非常に多くの可動部品の優先順位をどのように扱いますか？ 複数のプロジェクトに取り組むスクラムチームがある場合（その多くは1 Devのみを必要とします）、スタンドアップのコンテキストをどのように理解しますか？

8 scrum 

私が働いている場所では、最近、スクラムを使用してアジャイル開発を切り替えました。典型的な高まる苦痛を経験しましたが、今のところうまくいくように見えるアプローチに達しました（長期的にうまくいくかどうかは別の質問です！）。 明らかに、部門管理者はスクラムへの移行が機能していることに満足しています。しかし、彼らは私にとっては間違っていると感じることを始めています。 経営陣はチームを観察し、彼らにとって何が有効かを確認し、それを部門全体に処方します。のようなもの： 「完了」の定義 ストーリーポイントに使用できるストーリーポイント値（たとえば、1、2、3、5、13などが、スプリント中に使用された唯一の値であるため、fib。シーケンスから8を省略） ストーリーポイント値1を「UIラベルの更新」に調整する必要があることをチームに伝え、上限を20に制限する （すべてのプロジェクトにクライアントがいるわけではなく、すべての開発者がUIの経験があるわけではありません） ストーリーポイントの推定値100を使用して「このストーリーは後で分割する」ことをチームに伝える 無限のストーリーポイントの推定値を使用して、「これは壮大です」または「詳細情報が必要」を意味することをチームに伝える 私は彼らが役に立とうとしていることを理解していますが、上記のすべてがスクラムチーム固有のものではないのですか？つまり、あるプロジェクトの個人のグループで機能するものは、別のプロジェクトの別のグループでは意味をなさない場合があります。 非常に規範的で堅固なアジャイルアプローチに移行しているのではないかと心配しています。私はこれを考えることで正当化されますか、それとも私は過剰反応していますか？ 編集する 明確にするために...「管理」と「マネージャー」によって私は製品の所有者を意味しません。私は、スクラムチーム外の、ソフトウェア部門内のマネージャーを意味します。

8 agile  scrum  management 

私たちは、プロジェクトに最適なスプリントの長さを見つけようとしていました。3週間ベースで作業した後、スプリントを2週間に削減すると、速度が向上すると考えました。 利点は明らかでした-短いフィードバックループ、小さなストーリー（ユーザー価値あり）など。一方で、セレモニー（企画、回顧）など、私たちが制作しておらず、より頻繁に発生するデメリットもたくさんあります。 新しいチームのために、最適なスプリントの長さをどのように決定できるのかと思っていました。

8 agile  scrum  sprint  feedback 

受け入れ基準に関するこのブログの投稿で、著者は適切な受け入れ基準は次のようでなければならないことを説明しています。 解決策ではなく意図を述べる（たとえば、「ユーザーはドロップダウンからアカウントを選択できる」ではなく「ユーザーはアカウントを選択できる」） 実装に依存しない（理想的には、この機能/ストーリーがWeb、モバイル、音声起動システムなどに実装されるかどうかにかかわらず、フレージングは​​同じです） 比較的高いレベルである（すべての詳細が書面である必要はない） 次のような詳細： 列見出しは「バランス」です ローリングバランスの形式は99,999,999,999.9 D / CRです。 チェックボックスではなくドロップダウンを使用する必要があります チームの内部ドキュメントまたは自動受け入れテストのいずれかに移動する必要があります ただし、GUIテストを実行するためにCucumberまたは同様のフレームワークを使用することについて眉をひそめる人々をよく耳にします。さらに、内部ドキュメントを使用すると、ドキュメントを定期的に更新できないために多くの問題が発生する可能性があります。 私はまだ、お客様との会話中にそのような詳細をキャプチャする効果的な方法を見つけるのに苦労しています。

8 agile  development-process  scrum  requirements  user-story 

今日、私にとって興味深い問題が1つ現れました。分散SCRUMチームで、コード形式、IDEプラグイン（checkstyle＆co）、VCS、CIの観点から単一の作業環境の実施をいつ開始しますか？チームは探索段階にあり、目標は本番品質のコードではなく、概念実証です。チームメンバーが将来の作業に本当に関連するものを決定する前に、いくつかの一般的なコーディングルールを「アプリオリ」に実施するのはオーバーヘッドではありませんか？この種のツールは、技術的な負債を最小限に抑えるヒューリスティックとして機能するため、確かに大きなメリットですが、Jenkinsビルドを実際に破壊する「後続スペースなし」としてルールを強制することは、私にとっては、焦点を絞るべきフェーズのやり過ぎに思えます量産コードを作成するよりも氷をくじくように。 注意1：作成したプロトタイプは破棄されます メンション2：最初からすべてが正しく行われることを望みますが、100％可能ではないことは完全に承知しています。

8 scrum 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 製品所有者をどのように評価しますか？より具体的には、製品所有者のパフォーマンスレビューをどのように実施しますか？製品の所有者を確認するときに、どのような品質または特性を確認しますか？

8 project-management  agile  scrum  product-owner  product-management 

最近スクラムについて読んでいます。私の理解では、スプリントが始まる前に会議が開かれ、製品のバックログから次のスプリントのバックログに何を移動するかを決定します。現在のスプリントで機能が完了すると、「Ready to QA」バケットに入れられ、この時点で混乱します。バグレポートは製品のバックログに戻りますか？このサイクルで実行する作業はすでに決定しているため、スプリントバックログに戻れないと思いますか？QAがバグを検出するとどうなりますか？どこに行くの？

8 project-management  agile  scrum 

私の現在のプロジェクトは、途中で分割された「ディスカッション」を持っています- 「このストーリーは当初考えていたよりも複雑です。再推定する必要があります」対「決して再推定する必要はありません。 "。 あなたが再推定する必要があるかどうかについて誰かが光を当てることはできますか？ 私見私はあなたが新しい要件やストーリーのために完全に新しいカードを持ち出すことができると想像しますが、戻ってバックログアイテムを再推定することは相対的なサイジングの概念を歪めているようで、バックログを「膨らませる」だけです。

8 agile  scrum  estimation 

私たちはスクラムワークフローを実装しており、ユーザーストーリー、つまり完了したとき、イテレーションなどに頭を回そうとしています。私たちがよく行うことの1つは、初期のイテレーション中にストーリーに取り組み、それを完全に機能させることですが、 "醜い"。プレーンなボタンを使用し、画像は使用せず、テキストのみを使用して、ボタンが適切に機能していることを示します。私たちはお客様を紹介し、その動作に満足していることを確認してから、通常は提供された画像を使用して、機能の設計を完成させ、完成させます。 この例では、機能的に完成したときにユーザーストーリーを完成させ、「ユーザーとしてxyzを視覚的に魅力的にしたい」という効果を示す2番目のユーザーストーリーを作成して、設計フェーズを処理しますか？または、設計要素を取得して完了できたら、ユーザーストーリーをプロジェクトの最初の反復から後の方に移動するだけでしょうか。その場合、最初の数回の反復で1つか2つのストーリーしか完了せず、最後の数回の反復でTONのストーリーを完了していることがわかります。 このシナリオをどのように処理しますか？

8 development-process  scrum  user-story 

私はスクラムとTDDに取り掛かっていますが、いくつかの混乱があると思います。フィードバックについてお聞きしたいと思います。バックログにユーザーストーリーがあり、TDDの一部として開発を開始するために、これまでの要件が必要であるとしましょう。 プロダクトマネージャーとQAがユーザーストーリーを受け入れて受け入れテストに分解する責任を負うべきだと言うのは本当ですか？ 受け入れテストは形式的である必要があるため、上記は正しいと思います。テストとして使用できるだけでなく、製品が要件であることを製品が承認できるように、人間が読める形式でも使用できます。 私が後でこれらの受け入れテストを受けて、それを私の要件として使用すること、つまり、それらが（TDDを介して）実装する一連のユースケースであることも本当ですか？私は混乱をあまり作りすぎていないといいのですが、それが今私が考えている現在の流れです。 更新 当初の意図は不明確だったので、言い換えます。TDDの使用中にユーザーストーリーをコードに変換するスクラムフローの詳細を知りたい。 開始点は明らかです。ユーザーはニーズ（または製品としてのユーザーの代表）を表面化します。これは、既知の形式で1〜2行の短い説明であり、製品のバックログに追加されます。 春の計画会議がある場合、ユーザーストーリーはバックログから取得され、開発者に割り当てられます。 開発者がコードを作成するには、要件が必要です（特に、要件はテストの派生元であるため、TDDで必要です）。 いつ、誰が、どの形式で要件がコンパイルされますか？ 私が頭に浮かんだのは、製品とQAが受け入れテストを介して要件を定義することです（私はFitNesseまたはソートを使用して自動で考えていますが、それは私が考えるコアではありません）同時に2つの目的を果たすのに役立ちます： 彼らは「完了」を適切に定義しています。 それらは、開発者にテストの派生元を提供します。 これらがいつ記述されたかはわかりませんでした（スプリントが選択される前に追加情報が届くか、ストーリーが選択されないため、繰り返しの間に開発者がスタックを待機する可能性があるため、これは無駄になります）。 ..）

8 agile  scrum  tdd  requirements  acceptance-testing 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 6年前休業。 特定の国でしか利用できない特定の知識があるため、私たちのスクラムチームは地理的に分割されています（私が知っているのは理想的ではありません！）。つまり、たとえば7人のメンバーからなる1つのチームには、ある都市にビジネスパーソンがおり、別の都市に2人の開発者、別の都市に2人の開発者、別の都市に2人のQAがいます。 このタイプのグラフィカルに分散したチームを管理する方法について何か提案はありますか？ベストプラクティスはありますか？ スタンドアップはどのように行うのですか？スカイプビデオ経由？私たちは人々が6週間ごとに旅行することを保証していますか？タスクボードをどのように実行しますか？事実上またはビデオを介して？この設定ではかんばんがうまく機能しますか？

8 agile  scrum 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 5年前休業。 背景：カンファレンス中に、アナリストはツイートで開発者がスクラムを嫌うと指摘しました。 私と他の人はこれはそうではないと答え、開発者がスクラムを嫌う理由についてのさまざまなシナリオについて議論し始めました。 その怠惰な開発者がスクラムプロジェクトに隠れることができないシナリオの1つ。彼らは常にチームから貢献を求められます。 この議論の結果、ブログ投稿とビデオ http://elsewhat.com/2010/05/20/lazy-developers-hate-agile-and%C2%A0scrum/ 私は中立的な方法で答えようとした3つのコメントを受け取りましたが、それらのコメントは、スクラムを嫌う人がいることを指摘しています（そして、私は常に怠惰な開発者ではないと確信しています）。 質問 開発者の間で、開発者がスクラムをどの程度好きまたは嫌いかについて調査したことがありますか？

8 scrum 

本番環境でのバグ管理の問題は、最近私の心の大きな特徴でした。Sprintはアイテムを追加することを意図していませんが、重大なバグの場合、これは単に避けられません。 このスプリントの中断をどうやって管理するのですか？スプリントに時間の「許容量」のパーセンテージを与えるだけで、スケジュールの80％を「念のため」にスプリントアイテムで満たすだけですか？

8 scrum  errors  sprint 

バックログを作成するとき、エラー処理やフィードバックなどのアプリケーションの側面など、非常に多くのユーザーストーリーに適用されるいくつかの要件があります。これらをどのように含めるのですか（各ユーザーストーリーで#includeディレクティブを使用せずに）？エラープレゼンテーションを機能として扱い、「システムが例外をキャッチし、情報をユーザーに表示する」など、この機能のユーザーストーリーを用意する必要がありますか？

8 project-management  agile  scrum 

構築したばかりの新しいプロジェクトバックログから2つのユーザーストーリーを達成しました（いい言葉ですか？）。これらはユーザー登録とパスワードのリセットで、どちらもメールが必要です。私が最初に選択したもの、および通常は信頼できるものが機能しなかったため、代替メールコンポーネントを実装する必要があります。メールコンポーネントのデバッグではなく、ユーザーストーリーの配信に重点を置いていたため、スプリントの最後に機能するコードを配信するためにそれを交換しました。メーラーの新しいサポート問題をログに記録しますか、それともこれらのストーリーをバックログに「再挿入」しますか？後者を実行する場合、ユーザーストーリーに技術の詳細をあまり紹介していませんか？

8 agile  development-process  scrum  user-story