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

14日間のスプリントの反復があり、新機能、いくつかの改善点、および修正すべきバグのストーリーがいくつかあるとします。また、準備が整ったときにこれらの変更をデプロイします。スプリントの終了を待ちません。 私の問題は、このように開発および保守された製品のセマンティックバージョニングを追跡する方法ですか？14日ごとにリリースされる場合は簡単ですが、バージョン番号を増やし、すべての変更を変更ログに記録します。しかし、変更が継続的にデプロイされるとどうなるでしょうか。何かがデプロイされるたびにバージョンを上げる必要がありますか？または、スプリントが終了するまで待ってから、「再開」して、実際の展開で独立して反復ごとに1回だけバージョン番号を増やす必要がありますか？アジャイルのセマンティックバージョニングのベストプラクティスは何ですか？ 編集：私のニーズをよりよく説明するために、私は最初に利害関係者の変更ログを求めています。変更がデプロイされるたびに、変更ログの新しいレコードに関心を持つことはないと思います。

10 agile  scrum  versioning 

スプリントが早く終了したらどうしますか？ 現時点では、スプリントチームがスプリントが早期に終了した場合、バックログからストーリーを作成します。 バックログから取得したストーリーはどうなりますか？ストーリーは現在のスプリントに追加されますか？もしそうなら、これらの物語が間に合わないとしたらどうでしょう。その後、スプリントは失敗しましたか？

10 scrum  sprint 

私はシステムの所有者と私自身の両方が開発者であるシステムを書いています。現在、システムへの「要求」またはシステムの要件の唯一の情報源であり、機能に関連付けられたユーザーストーリーにそれを記録したいと考えています{1}。私の緊急の優先事項は、現在、管理可能なバックログを取得することです。ユーザーストーリーでの作業に慣れている技術仕様のレベルをキャプチャするにはどうすればよいですか。 {1}アジャイルプロジェクト管理サービスTargetProcessを評価しています。各ユーザーストーリーは親機能に関連付ける必要があります。システムは適切だと思われるので、この小さな制約は、回避するよりも私が作業したいものです。

10 project-management  agile  scrum 

スプリント中にリリースする頻度。スプリントの最後、または機能の準備ができるたびに。そして、バグ修正リリースをどのように処理しますか？

10 scrum  release-management 

私たちは最初のスプリントの真ん中にいて、何かが明け暮れています。 この2週間の反復で理想的な114時間を計画し、最初の週の終わりにスプリント全体を完了しました。今何をすべきか？「本」は、バックログから次の優先度の高いアイテムを取得する必要があることを示しています。しかし、それらをバーンダウンチャートに追加するにはどうすればよいでしょうか。それらを最初から存在しているかのように説明するために書き直しますか？あるいは、それらの作業を開始する日にy軸にそれらの推定値を単に追加します（90度の角度ジャンプを示しています）。 どんなフィードバックでも大歓迎です！

10 scrum  planning 

スクラムでの役割は、プロダクトオーナー、スクラムマスター、およびスクラムチームです。ユーザーストーリーは、タスクと呼ばれる小さな部分に分解する必要もあります。タスクには、定義、割り当て、実装、フォローという4つのフェーズがあるようです。 タスクについてスクラムで誰が何をすべきか？タスクの残り時間を更新するのはスクラムマスターの責任ですか、それとも開発者（スクラムチーム）の責任ですか？開発者は自分にタスクを割り当てる必要がありますか、それとも製品の所有者が伴うスクラムマスターの責任ですか？

10 scrum  scrum-master  user-story  task 

私のちょっとした背景-私はSCRUM（1〜2週間のスプリント）を使用したアジャイル環境内で約2年間、手動テスターです。そこで、Selenium WebDriver（Javaを使用）を使用した作業に自動化テストを導入したいと思います。 私の質問は、いつ機能を手動でテストする必要があるか、いつ自動化テスト用に変換する必要があるかです。 私は次のようなさまざまなアプローチを読んでいます。 新しいスプリントの開始時に、ユーザーストーリーを以前のスプリントの自動スクリプトに変換するか、または 同じスプリント内でユーザーストーリーを変換します。 アドバイスは非常にいただければ幸いです。前もって感謝します。

9 testing  agile  scrum  selenium  test-automation 

人々が私に潜在的に明白な質問を甘やかしてくれることを願っています。私は、毎日スクラムミーティングを行う多くの組織で働いています。一部の組織はチェックインにスクラムのみを使用することに非常に厳格です（「3つの質問」-昨日何をしましたか、今日何をしているのですか、ブロッカーはいますか）。他の一般的な傾向がある他の組織発表または詳細な技術的ディスカッション。 この記事のように、チェックインに関連しないこのようなディスカッションを許可することは誤りであるという意見を聞いたことがあります。スクラムミーティングは、スクラムマスターからの一般的な発表、技術的なディスカッションなどには使用しないでください。 これから私が目にした主な害は、会議が必要以上に長く続く可能性があることです（そして、私に関係のない詳細の議論に座ることを余儀なくされるのは面倒です）。 グループ全体に関連しておらず、「3つの質問」の一部でもないディスカッションは、スタンドアップの一部であってはならないことは明らかです。しかし、グループ全体に関連する他のアナウンスがあり、とにかく議論する必要がある場合、その時点で（個別の会議や電子メールではなく）アナウンスを行うことは有害ですか？

9 agile  development-process  scrum 

私はアジャイルチームのプロダクトオーナーです。私はPO受け入れテストを行うとき、通常いくつかのエッジケースを試すことを書き留めます。私が何かを発見するのは珍しいことではなく、それを開発者に渡します。開発者の話を拒否すると、開発者の1人から反発を受けます。彼は私がストーリーで説明するものだけをコード化する傾向があるため、エッジケースとプログラムが許容基準でどのように応答する必要があるかを指定しないので、彼は不公平だと言います。コーディング中にエッジケースにぶつかったときに私に尋ねるように彼に勧めましたが、彼はエッジケースをじっくり考えるのは自分の仕事ではないと考えており、次のスプリントのために新しいストーリーを作成する必要があります。 私の弁護では、彼がストーリーを実装するまで彼のストーリーのデザインがわからないので、すべての可能性を繰り返すことは困難です（構成はDBまたはプロパティファイルにありますか？）。簡単にするために、電卓アプリに除算を追加するストーリーがあるとします。理想的なSCRUMの世界では、「ゼロによるハンドル除算シナリオ」を受け入れ基準に追加するのは私に任されているのでしょうか、それともアプリが5/0に爆破しないように開発中にそれらのケースを処理する必要がありますか？明確に言うと、この場合、アプリが5/0で激しくクラッシュした場合は受け入れませんが、ログに記録したり、DIV0を出力したり、その他の方法でエラーを処理したりすれば合格します。クラッシュしない。

9 scrum  acceptance-testing  product-owner 

私はスクラムミーティングで、開発者がストーリーについて現実的な見積もりを行うことが多いことに気付きました。ただし、かなり単純なストーリーであっても、構成、サードパーティコンポーネントのセットアップ、テスト、最終ビルドに多大な労力が必要であり、システムにはかなりの技術的負債が蓄積されているため、製品の所有者や管理者にとって見積もりが高すぎることがよくあります。 POは次のような見積もりを頻繁に打ち消そうとします。たとえば、「このストーリーには13ストーリーポイント[4日間]が必要です。これは不可能です。これを経営者に説明することはできません。誰かがこれをコーディングできるはずです。 3 SP [4時間以内]で！」その結果、開発者は5または8ストーリーポイント（1.5〜2日）の見積もり（スクラムの見積もりは、単なる予測ではなく、コミットメントと見なされます）にコミットするために腕をひねります。 もちろん、（主にテストと品質に関する）期待を排除する計画がなければ、これらのスプリントは頻繁に失敗します。開発者の見積もりは正直で現実的なものであり、見積もりを打ち負かしても実際に行われる作業に影響が及ぶことはありません。 「誰かがあなたにそうするように強いたからといって、あなたは不可能な約束をするべきではありません！」しかし私の意見では、開発者の仕事はソフトウェアの設計とコーディングであり、交渉や圧力に対抗することではありません！すべての取引のジャックが存在する可能性がありますが、通常は外部の顧客と直接取引しますが、これはオフィス開発者の大多数ではありません！ 私にとって、この実践は、プログラマーをぎくしゃくさせ、絶え間ないスプリントの失敗を引き起こし、現実的な見積もりを妨げるだけでなく、実際の改善点も探します。 スクラムガイドラインはこのトピックについて何を言っていますか、または彼らはそれに何を言っていますか？ 編集：時間をストーリーポイントに置き換えました。私は、タスクの詳細計画ではなく、Planning Pokerとストーリーポイントを使用して最初の見積もりフェーズを参照していました。日/時をそこに置いたのは、このような典型的な対話であり、ポイントではなく時間も含まれていたためです。混乱してすみません！ストーリーポイントの例は、時間の例よりも長い期間を表しています。 編集2現在、専用のスクラムマスターはなく、POは見積もり会議に関してその役割を果たします。したがって、中立的なまたは開発者のスクラムマスターではなく、権威として表示されるため、おそらくロールコンフリクトがこの不適切な交渉を悪化させています。おそらく、これが何もない限り、彼を「マスター」ではなく偏った参加者とすることで修正できます。

9 scrum  estimation  planning  sprint 

私は現在、スプリント中（2週間）で、特定のユーザーストーリーの要件とUXを定義することをデザイナーに課しています。 同じスプリントで、私はこのデザインを実装します。スプリントの計画中、私はこの未定義のユーザーストーリーがどのくらいの時間を要するかについて、かなりの推測をしなければなりませんでした。 今日、ようやくデザインを受け取りました。残念ながら、設計は不完全で曖昧であり、設計よりもクライアントの要件に似ています。ただし、このことから、まだ十分に見積もっていないことがわかります。 さらに悪いことに、これは初めてではありません。最後のスプリントでは、まったく同じことが起こりました。私はそれを振り返ってフラグを立てましたが、スクラムマスターは「それはあなたのための単なる開発だ」と言うのではなく、これを解決する方法の答えがありませんでした。皮肉なことに、バーンダウンが目標に達していない場合、彼はイライラします... 今、私は彼の仕事を成し遂げるためにデザイナーに尋ねる/協力する必要があります。私は他のすべてのタスクを完了しているので、これは私を我慢するでしょう。 だから私の質問は A）スプリント計画で依存関係をどのように処理しますか？編集：ユーザーストーリーのデザイン/ UXが実装と同じスプリントで発生しても問題ありませんか B）今はどのようにスプリントにアプローチすべきですか？現在のユーザーストーリーを再推定し、バーンダウンがバーンアップに変わり、無能/非生産的と見なされるのを確認しますか？または、「デザイナーが適切なデザインを作成するのを助ける」という行に沿って、現在のスプリントに新しいタスクを追加します

9 agile  scrum  planning 

私の理解では、デイリースクラムミーティングは非常に迅速で、親しみやすい方法で開催する必要があり、すべてのチームメンバーが出席する必要があります。なぜなら、それは他の誰もが行っていることを誰もが最新の状態にすることであるからです。 そのように開催されるスクラムデイリーミーティングが好きです。 私の最新のプロジェクトでは、デイリースクラムはステータス更新会議のようなものです。立場は私たちがスクラムを保持し、適切なアジャイルを実践しているということですが。 私たちは2つの異なる国に分散したチームであり、同じ国にいる人々は同じオフィスにいません。結果として、仮想スクラムがあります。 問題は、ミーティングが常に時間どおりに開始され、実際の開始時間の前に多くの人が電話をかけるため、実際にはミーティングの最初の1秒から開始されることです。小さな遅延に対する許容度なし。 たとえば、前回電話に出たときに、会議の調整担当者が全員がオンかどうかを確認し、チームメンバーの1人がまだオンではないが、彼が電話していたと言いました。そして、チームメンバーを待たずに共有を開始するように言われました。 また、誰もが多くの会議を行っており、スクラム会議と連続していることもあるため、会議の最初または2分の間に到着したかどうかは理解できます。 デイリースクラムを練習しているチームにとってそれは正常ですか？初めてのことです。 それについて直接書誌を見つけることはできません。すべてのチームメンバーの存在が強調されますが、会議は常に同時に開始する必要があることも強調されます。しかし、私は少しの許容誤差があると想像します。 私は誰かが "5秒"遅れて到着した場合にスクラムマスターがペナルティを課すことができることを示唆している誰かをブログで読みました。私はスクラムは友好的であるはずだと思っていました、そしてそのようなペナルティを持つことは逆効果に思えます。 このような状況で推奨されるアプローチは何ですか？

9 agile  scrum 

最近、私はスクラムについてかなりのことを読んで学び、とても気に入っています。ただし、解決策がわからない可能性のあるシナリオが頭の中にいくつかあります。たとえば、4人のWeb開発者（そのうちの1人はUI / UXデザイナー）のアジャイルチームを編成したいとします。このチームはスクラムの原則に基づいて活動します。 最初は、おそらくアパートを借りたり、Cookieを販売したりするなど、普通の人の中小企業のランディングページのようなプロジェクトに取り組んでいるでしょう。このような顧客は、通常、会社を雇うことを期待しているため、製品所有者ロール（IMHO）を設定できません。 、彼らにプロジェクトの全体的な目標と詳細を提供し、可能な限り関与を少なくして（多くの意思決定を含む）仕事が完了することを期待します（彼らの意見では、彼らにはもっと重要なことがあると考えています）。私は開発者/スクラムマスターの役割に従事したいとします（それは議論の余地があることはわかっていますが、チームメンバーとスクラムマスターになることはわかっています）。したがって、単に製品所有者の役割をするべきではありません。上手。 だから私の質問については：私が私の会社の事業主である場合、私も単に製品所有者になる必要があるだけですか（これらの役割にはお互いが含まれますか）？製品所有者の役割を持つ可能性のある営業担当者を雇うことはできますか？営業担当者ではなく、経験豊富な開発者の方が良いでしょうか？これは賢い動きですか？最後に、私の立場により適した別のアジャイルアプローチはありますか？ 編集：良いインプットをありがとうございました。私はいくつかのコメントを追加しました、任意の追加情報は非常に高く評価されます。

9 agile  scrum 

アジャイルプロジェクト管理（Pivotal Trackerを使用）について理解しようとしていますが、プロジェクトの最初のいくつかのストーリーを定義しようとすると、壁にぶつかってしまいます。たとえば、次の非常に単純な話を見てください。 「ユーザーは製品にタグを付けることができるはずです」 私がすでに「製品」を別の場所で定義していると仮定すると、このストーリーには、多態性タグシステムを内部で記述し、そのシステムIDが完了すると、最終的に製品にタグを付ける機能を追加できるようになります。 私の問題は、このストーリーに隠されている作業量にあります。ストーリーを完成させるためのタスクを定義することはできますが、ストーリー全体は1〜2日間の作業になるはずです。私は氷山の一角を明らかにするだけの話では正しくないと思いますが、それはユーザーに関連する唯一の部分です。 このようなことをどのように克服しますか？ベストプラクティスは何ですか？ 更新25/08皆様のご指導に感謝し、ストーリーを定義する方法について、私はすべてのアドバイスを船内に取り入れました。私は今、ストーリー内のタスク（割り当て、見積もりなど）と、スプリントが始まったら開発タスクの追跡をサポートするJira Grasshopperに切り替えています。

9 scrum 

具体的には、DVCSとビルドシステムを統合するツールに取り組んでいますが、「メタ」ツール（コンパイラ、VCS、ビルドシステム、テストランナーなど）を開発している人が直面する課題をイメージしています「ドッグフーディング」を通じて発展したい。 私の質問は、分岐ワークフローを使用したスクラムスタイルのリリースプロセスで、ツールの開発サイクルで新しいバージョンのツールの使用を開始するのはどの時点ですか？ 私は、以下のバランスを取るプロセスを探しています。 常にdevelopツールのバージョンを使用します。変更が組み込まれると、自分の開発が中断されます。 常にmasterツールのバージョンを使用します。ドッグフーディングによって明らかになった問題は、すでにリリースされている問題です。

9 scrum  tools  workflows  branching  dogfooding