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

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、議論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 スクラムとXPについて何を読むことをお勧めしますか。私はトレンチからスクラムとxpを持っていますが、価値のあるいくつかのリファレンスを見てみたいです。

9 scrum  extreme-programming 

あなたのアジャイル/スクラムチームのバグワークフローは何ですか？ これが私たちのものです：-バグが現在のスプリントのストーリーに関連している場合、それを修正します。-バグが現在のスプリントのストーリーに関連しておらず、重大でない場合は、優先順位付けのために製品オーナーに送信されます。-バグがスプリントのストーリーに関連しておらず、重大な場合は、修正します。

9 agile  bug  scrum  workflows 

私のマネージャーがチームに「今から成功したユーザーストーリーは評価の対象となるでしょう！」 と言ったとき 私たちはショックを受けてそこに座っていましたが、それは彼が私たちに与えたいくつかのあごを落とす瞬間の1つでした:-) これはアジャイル開発方法論のすべての概念と目標を台無しにするので、それは愚かな考えだと感じました。 みなさんの考えを教えてください。そして、どうすれば彼を説得できますか？

9 agile  scrum  productivity  user-story 

たとえば弱いコード所有権ではなく、スクラム方法論に従って集団的なコード所有権を実践する場合、絶対的な義務はありますか？

9 scrum  code-ownership 

スクラムの状況は次のとおりです。 特定のタスク（バックエンドのデータテーブルの実装）は頻繁に発生します 多くの場合、テーブルには類似しているがカスタム機能があります 各テーブルの実装には約1週間かかります（8ストーリーポイント） 最終的に、チームは4週間かけて再利用可能なコンポーネントを作成します 新しいテーブルの作成はほぼ瞬時に 私の質問： 出力/複雑度が変更されていないため、新しいテーブルストーリーはまだ8ですか？それとも、労力が最小限なので1ですか？ 私の研究：ジェフサザーランドとスクラムトレーニングを受けたとき、ストーリーポイントは出力を測定するため、ストーリーはまだ8であるという理解を残しました。PMはまだ同じテーブルを取得していますが、5倍速く配信されています。それは本当の速度の改善です（同じ作業を行うがより高速） しかし、私の理解が正しいことを確認したいと思います。何か助けはありますか？正式なスクラムの定義を探しています。私はscrum incのサイトを調査し、「半分の時間で2倍の作業を行うアート」を試してみましたが、私の理解が正しいか間違っているかを示すドキュメントが見つかりません。 ありがとうございました！ 更新 私は本当に正式なスクラム当局による文書へのリンクを探していました。以下の答えの多くは単なる人々の意見なので、この質問は誤解を招くと思います。

8 agile  scrum  estimation 

スプリントの真ん中にある毎日のスタンドアップミーティング中に、デファクトプロジェクトマネージャー/スクラムマスターは通常、開発者に次のバージョンを尋ねます。 「それで、これはいつ行われるのですか？」 「では、今日の午後4時までにこのタスクを完了させることはできますか？」 「このサブタスクには何時間残っていますか？」 これは率直に言って非常に迷惑であり、物事をより速く終わらせません。その結果、開発者は多くのプレッシャーにさらされていると感じることが多く、スタンドアップはコラボレーションよりも戦場のように感じることがよくあります。 開発者として、これを処理する確かな方法は何ですか？

8 agile  scrum  user-story  sdlc 

Pivotal Trackerの技術的負債のユーザーストーリーに対して、私たちは何をすべきですか？これらを特徴（ポイントを与える）または雑用（ポイントを与えず、速度を下げる）と見なす必要がありますか？ 私は雑用と見なされるべきものを混乱しています： コードの重複-複数の場所に同じコードを配置した場合、それはコードの習慣としては非常に悪いことであり、チームの開発者はソフトウェアを保守可能にするためにより多くの検討を行い、リファクタリングを行い、コードレビューに時間を費やす必要があることを示しています。これにはすべて、成熟度、時間、コードレベルの経験が必要になるため、提供するポイント数を少なくして、コードの品質が損なわれないようにすることをお勧めします。したがって、そのようなミスは罰せられるべきであり、雑用にポイントを与えないことによって速度を下げる必要があります。 テクノロジーのアップグレード-JS、HTTP2、React、MVCまたはその他の新しい/より優れたテクノロジーのモジュール化への移行のように。これらの手順により、コードのパフォーマンスとメンテナンスが改善されます。しかし、これは雑用か機能か？これがテクノロジーの世界のあり方であり、新しいテクノロジーが時々やって来て、それに移行する必要があると思います。したがって、そのような作業に対してチームの速度にペナルティを課すことには意味がありません。提案？ レガシーコードの複製/サブスタンダードコード-長い間使用されていないコードや、新しいチームが結成されたがコードベースが少し古い場合、この問題に直面します。チームはこのセクションをコーディングしていないので、なぜそれらの負債を作成したことがないので、なぜそのような技術的負債を選ぶことによって彼らの速度にペナルティが課せられるべきであるとチームは言います。 ビジネスの緊急性が原因の標準以下のコード-競合他社/ターゲット/ビジネス/ユーザーのプレッシャーが原因で、開発者は機能をすぐにライブでプッシュしなければならない場合があります。そのような悪いコードのクリーンアップも雑用（ポイントを与えない）と見なす必要がありますか？今回の開発チームに問題はないので、なぜ彼らの速度を下げなければならないのですか？ 上記のすべてのタイプの雑用は、賢明に行えば、将来的にチームの速度を向上させるはずです。しかし、チームの速度を維持しながらバランスを保ち、チームが悪い決定を下すことで技術的なミスを罰する必要があるでしょうか。 質問は次のようなものです。 技術的な負債は機能または雑用（またはバグ）としてスケジュールする必要がありますか？が、4つのポイントすべてを網羅する説得力のある回答が見つからなかったため、別の方法で再投稿しています。

8 agile  scrum  estimation  technical-debt 

有効にするために100のルールをカバーする必要がある検証エンジンがあるとします。 また、チームは反復ごとに約10のルールしか配信できないと仮定します。 ルールエンジンにコアルールの90がまだ不足している場合、最初の反復の終わりまでに「リリース可能な製品の増分」を行うにはどうすればよいでしょうか。 たとえば、すべてのルールが実装されていないという事実に基づいて常に起動する一時的な失敗/警告を追加しますか？ コンテキストの編集：私は、大規模なモノリスを複製して置き換えることを目的とした、多くのレガシーユースケースを持つ複雑なビジネスプロセス用のミドルウェアを開発しています。100％カバレッジなしでライブ配信するのは困難です。サービスを要求する運用で表示されるトリッキーなユースケースを決定または制限する機能が限られているためです。

8 agile  scrum 

問題のケース： スプリントはほぼ終了し、私のスクラムチームの1つはいくつかのタスクを完了しませんでした。（この理由は、この質問では必須ではないので、それに応じて対処します。）それらの1つは、かなり多くのストーリーポイントを持つ古典的な「90％完了」のケースであり、次のスプリントの一部になります。こちらの質問です。 バックロググルーミングと次のスプリントのためのいくつかの予備的な見積もりを行い、この未完成のタスクを処理する方法について説明しました。このスプリントの速度にはカウントされないことに私たちは皆同意していますが、真の複雑さと実行された総作業を次のようにしたいので、5つのストーリーポイントではなく1でほぼ完全なケースを再推定しないでください。まだ見えています。そして推定を振り返ってみると正しかった。-私たちは（スケーリングされた）アジャイルに移行しているだけであり、一部の管理レベルでは、提供された製品よりも多くの点で生産性を維持していることを「確認」する必要があります。 明らかに、このスプリントの速度は低下しますが、転送された「既に完了した」パーツは、次のスプリントで再び上昇するはずです。 これまでのところ、全員が同意しています。 しかし、私たちのチームはかなり小さいので、4ポイントは大きなかたまりです。このタスクのみで適切なドキュメンテーションがあれば、意識的に4つのポイントの過負荷を計画できると提案しました。 それは実現可能なアプローチですか、それとも私は まだ予想していない問題に遭遇する ほんの数か月前にアジャイルに移行したチームに悪い例を示しますか？

8 agile  scrum  planning  sprint  scrum-master 

私の現在のスクラムマスターは、公式のスクラムに屈することをいとわない真の信者です。私はこれが不確かに聞こえるようにしたくありません、私は過去に公式の用語で物事を再キャストすることによって彼と一緒に問題を解決することに成功しているので、この問題の正統な解決策について本当に尋ねています。 現在発生している問題の現在の例は、一部のストーリーの間に順序付けの依存関係があることです。（特に、開発の一部では、シングルシートライセンスしか持っていないサードパーティプログラムを使用しています。）これに関連するいくつかの必要なセットアップタスクがあり、「セットアップストーリー」にまとめられています。任意の順序で実行できるタスク。 問題は、現在のスプリントについて、セットアップストーリーと後続ストーリーの1つをプルしたことです。その時点で、スプリントが半分以下であっても、このグループでこれ以上のストーリーをとることはできないと述べました。このグループよりも優先度が低いバックログには無関係なストーリーがあり、スプリントに取り入れることをお勧めします。ただし、これらはすべて、このグループのストーリーの下で優先されました。この時点で、スクラムマスターは、「セットアップタスク」に群がってそれをより速く実行する必要があると述べました。これは、以前に発生した競合であり、彼は問題を抱えています。 したがって、このスプリントの前半では、2人の開発者と1つのテストリソースが、外部ベンダーの構成Webサイトでの作業、リソースのダウンロード、および証明書のシャッフルを監視しています。3つのスプリントでリリースされる予定で、POが希望するバックログのほぼ全体を取得できることはわかっていますが、誰もが座っている間はこれらのタスクで作業が行われていないので（er、群れ）最も優先度の高いストーリーのセットアップタスク。 私のスクラムマスターは、私たちの唯一の懸念は、スプリントに受け入れたストーリーを完成させることだと言っています。私は理解していますが、私たちは、製品の所有者から受け取った優先順位付けが引き起こしている「不良箱の梱包」を伝えないことによって、より大きな組織を失敗させているように感じます。 それでは、ストーリーと本質的に連続するストーリーとの間の依存関係の問題は、方法論によってどのように公式に処理されますか？

8 agile  scrum  scrum-master 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 私は18か月間、プログラマーとして（多くの顧客に再配布される）ガソリンスタンドの汎用ソフトウェア用に設計されたプロジェクトに取り組んできました。プロジェクトは大きいです。現在、約150のテーブルがあります。特定のアプローチは使用していません。適切に管理されていません。 personテーブルには今日約70列ありますが、15か月前には約30列でした。これらの新しいフィールドは、販売、財務、会計などの他のモジュールと統合するために登場しました。また、多くのフィールドが作成されてから削除されました。 その結果、多くのリファクタリングとリワークがありました。常に新しい要件が発生しているため、プロジェクトの準備はできません。 ここに私の疑問があります。通常の仕様アプローチを使用した場合、インタビュー、要件文書、アクティビティ、シーケンス、およびクラス図があり、「人」テーブルには70個のフィールドが必要であることを最初から知っているので、多くのリファクタリングを避けていました。 スクラムはこのプロジェクトに役立ちますか？この場合、スクラムも多くのリファクタリングを行うことになると思います。 私はプログラマーであり、プロジェクトマネージャーではありません。私はそれがどのように行われるべきであったのか疑問に思っています：スクラムまたは大きなデザインを前もって。 編集する この話の終わりを補足するだけです。8か月後、私はこの質問をしました。プロジェクトをいくつかの「テスト衣装」で生産した後、プロジェクトは公式に失敗しました。製品の所有者はプロジェクトを中止することを決定しました。問題の修正が難しくなり、多くのパフォーマンスの問題が発生しました。

8 scrum  requirements-management 

バックログが混乱するのを防ぐだけでなく、開発者の生産性を維持するためのベストプラクティスは何ですか 製品バックログにストーリーを追加できるのは誰ですか？また、これらのストーリーが特定の要件を満たしていることをどのように確認しますか？ たとえば、Feature Xの開発中にいくつかの小さなcssバグを見つけました。開発者として、バグを説明するストーリーをバックログの下部に追加することを許可する必要がありますか？それとも、製品の所有者と話し合う必要がありますか？ すべてのアイデア/バグを製品の所有者に渡すことは、ボトルネックの可能性があるようです。

8 scrum  product-owner  product-backlog 

私の組織では、スクラムチームがすべてのストーリーを100％完成させることはほとんどありません。私はスプリントごとにコミットするストーリーを減らすことを提案しましたが、R＆Dマネージャーは、そうする場合、人々はまだ作業を完了せず、それよりも少ないため、開発が遅くなると言います。彼はここで学生症候群が働いていると言います。 それについてどう思いますか？

8 scrum 

当社では、一括通知に使用する新製品をお届けする予定ですので、組込みソフトウェアプロジェクトであり、SCRUMを製品のフレームワークとしてご利用いただきます。 製品のバックログの記録を開始しました。私が理解したことに基づいて、製品のバックログは各アイテムのビジネス価値を反映する必要があります。組み込みソフトウェアの性質は、SPI、UART、イーサネット、WIFIなどのマイクロコントローラー用のドライバーを作成するために大量の時間を消費する多くの技術的詳細があることです。 たとえば、システムは通知のためにメッセージを再生することで音を出しているので、メッセージを再生することがビジネス上の価値であることは明らかですが、この目標を達成するために、どのような方法でもない要件を書き留める必要があります。 SPI、MP3デコーダーチップドライバー、SDカードドライバー、そして最後にFATなので、以前のすべてのドライバーには、製品バックログに書き込む必要がある要件があります。サブ要件。 これらはクライアントのビジネス価値を反映していません。製品のバックログをどのように作成するのですか？

8 scrum  embedded-systems 

ユーザーストーリーのバックログがあり、それぞれにストーリーポイントの推定数があるとします。今、スプリント計画を実行しています。 これで、ストーリーはタスクに分解されるはずであり、多くのスクラムリソースは、各タスクを人時間で推定する必要があることを示唆しています。この時点ではすべての質問についてチームが話し合っているため、タスクの見積もりに1分以上かかることはありません。ただし、タスクは1日より長くすべきではないため、8人の開発者による3週間のスプリントを想定すると、120タスクを意味し、見積もりにのみ2時間かかることは、私には少し多く思えます。 経験豊富なチームがタスクの見積もりをスキップまたはショートカットできることは知っていますが、まだその段階ではないとしましょう。 あなたの経験では、スプリントにはいくつのタスクがあり、それらすべてを推定するのにどれくらいの時間がかかりますか？（それらの半分だけを見積もることはあまり意味がありませんか？） 明確化： 答えはスプリントの長さとチームのサイズに依存するので、8人の開発者と3週間と仮定します。 言及された数値は経験則である可能性がありますが、それらがオフの場合（たとえば、より多くのタスク、それぞれを推定するために必要な時間の短縮）でも、推定には約2時間かかります。それで、おそらく質問は「計画会議の何パーセントが純粋なタスク推定のために予約されるべきであり、そして私たちがより良いことをすべきではないのか」であろう。

8 scrum  planning  user-story