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

私たちのスプリント計画会議は面白くないだけでなく、実に恐ろしいものです。 会議は退屈で退屈で、永遠にかかります（1日ですが、ずっと長く感じます）。 開発者はそれについて文句を言い、今後の計画を恐れます。 私たちのルーチンはかなり標準的です（優先順位によってスプリントバックログに挿入されるユーザーストーリー>>ストーリーはタスクに分解されます>>タスクは時間単位で見積もられます>>繰り返し）、何が間違っているのかわかりません。 どうすれば会議をもっと楽しくすることができますか？ ... 詳細情報のリクエストへの応答として、さらに詳細を示します。 バックグラウンドアイテムがスプリントキックオフの前に挿入および優先順位付けされないのはなぜですか？ ユーザーストーリーは確かに優先されます。それらをタスクに分解するまで、どれだけ時間がかかるかわかりません！ここの（優れた）回答から、タスクをまったく推定すべきではなく、ユーザーストーリーのみを推定すべきであることがわかります。タスク（ストーリーではなく）を見積もる理由は、ストーリーの見積もりがひどく間違っているためです。しかし、それはまったく異なる質問の主題だと思います。 開発者が文句を言うのはなぜですか？ 会議は長いです。 会議は単調です。ストーリーごと、タスクごと、苦労（はい、苦労）にかかる時間とその内容を推定します。 タスクを見積もると、ユーザーストーリーの推定が無意味に見えます。 会議が長ければ長いほど、部屋に集中できなくなります。集中力の低い同僚ほど、会議に時間がかかります。再帰的なヘイトスパイラルが発生します。人々を集中させるために会議を2日間に分割することを検討しましたが、開発者はそれを聞きませんでした。計画の1日で十分です。これで2つになります。 私たちの問題の一部は、（より正確な推定を得るために）非常に小さな詳細になることです。しかし、おおよその見積もりをするときは、大したことはありません！ 質問を要約するには： 私たちは何を間違っていますか？ 一般的に会議をより楽しくするために、他にどのような方法がありますか？

51 agile  scrum  sprint  meetings  process-improvement 

ストーリーポイントをバグ修正タスクに割り当てる必要があるかどうかだけを考えています。私たちの問題追跡ソフトウェアであるJIRAには、バグタイプの問題のストーリーポイントフィールドがありません（StoryおよびEpic専用です）。 ストーリーポイントフィールドの該当する問題タイプにバグ問題タイプを追加する必要がありますか？長所と短所は何ですか？スクラムに適しているでしょうか？

50 agile  scrum  bug  user-story 

私たちはスクラムを使用していますが、時折、それが計画されたスプリントでユーザーストーリーを完了できないことがあります。とにかく真のスクラムスタイルでソフトウェアを出荷し、次のスプリントプランニングセッション中に次のスプリントにユーザーストーリーを含めることを検討します。私たちが引き継いでいるユーザーストーリーが部分的に完了している場合、次のスプリントプランニングセッションでどのように正しく見積もることができますか？私達は考慮しました： a）ストーリーポイントの数を減らして、ユーザーストーリーを完了するために残っている作業のみを反映するようにします。残念ながら、これは製品バックログの報告を台無しにします。 b）部分的に完了したユーザーストーリーを閉じて、新しいストーリーを作成して、ストーリーポイントの少ない残りの機能を実装します。これは、そのスプリントで完了しなかったものを遡及的に見る能力に影響し、少し時間がかかるようです。 c）aまたはbのいずれにも煩わされず、スプリントプランニング中に「ユーザーストーリーはXストーリーポイントかもしれませんが、95％が終了していることを知っているので、それが収まると確信しています。」

50 agile  scrum  estimation  planning 

仕事中の私のチームはスクラムに移行しており、他のチームは単体テストとユーザー受け入れテストを使用してテスト駆動開発を始めています。私はUATが好きですが、テスト駆動開発または一般にテスト駆動開発の単体テストで販売されていません。 テストを書くことは余分な作業であり、実際のコードを書くときに人々に松葉杖を与えるようで、あまり効果的ではないかもしれません。 ユニットテストがどのように機能し、どのように記述するかを理解していますが、それは本当に良いアイデアであり、努力と時間の価値があると主張することができますか？ また、スクラムにとってTDDが特に優れているものはありますか？

48 unit-testing  scrum  tdd 

公的機関から、スクラム、かんばんなどの用語と概念を説明するアジャイル開発の101に関する非公式ワークショップを行うように依頼されました。私は約5年間アジャイル環境で働いてきましたが、私はスクラム伝道者とは思いません。 ワークショップの後、彼らはそのアイデアを気に入りました。しかし、彼らは外部のソフトウェア会社に彼らのためにソフトウェアを開発するよう依頼する必要があるので、彼らにはアプローチがおそらく適用されないだろうと説明した（彼らは少数の開発者しかいない）。この活動は、結果、価格、および期間を説明する公開入札プロセスで行う必要があります。これは、この組織（公的研究機関）の予算を申請するための法的要件です。 これらの制約は、アジャイル開発の基本原則とは幾分矛盾しています。 スクラムはそのような環境では互換性がありませんか？ この組織に何をお勧めしますか？

43 agile  project-management  scrum  government 

開発者は、各スプリントのマスターブランチへのストーリーの統合について懸念を表明するレトロコールを終了しました。開発者はすべて自分のブランチ内のコードを作成し、スプリントの終わりに向かってすべて1つのマスターブランチにマージします。 次に、ある開発者（通常は同じ開発者）に、すべてが他の開発者のコ​​ードとうまく統合されていることを確認するタスクを残します（ほとんどの変更は同じページにあります。たとえば、データ表示ストーリー、データフィルターストーリー、 SLAインジケータ）。 この負担を軽減し、コードをより簡単にマージするにはどうすればよいですか？私の観点からすると、POまたはSMがストーリーをより効率的な方法で優先順位付けすることで、同じスプリントでこれらの種類の依存関係がなくなるため、いくつかの問題が解決する可能性があります。他のみんなはどのようにこれに取り組んでいますか？または、これはプロセスの一部ですか？

42 agile  scrum  branching  stories 

リード開発者以外のアジャイル開発チームでは、一般的に： 標準を設定します（コーディングなど） チームの新技術を研究する チームの技術的な方向性を設定します 問題について最終決定権を持っています システムのアーキテクチャを設計します ただし、アジャイルチームの動作は異なります。 アジャイルチームは、前もってではなく、新しいデザインに依存します アジャイルチームは、1人が設計を指示するのではなく、一緒に設計します アジャイルチームは、プロジェクトを提供するのに最適な独自の技術的方向を決定します これにより、アジャイルチームの主任開発者はどこに残りますか？アジャイルチームにリード開発者を置くことは可能ですか？アジャイルチームはリードに異なる責任を要求しますか？

42 design  architecture  agile  scrum  team-leader 

アジャイルマニフェストの設立原則の一つは アジャイルプロセスは持続可能な開発を促進します。スポンサー、開発者、およびユーザーは、一定のペースを無期限に維持できる必要があります。 スクラムチームは、スプリントという用語を使用してワークサイクル（反復とも呼ばれます）を指します。 しかし、これは私には意味がありません。Googleによると、スプリントは次のとおりです。 短距離で全速力で走る。 言い換えれば、それは持続可能ではありません。なぜスクラムチームはスプリントという言葉を使用するのですか？私には、アジャイルの基本原則の1つと対立するように思われます。

41 agile  terminology  scrum 

私はアジャイル開発の大ファンであり、数年前に非常に成功したプロジェクトでXPを使用しました。私はそれについてのすべて、反復開発アプローチ、テストの周りのコードの記述、ペアプログラミング、物事を実行するための顧客を現場に持っていることが大好きでした。それは非常に生産的な職場環境であり、私はプレッシャーにさらされているように感じたことはありませんでした。 しかし、私が働いた最後のいくつかの場所はスクラムを使用/使用しました。最近のアジャイル開発の代表的な子であることは知っていますが、アジャイルであることを100％確信しているわけではありません。以下に、私にとって俊敏性を感じない主な理由を2つ示します。 プロジェクトマネージャーは大好き 本質的にタイムラインに夢中になっているプロジェクトマネージャーは、すべてスクラムを気に入っているようです。私の経験では、彼らは時間要件を追跡し、特定のタスクに費やされた時間の記録を保持する手段としてスプリントバックログを使用しているようです。ホワイトボードを使用する代わりに、全員がExcelシートを使用します。各開発者はそれを宗教的に記入する必要があります。 私の意見では、これはアジャイルプロセスのための非常に多くのドキュメント/時間追跡です。タスク自体に取り掛かることができるのに、タスクがどれだけの時間を要するかを見積もるのに時間を無駄にするのはなぜですか。または、同様に、手近な次のタスクに移動できるときに、タスクにかかった時間を文書化するのに時間を浪費するのはなぜですか。 スタンドアップミーティング 私が以前働いていた場所でのスタンドアップミーティングは悪夢でした。毎日、昨日やったことと、その日に何をしようとしていたかを説明しなければなりませんでした。タスクの「見積もり」に時間を費やした場合、プロジェクトマネージャーは悪臭を放ち、タイムラインを順守していないためにあなたが無能であることを示す手段としてスプリントバックログを参照します。 今、私はコミュニケーションの必要性を理解していますが、確かに毎日の会議の雰囲気は軽やかで、知識の共有に焦点を当てるべきです。私はそれがあなたの宿題スタイルのシャレードの場所になるとは思わない。また、アジャイルの重要なポイントは、タイムラインが変更されることであり、それらを固定するべきではありません。 結論 アジャイルのアイデアは、開発者の生活を楽にすることでソフトウェアを改善することです。したがって、私の意見では、チームが使用するアジャイルプロセスは開発者主導である必要があります。プロジェクトマネージャーが、プロジェクトを追跡するために「アジャイル」とラベル付けしたプロセスを使用することは、アジャイル開発と関係があるとは思わない。 誰でも考えますか？

41 agile  scrum 

私は新しく設立されたチームのスクラムマスターになりました。このチームは、ソフトウェアの作成と、デプロイされた他のアプリケーションの保守を担当しています。したがって、基本的に各チームメンバーには開発および運用タスクがあります。 過去数週間、彼らがどのように機能するかを観察してきましたが、これらのタスクの調整にチームが問題を抱えていることに気付きました。開発者がコーディングに集中していると、本番で発生した問題を修正するために中断され、以前のタスクに再び集中することは困難です。 開発作業時間の％を運用作業に割り当てようとしましたが、明らかにこれは問題を解決していないようです。以前にこの状況に遭遇したスクラムマスターからの連絡に興味があります。どのようにそれを管理し、どのような推奨事項がありますか？

40 agile  scrum  scrum-master 

毎日のスクラムを保持することには、次のような利点があります。 チームは互いに調整されます 誰がどの程度のタスクを実行したかを知っています バーンダウンチャートはますます完全になります タスクボードが更新されました それほど長くは続かない、15分は誰も殺さない しかし、最近（6か月間のスクラムの実装と使用後）、開発者は毎日のスクラムがあまり好きではなくなったように感じます。人々は十分な説明をせずにタスクボードを更新するだけで、退屈しているようです。何らかの理由で、私たちはそれを保持しないとき、彼らは一種の特別な幸せになることがわかります。 私はこれで何が間違っているのか分からない。チームにとって「デイリースクラム」が持つ不利な点について、どこかで言及された理由はありますか？開発者が毎日のスクラムに飽きた理由は何でしょうか？

40 project-management  scrum  meetings 

毎日のスタンドアップミーティングはどれほど価値があると思いますか（またはそうでないと思いますか）？ あなたがそれに慣れていない場合、これはスクラムの支持者の一部である毎日の会議を指します（および他のいくつかのアジャイル方法論）。アイデアは、15分のタイムボックスで毎日会議を開催し、全員が立ち向かわなければならないということです（人々がそのポイントになるように促すため）。 会議では、部屋を歩き回って各自が次のように言います。-昨日あなたがしたこと-本日あなたがすることを計画していること-進行の妨げや障害 この実践には価値があると思いますか？誰かがそれをした場所で働いたことがありますか、あなたはどう思いましたか？

40 agile  scrum  meetings  development-methodologies 

そのため、スクラムスプリントは、特定の機能セットを実装する必要がある固定期間です。そして、スクラムチームは、これらの機能を提供することに全力を注いでいる人々で構成されており、その大部分は通常、開発者とテスターです。 これらのルールを確立した後、スプリント全体でこれらすべての人々を忙しく保つ方法を疑問に思うかもしれません。スプリントの開始時にはまだテストするものはありません。また、スプリントの終了時には、通常、開発/修正するものがまったくないか、ほとんど残っていません。 これを処理する2つのアプローチを見てきましたが、どちらも問題を適切に解決していないようです。 1）チームメンバーに、タスクがなくなったときの対処方法を決定させます。 短所： 彼らがすることを徹底的に計画していない場合（すなわち、主要なリファクタリング、新しいテストフレームワークへの切り替え）、彼らの仕事は役に立たないか、途中で立ち往生するかもしれません 一方、そのような作業の計画には多くの時間がかかる可能性があり、クライアントは即座に価値をもたらさないものにチームが時間を浪費するのを見ることに失望するかもしれません 通常、このようなタスクは完全に見積もることができないため、未熟な労働者がスクラムボードや他の場所に反映されることなく、YouTubeの猫を見ることに時間を費やすことは非常に簡単です。 2）スプリント内に開発専用のスペースを確保し、スプリントの終了後にテストを開始します（開発者が次のスプリントから機能の作業を開始するとき） 短所： 現在のスプリント用の機能を開発している間、開発者は前のスプリントからバグを修正することに気を取られ、現在のスプリント中に行われると推定された量の作業を実行できない可能性があります 2つのスクラムボードが必要です。1つは現在のスプリント機能用で、もう1つは以前のスプリントバグ用です。 だから私の質問は、スプリント中に開発者とテスターの間で作業を適切に分散して、誰も作業で過負荷になったり、いつでもタスクなしで終わることがないようにする方法ですか？上記のアプローチを改善する方法はありますか？または、より良いアプローチがありますか？

33 agile  scrum  sprint 

スクラムチームは、計画会議で開発/インフラストラクチャタスクをどのように考慮しますか？ 一見、エンドユーザーの価値を提供しないため、ユーザーストーリーのようには見えません。 ただし、それらをタスクとして特定のユーザーストーリーに添付することも意味がない場合があります。たとえば、タスクが「Bambooのセットアップ」であるとします。チームが手動でビルドおよびデプロイできるため、ユーザーストーリーを完了するためにそのタスクは必要ありません。そのため、ユーザーストーリーを完了するのにこのタスクは必要ないため、ユーザーストーリーに添付しても意味がありません。 したがって、これは、これらのタスクがユーザーストーリーになることを示唆しています。しかし、その後、チームストーリーがそれらを指し示している場合、プロダクトオーナーがバックログに対して速度を知りたいので、これに奇妙な速度が変更されます。

33 scrum  planning 

「典型的な」SCRUMチームがあり、スプリントで働き、バックログを維持することを約束します。最近、帯域外作業（通常の労働時間/スプリント以外で作業することを選択）を行っている、過剰に達成している開発者の作業を統合/処理しようとする問題に遭遇しました。 例として、チームが50ポイントの仕事を引き受ける場合、スプリントの終了までにSCRUMフレームワーク内ですべての仕事を完了し、彼らと会社は満足しているとしましょう。チームメンバーの1人が、自分で、バックログアイテムで、自分の自由時間に取り組むことにしました。彼らはこの作業をチェックインせず、代わりに保存します（TFSを使用し、シェルフセットにあります）。 これを処理する方法は？問題のいくつか.. 次のスプリント中に、このチームメンバーは、プログラミング作業が99％完了し、コードのレビューとテストのみが必要であると言います。SCRUMおよびアジャイル方法論でこれをどのように扱いますか？ 他の開発者は、作業が帯域外で行われたため、これらのストーリーに関連する設計決定に関与していないことに不満を述べています。 私たちの製品所有者はこの「無料」の仕事を引き寄せようとしますが、チームがスプリントで達成できないような機能を製品に追加するために、過剰達成メンバーが意図的にこれを行っている可能性があります。これが「プロセス」を壊しているという見方があります。明らかに、QA、UI、およびドキュメントの作業をこの作業で行う必要があります。 SCRUMチームに時間外労働を強制しないことについて多くの議論がありますが、スプリントの計画と実行中に出された期待以上の仕事をしているチームメンバーはどうでしょうか。私はこの人物を統治することをheし、あなたが余分に働くことはできないと言います（もちろん燃え尽きないように注意してください）が、同時にそれはチームの特定のメンバー（しかしすべてではない）でいくつかの問題を引き起こしているようです。 達成度の高いメンバーが行った作業を、ソフトウェア開発のSCRUMおよびアジャイルプロセスに統合する方法

32 agile  scrum  team