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

私たちはプロジェクトでスクラムをフォローしています。ほとんどの場合、スクラムマスターがタスクを割り当てます。しかし、私は多くのスクラムの本を読んで、スクラムが逆に機能し（「プル」アプローチ）、チームメンバーがタスクや機能を取り上げることを読みました。スクラムマスターはタスクに正しいアプローチを割り当てていますか、それともアジャイルイデオロギーに反していますか？

19 project-management  agile  scrum 

「ユーザーストーリーは要件ではなく、顧客が望むものを思い出させるだけであり、ストーリー内に要件を置くことはできません」と言われました。しかし、顧客がクレジットカードごとに異なる処理を望んでいる例を見てみましょう。テストケースを作成できるように、実装する必要のある厳密な要件があります。ユーザーストーリーにない場合、要件はどこに行くべきですか？ より低い要件がない場合、開発者はストーリーからどのように開発できますか？テスターはユーザーストーリーに基づいてテストケース（詳細なケース）をどのように作成できますか？DB制約、フィールドの検証などの要件は、ユーザーストーリーの外側にありますか？

18 agile  scrum  requirements 

私は最近、まだ自分自身をセットアップしている若いハッカースペースに参加しました。幸いなことに、このスペースには作業が必要な内部プロジェクトがいくつかあり、作業を行うボランティアが不足していません。 これらのプロジェクトを整理する方法についていくつかの議論がありました。私の最近の専門的な経験はスクラムであったため、ソフトウェアプロジェクトにスクラムアプローチを提案することを検討していますが、それが適切かどうかはわかりません。 スクラムはフルタイムの小規模なチームでうまく機能しますが、この組織の性質は異なります。 メンバーはボランティアです。一部はフルタイムの学生です。他の仕事はフルタイムで仕事をしています。実際の生活が優先されるため、誰からも一定レベルの貢献は期待できません。 ほとんどすべての人がソフトウェアを作成する長年の経験を持っていますが、専門家やチームでこれほど多くのメンバーはそうしていません。 プロダクトオーナーはいません。これらのプロジェクトの要件は、委員会によって決定されます。この委員会のメンバーも実装に取り​​組んでいます。つまり、専任の専任のプロダクトオーナーはいません。 期限はありません（ソフトまたはハード）。プロジェクトは完了すると完了します。 これらはかなり重要な違いですが、私は彼らがスクラムを適用するためのブロッカーになるとは確信していません。ちょっとした微調整でこのハードルを克服できると思います。 スプリントを固定してストーリーポイントサイズを固定するが、継続時間（時間）が流動的である場合、ボランティア開発者に非現実的な配信のプレッシャーをかけることなく、繰り返しのリリースから利益を得ることができます。 バーンダウンチャートと速度計算を捨てることができます。私が正しく理解していれば、これらは開発チームと経営陣の間の橋渡しとして機能するツールと指標です。開発者と利害関係者の両方にとって意味のある形式で進捗状況を報告するのに役立ちます。報告する人がいない（プロジェクトマネージャー、プロダクトオーナー、外部関係者がいない）ことを考えると、これを完全に削除できると思います。 微調整を必要としないメリットがあると思います。 要件収集会議（複数可）。全員がテーブルの周りに座って、ユーザーストーリーについて議論し、UIモックをスケッチし、製品バックログを作成します。 スプリントの回顧展。これは、ボランティアチームとして機能する開発プロセスに集中するための興味深い方法です。 よくわからないこと： 毎日のスタンドアップはどのように扱われるべきですか？私たちの環境では、彼らは非常に価値があるのでしょうか。スタンドアップ式の儀式についての私の理解は、チーム全体に自然に情報を広めることでコミュニケーションを支援することです。私たちのスプリントはおそらく平均的なスプリントよりもはるかに少ない複雑さを提供する可能性があるという事実を考慮すると、他のすべてのチームメンバーの進捗状況/開発に遅れをとる必要が少なくなる可能性があります。 継続的インテグレーション、コードレビュー、TDDなどのXPを推進すべきですか？私はこれが多くを求めているのではないかと心配しています。人々がスクラムに精通し、チームとして働くようになれば、将来のプロジェクトでこれらの概念を取り入れたいと思うでしょう。 私の質問： スクラムはボランティアベースの環境に適応できますか？ そして、私の計画したアプローチはこれまで正しい方向に向かっていますか？

18 scrum  extreme-programming 

このプロジェクトでは、ゼロバグ（別名ゼロディフェクト）方法論で作業します。基本的な考え方は、バグは常に機能よりも優先度が高いということです。ストーリーの作成中にバグがある場合は、ストーリーを承認するために解決する必要があります。古いストーリーのスプリント中にバグが見つかった場合は、バックログに次に配置して解決する必要があります-最優先事項。 私が解決と言っている理由は、バグを常に修正するとは限らないからです。それほど重要ではないので、「修正しない」と宣言することもあります。全体的に素晴らしいですね。私たちは高品質の製品を出荷しており、巨大なバグのバックログの形で「こぶ」を運んでいません。 しかし、このアプローチが正しいかどうかはわかりません。深刻なバグをできるだけ早く修正する必要があり、重要ではないバグを破棄する必要があることに同意する傾向があります。しかし、重要ではあるが新機能ほど重要ではないバグはどうでしょうか？それらは適切な優先順位でバックログにファイルされるべきだと思う傾向があります。 より明確にするために例を挙げます-私のプロジェクトでは、flexで書かれたUIを使用します。すべての画面解像度で同じサイズで開くウィザード画面があります。ウィザードウィンドウを拡張すると、ページの1つが見栄えがよくないことがわかりました（ウィザードはすべてを表示でき、スクロールバーを必要としないにもかかわらず、消えない垂直スクロールバーがあります）。このバグは見苦しいと思います。修正する必要があると確信しています。しかし、私たちは厳しいスケジュールにあり、多くの機能を備えているので、カットを加えてリリースすることはできないと考えています。私たちはそのようなバグに耐えることができると感じています。修正する必要はありますが、他の機能よりも優先度が低くなります（したがって、完了できない場合は、少なくとも重要な機能を除外しませんでした）。だが、 「修正できない」とマークしたくないが、最も重要ではないバグに対処する方法について意見を聞きたいと思います。

18 agile  scrum  bug  backlog 

スクラムに関する最近の白熱した議論の後、私の問題は、管理が完全にアジャイルなチームで非常に不必要で冗長な活動であると考えることであることに気付きました。成熟したアジャイルチームは、管理や非技術的な意思決定プロセスを一切必要としません。私の（明らかに間違い）目には、成熟した開発チームを管理するのに適した能力があるのはコーチ（適切なコミュニケーションスキルを持つ最も技術的に有能な同僚）だけであることは明らかです。スクラムマスターがこのようなチームにどのように貢献できるか想像できません。 私は、スクラムとそのようなベテラン開発者ではないが、チームにコーチがいる場合の生産サイクルの計画に長けているマネージャーの価値を理解し理解するのに非常に苦労しています。それは一体何の意味ですか？開発の最先端スキルを持たない人が高度な技術チームを管理するにはどうすればよいのでしょうか？おそらくここでの管理は何か他のものを意味するのでしょうか？ 管理は時間の無駄であり、未熟さの副産物だと考えています。私の理解では、成熟したチームは完全に自己管理しています。どうやら私は多くの偉大な人々が反対を言うので間違っていますが、私は自分を納得させることができません。

18 agile  scrum  management  extreme-programming 

最近、「xページからログインページに移動するとエラーが表示されます。そのエラーを削除したい」というアイテムが製品所有者によって製品バックログに追加されました。 これはユースケースではなく、PBI（Product Backlog Item）であってはならないようです。しかし、私が議論したとき、スクラムマスターは、ユーザーストーリーはPBIではなく、PBIはバグレポート、タスク、ユーザーストーリー、あらゆるもの、文字通り最初に対処する必要のあるアイテムであると教えてくれました。 これについてはわかりません。また、ウェブ上でPBIの適切な定義を見つけることができません。だから、私の質問は、どのようなものがアイテムとして製品バックログに入ることができるのですか？製品バックログアイテムはユーザーストーリーにマッピングされますか？彼らは同じですか？

18 agile  scrum  definition  product-backlog 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 で別の質問、私は、開発者が好きではないかもしれない理由について尋ねた毎日スクラム。開発者と話をして、しばらくの間毎日のスクラムを開催しないことにしました（最初の試みで試してカスタマイズしたスクラムを提供するため）。これは、開発者と直接相談した結果です。 一方、開発者を毎日調整する機会を得たり、主要業績評価指標のように作業の進捗を監視したりして、早期にアクションを起こすなど、毎日のスクラムの良い部分を失いたくありません。 毎日のスクラムに代わるものとして、開発者に次の条件で毎日のレポートを提供するよう依頼することを考えています。 特定の形式に従う必要はありません。すべての形式が受け入れられます。 作業が完了していなくても、進捗状況を聞きたいと思っています。 各タスクに費やされた時間を言及する必要はありません。 開発の障害と調整の要件に言及する必要があります。 毎日のレポートに取りつかれている必要はありません。そんなに厳しくはありません。 これにより生産性が低下すると思いますか？日報の経験はありますか？マイクロ管理を行っていないことを確認できるように、何か提案がありますか？

18 productivity  management  scrum  meetings  reporting 

チーム内で初めてスクラムを実装するとき、チームの速度がわからないときに、最初のスプリントにあるストーリーポイントの量をどのように決定する必要がありますか？ これは時間の見積もりに基づいており、後の段階でのみポイントを使用する必要がありますか？

18 scrum  planning 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 スクラムはプロジェクト管理の方法論ですが、現在の状況にかなり満足しているチームの開発者にどのようにそれを「販売」しますか？ スクラムがどのようにして定期的なリリースを取得し、要件を修正し、最初に優先度の高いストーリーにチームを集中させることができるかをプロダクトマネージャーに説明するのは簡単なようです。TDDまたは継続的インテグレーションが開発者の日常生活にもたらすものを簡単に説明できました。 しかし、開発者はどのようにしてスクラムを採用することを確信できますか？スクラムはどのように彼らの人生を楽にしますか？

18 scrum 

チームメンバーが年次休暇を取っているとしましょう。彼はスプリント計画には参加しませんが、イテレーション/スプリントの半ばまでに戻ってきます。彼が50％のキャパシティを持っているとしましょう。つまり、イテレーションの後半で利用できるようになります。 彼が戻ってきた後に彼と計画セッションを持っています。 彼が年次休暇をとる前、すなわちスプリント計画の前に、彼と計画を立てる。 タスクのスケジュールを立てたり、スパイクなどの非スプリントタスクに割り当てたりしないでください。 スプリントプランニング中に同僚に代わって計画を立てさせ、欠席している人が戻ってきたときにタスクを追加したり、すべての作業を実行できない場合はスコープを解除することができます。 彼に別の開発者と一緒に座ってもらい、しばらくの間ペアプログラミングを行います。 他に何か.. 私はあなたが何をしているのか知りたいです。 注：私たちは（1）を行っていますが、正しくないと感じています。

18 scrum  sprint 

ソフトウェアの開発方法を改善したい。より速く、優れたコードを開発したい！今日、私はフリーランサーとしてウォーターフォール法を使用し、Webスタッフ（サイト、システムなど）を作成しています。このように動作するアジャイル開発（XP、SCRUMなど）を使用する方法はありますか？アジャイル開発について何も知らないのですが、どこから始めればいいですか？どうもありがとうございました。

18 agile  freelancing  scrum  web 

アジャイル手法をどのように適用するかは、大規模で複雑な組み込みシステムソフトウェア（100人以上のエンジニア）に本当にあるのかといつも思っていました。ファームウェア開発には、アジャイルを実行するのを難しくするいくつかの独自の特性があります（つまり、ハードウェアは開発サイクルの後半まで利用できません。製品がリリースされると、ファームウェアを簡単に更新できませんなど）。 この種の開発の標準は、厚手のドキュメントと厳しいピアレビューです。2〜3個の署名なしで変数の名前を変更するなどの簡単なコード修正を取得することはできません。（少し誇張しますが、これは典型的なことです。さらに、多くの人がショートカットを採用しており、特に厳しい市場の締め切りに直面して、プロジェクトマネージャーはそれらを承認します。） ファームウェア開発プロジェクトにアジャイル手法を採用する方法に関するヒントやガイドラインを聞きたいです。

17 agile  scrum  embedded-systems 

チケットの推定時間を作成するとき、テスター（QA）にかかる時間をチケットの推定に含める必要がありますか？以前は、テスターの時間なしで常に見積もっていましたが、常にそれを含めることについて話し合っています。チケットがあと1週間でかかる合計時間を知る必要があるため、現在のスプリント、リリース前の最後のスプリントには意味があります。 チームのリソースを制限する傾向があるため、見積もりは開発者向けの時間であると常に理解していました。同僚は、テスターの時間より前に働いていた場所はどこでも含まれていると言っています。 明確にするために、これは、開発者が適切なカバレッジでユニット、統合、およびUIテストを記述しているプロセスのためのものです。

17 agile  scrum  estimation  qa 

スクラムには、チーム、プロダクトオーナー、スクラムマスターの3つの役割が定義されています。プロジェクトマネージャーはいません。代わりに、プロジェクトマネージャーの仕事は3つの役割に分散しています。 例えば： スクラムマスター：プロセスの責任者。障害を取り除きます。 プロダクトオーナー： ROIを最大化するために実行する作業のリストを管理および優先順位付けします。すべての利害関係者（顧客、利害関係者）を表します。 チーム：自分自身で作業を見積もり、配布することにより、作業を自己管理します。自らのコミットメントを満たす責任があります。 したがって、スクラムでは、プロジェクトの成功を担当する責任者は一人もいません。コマンドとコントロールの構造はありません。それは多くの人々、特にアジャイル手法に慣れていない人々、そしてもちろんPMを困惑させているようです。 私はこれとスクラムの実装を壊す可能性があるものの1つだと思うので、これとあなたの経験に本当に興味があります。 プロジェクトマネージャーは必要ないという点でスクラムに同意しますか？そのような役割はまだ必要だと思いますか？どうして？

17 project-management  agile  scrum 

アジャイルソフトウェア開発は、最近ではかなり楽しい流行語になりつつあります。 開発者として、私は反復開発の実際的な価値を理解していますが、（ほとんどの場合）ソフトウェア開発へのアジャイルアプローチを採用することは開発者の選択ではありません。トップダウンの管理選択です！クリスタル、アジャイルメソッド、dsdm、rup、xp、スクラム、fdd、tddのいずれであっても、名前を付けてください。開発者の選択ではありません。 世の中のすべてのマネージャーにとって、（私の経験では）ほとんどのマネージャーがコードの一部に触れさえしていないときにアジャイル開発を選択する最大の理由は何ですか？

17 project-management  agile  management  project  scrum