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

プロダクトオーナー(PO)、3〜9人の開発者の開発チーム(DT)、およびスクラムマスター(SM)がスクラムチーム(ST)として機能し、最高の価値を持つ複雑な製品を構築および維持するためのアジャイルフレームワーク。彼らはスプリントと呼ばれるタイムボックス内でこれを行います。スプリントは短くなる場合がありますが、30日を超えることはありません。イベント、ロール、およびアーティファクトは、公式のスクラムガイド(http://scrumguides.org/scrum-guide.html)で明確に説明されています。

7
スクラムガイドにテスターがいないと書かれているのはなぜですか?
私はscrum.orgのスクラムガイドを読んでおり、次のように書いています。 開発チームには、テストやビジネス分析などの特定のドメイン専用のサブチームは含まれていません。 文字通りの翻訳では、これは混乱を招くテスターがいないことを意味します。彼らはどのようにこれを提案できますか?
14 scrum 

8
スクラムチームでオーバータイムを停止/回避する方法は?
実際、私は彼らのスクラムの実装に関する小さなソフトウェアショップを手伝っています。最近、スクラムマスターから、チームがスコープ(コミットバックログ)を達成するために時間をかけて作業しているため、問題があると報告されました。そのため、Unreal Velocityがあります。 私の正式な質問は/です: レトロスペクティブ会議について話すこととは別に、オーバータイムを避けるためにいくつかのハードブロックを実装するのは良い考えだと思いますか? もしそうなら、どのようなテクニック/ツールを提案しますか? リビジョン管理システム(SVN、GIT、HGなど)、時間単位(8〜5)のブロック ワークステーションは、時間単位(8〜5)または累積時間(最大8時間/日)でブロックしますか? その他... または、多分、この種のものをハードブロックしないでください。しかし、不当な余分な時間に「ペナルティシステム」を実装しますか? 最初:あなたの速い応答のためのすべて。 @Baqueta(および同様の質問を持つ他の人):いいえ、彼らは余分な時間に対して支払われていません。彼らへの私の最初のアドバイスは、おそらく彼らが過小評価していたので、彼らの見積もりをレビューすることでした。これは私のお気に入りのアドバイスでした: 残業に興味がある場合は削除してください。開発は週に60時間行うことができ、生産性を維持できるものではありません。これを証明する多くの研究があります。残業代が問題になる場合は、それを取り除き、基本給を改善して、彼らが価値のあるものを手に入れるようにします。 また、(このチームの)根本的な問題は、次の組み合わせであると思います。 開発者は、スプリントで何を達成しなければならないかを伝えられている/達成可能なことについて相談されていない/作業が多すぎると言われたときに無視されている。 開発者は、タスクにかかる時間/各タスクに含まれる作業単位の数を常に過小評価しています。 要約:チームと話し合い、見積もりを確認します。POについても、あなたが述べたように、範囲について相談されていないように感じます。
14 agile  scrum 

5
ストーリーのスクラム再評価
毎日、スタンドアップの後、チームと私は各ストーリーの見積もりを更新します。私たちのやり方に何か問題があると感じているので、あなたの助けが必要です。 これが俺たちのやり方です: ストーリーAの見積もり:24時間(1日8時間-基準として「理想的な日」を使用) N日:開発者は午前中にストーリーAの作業を開始します(1日の終わりまでに8時間の作業が完了します) N + 1日目:ストーリーAの再推定= 16時間(N日からストーリーAから1営業日を取り除いた) N + 2日目:ストーリーAの再推定= 8時間(N + 1日目からストーリーAから1営業日を取り出した) N + 3日目:ストーリーAはこれまでに完了する必要があります。しかし、そうではありません。開発者は、完了するまでにさらに3時間かかると考えています。ホワイトボードのストーリーを更新し、それに応じてバーンダウンします。 N + 4日目:ストーリーAは、わずか3時間ではなく終日かかりました!これで完了です。5時間という違いは、計画ではまったく考慮されていません。 ストーリーを毎日再評価する方法を教えてください。
14 scrum  estimation 

16
インタビューで流行語アジャイルから本物のアジャイルを取り除く[非公開]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 私は最近、協同組合(有給インターンシップ)のインタビューを行っていますが、インタビューを行っている多くの企業は、スクラムやその他のアジャイル手法を使用していると言っています(スクラムが最も人気があります)。本当のアジャイルショップがあり、アジャイル手法を使用しているが、何か他のことをやっていて、アジャイルを流行語として使用していると言う場所があることを知っています。 私の質問は、これらの店を区別するインタビューで尋ねることができる質問は何ですか? 編集:私はインターンシップを探していますが、これらの質問はすべての人に関係があると感じています。インターンシップの部分はコンテキストです。
14 agile  scrum 

10
スクラムチームの懐疑論者
私の会社は最近、アジャイルな作業方法に切り替えました。その一環として、SCRUMの使用を開始しました。私はこれに非常に満足しており、この方法は従来の方法よりも優れていると感じていますが、チームメイトの一部は同じ意見を共有していません。実際、彼らは「すべてのアジャイルなもの」について非常に懐疑的であり、それを真剣に受け取らないでください。例として、チームメイトの1人は常に会議に遅れており、実際には気にしません。管理IMOはこれに気付かないようにします(おそらく新しいため、人々がそれに慣れるには時間がかかります)。 私の質問は、チーム内で対立を起こさずにこの問題に対処する方法です。
14 team  scrum 


4
スプリント中のスプリントバックログの変更について混乱している
私は最近スクラムについて多くのことを読んでおり、スプリント中にスプリントのバックログを変更しても大丈夫かどうかについて、私にとって矛盾する情報を見つけました。スクラムのWikipediaの記事は、それがOKではない、と様々言う他の記事は、同様にこれを言います。また、私のソフトウェア開発教授は、スクラムの概要の中で同じことを教えました。 ただし、私はトレンチからスクラムとXPを読み、タスクボード上の計画外の項目のセクションについて説明します。そこで、スクラムガイドを調べて、スプリント中に「スプリント目標に影響する変更は行われていない」とスプリント目標の議論で「作業が開発チームの予想と異なることが判明した場合、その後、プロダクトオーナーと協力して、スプリント内のスプリントバックログの範囲を交渉します。」さらに、スプリントバックログの議論でも述べています。 スプリントバックログは、進行中の変更をデイリースクラムで理解できるほど十分に詳細な計画です。開発チームはスプリント全体でスプリントバックログを変更し、スプリント中にスプリントバックログが発生します。この出現は、開発チームが計画を進め、スプリント目標を達成するために必要な作業についてさらに学習するときに発生します。 新しい作業が必要になると、開発チームはそれをスプリントバックログに追加します。作業が実行または完了すると、推定残り作業が更新されます。計画の要素が不要と判断された場合、それらは削除されます。開発チームのみが、スプリント中にスプリントバックログを変更できます。スプリントバックログは、開発チームがスプリント中に達成する予定の作業の非常に目に見える、リアルタイムの画像であり、開発チームのみに属します。 したがって、この時点で私は完全に混乱しています。それについて考えると、2番目のアプローチを取る方が理にかなっています。バックログの個々の特定の項目は、私にとって最も重要なものではなく、むしろスプリントの目標であるように思われるため、スプリントの目標を変更するのではなく、バックログを変更できるのは理にかなっています。たとえば、製品の所有者とチームの両方がストーリーについて同じページにいると思っていたが、スプリントが進むにつれて誤解があることがわかった場合、そのストーリーを構成するタスクをそれに応じて変更することは理にかなっているようです。または、忘れられたストーリーまたはタスクがあり、スプリントの目標を達成するために必要な場合、スプリント中にストーリーまたはタスクをバックログに追加するのが最善だと思います。 しかし、スプリントのバックログへの変更は大丈夫ではないと断固として思われる人がたくさんいます。どういうわけかその位置を誤解していますか?それらの人々はどうにかしてスプリントのバックログを異なって定義していますか?スプリントのバックログについての私の理解は、スプリントのバックログは、ストーリーとそれらが分解されるタスクの両方で構成されるということです。 とにかく、私はこの問題に関する意見を本当に感謝します。私は、理想的なスクラムアプローチがスプリント中にスプリントバックログを変更することと、スクラムを開発にうまく使用する人々がスプリント中にスプリントバックログを変更できるかどうかの両方を把握しようとしています。

8
スクラムチームはYAGNIの原則に従っていません
SCRUMミーティングで、製品チームは、モバイルアプリで使用されるAPIの機能について議論していました。私たちは、画面がどのように見えるべきか、そしてどのキー要素を含むべきか(「レイアウト」)を示すモックアップを用意しました。 これと製品所有者との議論に基づいて、API応答のプロトタイプ(HAL + JSON)を作成しました。それは非常にシンプルで、HALに準拠したJSONであり、モックアップにあるものを表すことしかできませんでした。ビジネスマンは頻繁にアイデアを変更する傾向があるため、私は将来のアイデアに影響されることはなく、ミニマルなアプローチを取ることにしました。私の提案はチームによって却下され、7対1に投票されました。 チームは、レイアウトをより柔軟に配置できる、より複雑で非セマンティックな抽象json構造を使用することにしました。そのアプローチの欠点は、設計上、nullおよび空のプロパティを持つ可能性のある一連の均一なオブジェクトになってしまったことです。彼らはまた、A / Bテストを可能にすると良いと思っていましたが、そのような要件がなかったため、予測に基づいていました。 ほとんどの場合、スプリントの一部ではなく、モックアップで言及されていないことについて議論していました。説明された問題は、「将来のマーケティングがどうなるか...」、「ビジネスが私たちに望むならどうなるか...」でした。 私と製品所有者は経験豊富なプログラマーであり、過去にこの種の問題を見てきました。YAGNIとKISSの原則に従うよう努めています。チームの他のメンバーは少し経験が浅く、これらの原則を知っていますが、理解していないようです。 チーム全体が私たちにとってより重要であり、私たちはそれほど重要ではない何かをめぐって戦いたくなかったので、私たちは彼らの解決策に同意しました。しかし、そのようなことが今後のより複雑な議論の先例になり得るのではないかと心配していますか?そのような行動に対処する方法は?チームリーダーとして、私がもっとうまくできることはありますか? 製品は初期段階のMVPであることに言及する価値があります。

5
定義された役割を持つチームでスクラムを機能させる方法は?
いくつかの背景情報 私は社内のソフトウェア開発チームの一員です。で構成されます 5人の開発者(2〜5年の経験があり、私もその1人です) 3人の実装スタッフ(ソフトウェアの展開とトレーニングを行います) および1人のプロジェクトマネージャー。 多くの小規模から中規模のプロジェクトを開発しており、それらのスケジュールは通常重複しています。開発は次のようになります。 「クライアント」は一連の初期要件を提供します 上記の仕様に合わせてシステムを開発します システムを「クライアント」に提示する 「クライアント」は、上記のプレゼンテーションに基づいて追加の要件を提供します 「クライアント」の新しい要件がなくなるか、展開の対象日が近づくまで2〜4を繰り返します システムをセットアップして展開する これは、ほとんどの場合、期限を処理する「クライアント」であるという事実(これはプログラマーとPM.SEで私が見ているものからの赤旗です)であり、明確な開発方法論に従っていませんカウボーイコーディング、メンテナンス不可能なコード、本番環境を通過するバグなどが含まれます。それが、スクラムのようなアジャイルベースの方法論を採用することを選んだ理由です。 なぜスクラムなのか? それは私たちのマネージャーのイニシアチブであり、現在の状況を考えると誰もがそれに同意するようです。 スクラムの問題 スクラムの一部の要素は、特にアジャイル開発者の「すべての取引」という性質に簡単に対処できない現在のセットアップと競合しています。展開チームはプログラミングの方法を知らず、開発者は平均以下のコミュニケーションとトレーニングのスキルを持っています。そして、このラインナップはすぐに変わることはありません。 質問 方法論としてのスクラムの有効性に影響しますか?補償するために他の変更を行う必要がありますか?それとも、考えを完全に捨てて、別の方法論について考える方が良いでしょうか?

8
一歩先を行くUXデザイナー
UXデザイナーは通常、開発者がSprint X + 1で実装するSprint Xのストーリーを持っています(UXデザイナーと開発者/テスターは1つのチームに所属しています)。これは理にかなっていると思います。スクリーンモックアップと明確な仕様がなければ、スプリントプランニング中に作業を実際に見積もることができないからです。 ただし、スクラムでは、ユーザーに価値を提供するユーザーストーリーのみが想定されています。私たちの場合、UXデザインストーリーはそのような価値を提供しません(バックロググルーミングアクティビティに似ています)。また、通常、スクラムのコーチは、スプリントの開始前に完全な仕様を持つことを推奨しません。 それで、私たちのアプローチには欠点がありますか?うまくいくように思えますが、スクラムの原則にいくらか反しています。

6
スクラムでは、誰が「完了」を検証しますか?
私は組織のQA /テストマネージャーであり、今日までソフトウェアの品質を確認しました(テストの作成と実行、バグの修正)。誰がスクラムでこれを検証しますか?チームがすべての適切なテストを作成して実行したことをどのようにして知ることができますか?一方、私が検証を続けた場合、チームは十分な権限を与えられているとは感じないでしょう。しかし、「完了」が実際に「完了」であるという検証プロセスが必要です。何を指示してるんですか?
13 scrum 

4
アジャイル方法論におけるスタンドアップの目的とその期間は何ですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 私はかつてウォーターフォールの方法論で働いていましたが、今ではアジャイルの方法論に従っているチームにいます。彼らはそれを間違っているようです。たとえば、1日25分以上続くスタンドアップがあり、これは非常に面倒です。さらに、私は他の何よりも自分の給料を経営陣に正当化しているように感じます。 このように感じるのは間違っていますか?これは通常、スタンドアップが行われている方法ですか?

6
アジャイル手法を使用したソフトウェアの書き換え
アジャイル手法を使用してアプリケーション全体を書き直さなければならないとしたら、どうしますか? 現在のシステムの動作に基づいて、多くのユーザーストーリーを作成できると思います。そして、それらを小さな反復で実装します。しかし、これは私たちが前方に要件を持っているという意味ではないでしょうか? また、いつリリースを開始しますか?アジャイルは、早期かつ頻繁にリリースすべきだと言っていますが、完全な書き換えが完了する前にリリースすることはあまり意味がありません。

4
ペアプログラミングの理由
私は、管理者がペアプログラミングのアイデアを私または別のマネージャー/開発者に引き継いだいくつかのショップで働いてきましたが、まったく後れを取ることができません。開発者の観点からは、このコーディングスタイルへの移行が有益である理由を見つけることができません。また、小さなチームのマネージャーとして利益を見ることもありません。 私はそれが基本的な構文エラーに役立ち、何かをハッシュする必要がある場合に役立つことができることを理解していますが、プログラミングループの外にいるマネージャーは、デザイナーよりもFacebookやRedditに行くのを防ぐ方法としてそれを見続けているようです設計ツール。 開発フロアの近くにいる人で、明らかに私のやり方や主題に関するwikiページからはまったく理解できない...高レベルの管理職から、スクラムやアジャイルを扱う際のペアプログラミングの利点は何ですか環境?


弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.