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

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

4
ドキュメントはユーザーストーリーですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 過去数回のスプリントで取り組んできた製品のユーザーマニュアルを作成する必要があります。現在、私たちは次のスプリントで新しいプロジェクトを開始しており、POは以前に作成された製品のドキュメントをこのスプリントのユーザーストーリーにしています。 このアプローチについてのあなたの意見を知りたいだけです。個人的には、ドキュメントはコードを生成しないため、スクラム内のユーザーストーリーであることに同意しません。 編集:ご意見ありがとうございます。私は頭の後ろで、スプリントが作業ソフトウェアの増分を実装することであると思っていましたが、あなたの意見は私の見通しを変えました。答えてくれてありがとう。
13 scrum  user-story 

6
スクラムで「外部」依存関係を処理する方法は?
スプリントで多数のユーザーストーリーを計画しており、1つの候補ストーリーがチームに何かを提供する外部プロバイダーに依存している場合。たとえば、オンラインサービスプロバイダーが新しいAPI呼び出しをシステムに追加したり、システムなどでテストアカウントを有効にしたりします。 あなたはそれが「もうすぐ」来ることを知っています。 あなたは先に行くと、彼らはあなたがあなたの物語を完了するための時間が必要であるものを提供します望んでスプリントに話を追加してくださいまたはあなたはそれが可能な状態になりますし、あなたがしても、すぐに始めることができます知っているとき、あなたは次のスプリントまで待つんできるだけ早く話を始めないことを意味します。 前者が依存関係のために失われた「未学習」のストーリーポイントをどのように処理するか?部分的なクレジット(eek!)またはあごにそれを取る。

9
プロジェクトでどのようにスプリントに名前を付けますか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 一部のスクラムソフトウェア管理ツールには、スプリントに明示的に名前を付けるためのこのオプションがあります。 スプリントに名前を付ける好ましい方法はありますか、それとも1、2、3、...などの単純なスキームを使用しますか?
13 scrum  sprint 

6
SCRUMは、チームメンバーが共有されている環境をどのように管理しますか?
まあ、質問はそれ自身を言いました。私の職場ではそのようなケースが起こりますが、多くのアジャイルの本は同じ職場で働き、仕事のペースを速くするために現在のプロジェクトに集中することを促進しています。 たぶん、私はそのトピックについて知らされていないかもしれませんが、それほど厳密ではないかもしれませんが、そのような場合にアジャイルが提案することを知りたいと思ったのはそのためです。 誰か?

5
スクラムチームメンバーまたはスクラムマスターのいずれかをプロダクトオーナーとして任命するのは良い考えですか?
最近、プロジェクトがあり、クライアントはツアーで忙しかった。通常のスクラムチームが結成されたため、経営陣はクライアントが積極的に参加できないため、アナリストをプロダクトオーナーとして任命することにしました。アナリストは、要件分析と仕様の草案作成のためにクライアントと密接に協力した人でした。 クライアントには、最初の2つのリリースをレビューする時間がありません。クライアントが3番目のリリースを見るまで、すべてが順調に進みました。彼はいくつかの機能に満足していませんでしたが、それらはmake shiftプロダクトオーナー(私たちのアナリスト)によって導入されました。 設計チームがすべてのページのモックアップを完了し、クライアントが各ページをチェックし、作業を継続することを承認するまで待つように言われました。スクラムチームは存在しますが、スプリントはありません。従来のウォーターフォール方式とほぼ同じように作業を終了しました。 スクラムチームメンバーまたはマスターをプロダクトオーナーとして任命するのは良い考えですか?クライアント/製品所有者の参加がない場合、スクラムに従う必要がありますか?
13 agile  scrum  waterfall 

2
複数の開発チームが同じ製品で作業している場合の「完了」の定義
スクラムテストの1つには、複数の開発チームが同じ製品で作業を行うときの「完了」を最もよく説明する定義に関する質問が含まれています。 適切な答えは、それらの開発チームが、結合された作業を潜在的にリリース可能にする「完了」の定義を持っている必要があることを示しています。 このクイズの適切な答えから私には明らかではないものは、次のとおりです。 チームは「完了」の異なる定義を持つことができますか?どれくらい?
12 agile  scrum 

6
タスクに複数の人が関与している場合、スクラムタスクのバーンダウンにアプローチする方法は?
私の会社では、1人のユーザーが1つのタスクを完了することはできません。各タスクをQAおよびコードレビューする担当者が別々になります。これが意味することは、各個人がタスクごとに、完了するまでにかかる時間についての見積もりを提供することです。 問題は、どのようにすれば燃え尽きるのでしょうか?時間を一緒に集計する場合、次の推定を仮定します。 10時間-開発時間 4時間-QA 4時間-コードレビュー。 タスクの見積もり= 18時間 毎日の終わりに、タスクを「完了するまでの残り時間」で更新するようにお願いします。ただし、一般的に各人は自分の部分について考えます。彼らは残りの努力をマークし、それに努力の見積もりを追加する必要がありますか?どうやってこれをやってるの? 更新 いくつかのことを明確にするために、私の組織では、ストーリー内の各タスクに3人が必要です。 タスクを開発する誰か。(単体テストを行う、など...) タスクをレビューするQAスペシャリスト(主に統合テストと回帰テストを行います) コードレビューを行う技術リーダー。 間違った方法や正しい方法があるとは思いませんが、これは私たちの方法です...そしてそれは変わりません。私たちはチームとして働き、可能な限りストーリーの最小レベルでも完成させます。開発が完了するまで何かが機能するかどうかを実際にテストすることはできません。また、コードの品質を確認することもできません。そのため、できることは、最小限の機能をテストしてプロセスのできるだけ早い段階でレビューしました。 このように働く人々への私の質問は、彼らがこのようにセットアップされたときに「タスク」を焼き払う方法です。タスクにそれ自身のサブタスクがない限り(JIRAは許可しません)...毎日「残っているもの」を追跡するための最良の方法がわかりません。
12 agile  scrum 

7
スクラムでは、バックログを機能的なバックログと技術的なバックログに分割する必要がありますか?
スクラムチームでは、バックログを使用します。バックログには主に機能的なトピックが含まれますが、技術的なトピックも含まれる場合があります。バックログが1つあることの利点は、次のスプリントのトピックを選択しやすくなることですが、いくつか質問があります。 まず、私にとっては、開発者自身が純粋な技術項目を追加できる個別の技術的バックログを持つ方が論理的だと思われます。開発者は常に製品所有者を経由してトピックをバックログに追加する必要がありますが、これは製品所有者にとって追加の不必要な作業のようです。 第二に、純粋な機能アイテム、純粋な技術アイテム(技術文書の欠落、浸食されてリファクタリングされるべきコード、デバッグ中に常に問題を引き起こすクラスなど)安定した基盤であり、リファクタリングする必要があります、...)「顧客に直接サービスを提供しない」ため、常にリストの最後になります。個別の技術バックログを持ち、これらの純粋な技術アイテムのすべてのスプリントで時間を確保することにより、アプリケーションを機能的に改善するだけでなく、内部の健全性を保つことができます。 最善のアプローチは何ですか?1つまたは2つのバックログ?

6
スクラム:一度に1つのストーリーに取り組む方法
私は、新しく形成されたスクラムチームのスクラムマスターにノミネートされました。すでにいくつかのスプリントを行っています。最初は、チームが一度に1つのストーリーに取り組むようにしようとしました。しかし、うまくいきませんでした。私のチームは、1つのストーリーで同時に作業できるようにタスクを分散するのが困難でした。たぶん私たちは何か間違ったことをしているのでしょうか? たとえば、新しいダイアログを作成するストーリーがあります。次のタスクを作成します。 モデルクラスを作成する データベースからモデルデータを読み取る モデルクラスをビューに接続する ダイアログ処理を実装する 閉じるときにデータを保存する テスト文書 ソリューションの説明 一度に複数の人がこれらのタスクを実行できますか?タスク-多かれ少なかれ-は互いに構築されます。または、間違った方法でタスクを設計していますか?

3
優れたアーキテクト/マネージャー/主任開発者を作るのは何ですか?
私は小さなソフトウェア会社の主任開発者です。過去2年間で、私のチームは1人の開発者(私)から約9人のグループに成長しました。私たちのほとんどは非常に有能なシニアエンジニアであり(1人あたり20年以上ソフトウェアを構築した経験があります)、ほとんどの場合、手で持つ必要はほとんどありません。スクラムを使用して作業を管理し、通常は最小限の書面要件で多くのことを迅速に完了します。 チームが成長するにつれて、プロジェクト全体の技術的な監視を維持しながら、かなりの量の新しいコードを自分で作成することが困難になったため、自分の役割を調整する時が来ました。ほとんどの時間を開発に費やしていないときに、チームにとって最も役立つものにするにはどうすればよいですか? 私の目標は、開発者を追加することでグループをさらに成長させる(つまり、スクラム速度を上げる)ことです。そのため、単にチームに意思を課す「アーキテクチャポリス」になりたくありません。言い換えれば、私は不必要な官僚主義の層を追加することによって物事を遅くする男ではなく、物事がより良く働く/気分を良くする男になりたいです。それでも、私たちの主なリスクの1つは、すべてを同じページに保持するのに十分な構造を持たずにさらに人を追加すると、物事が制御不能になることです。 私の目標を達成するための最良の方法は何ですか?

5
スクラムメンバーが途中で退去した場合はどうすればよいですか?
スクラムメンバーの1人の健康状態のため、彼はチームを離れなければなりません。 私の質問は、スプリントプランニングセッションを再度開始する必要があるかどうかです。またはバーンダウンチャートを変更しますか?または、すべてのチームメンバーに弾丸を噛んでもらい、目標を達成するために追加の作業を行うよう依頼しますか? ありがとう


5
プロジェクト開始時のアジャイルメソッドとデータベース
アジャイルは初めてで、どのように始めればいいのかわかりません。アイデアは、スプリントでプロジェクトの小さな部分を作成することです。しかし、私が取り組んでいるプロジェクトにはデータベースが必要であり、データベースはプロジェクトで何でもできるようにほぼ機能している必要があります。 それでは、アジャイルプロジェクトはこれをどのように処理しますか、データベースを作成することから始めますか? たとえば、Scrumを使用している場合、ユーザーストーリーをどのように行い、データベースをテストしますか。 コードを必要とするストーリーの中で、dbの一部を実行したいですか。 「ユーザーとして登録する必要があります...」というストーリーがあるとします。このストーリーの一部としてデータベースにユーザーテーブルを作成しますか? アジャイルは、データベースの設計にどのように役立ちますか?

2
スクラムには、防衛契約にメリットがありますか?
昨日、ウォータークーラーで耳にした:「スクラムには防衛契約の場がありません。」 私はスクラムが多くのシナリオで機能するように調整できると信じているという意味で意見が合わない傾向があり、防衛がそれらの1つであることがわかります。これは私の同僚の間でかなりの議論を巻き起こしました(私たちの多くは防衛契約で働いています)。 これを適切な質問にするには:防衛契約の状況でスクラムを使用した人(または使用経験がある人)はいますか?何がうまくいったのか、何がうまくいかなかったのか、バニラスクラムの変更(もしあれば)をしましたか?

6
スクラムと安定した開発は矛盾を作りますか?
私は5チーム、合計約40人の開発者からなる開発グループの一員です。私たちは3週間のスプリントでスクラム方法論に従っています。継続的な統合セットアップ(Jenkins)があり、ビルドパイプラインには数時間かかります(広範な自動テストのため)。基本的に、開発プロセスはうまく機能します。 ただし、新しいスプリントを開始してから数日後、ビルドが不安定になり、スプリント終了の「コミットが停止する」まで揺れたままになることがあります。これの悪影響は、パイプラインのはるか下のビルドステップ、特にUI / Webtestsが数日間実行されないことです(「グリーン」ビルドでのみトリガーされるため)。その結果、新しく導入されたバグは、スプリントの非常に遅い段階でのみ検出されることがよくあります。 各コミットは、テストの基本セットに対して検証されます。確認されると、コードレビュー後に変更がマスターにプッシュされます(Gerrit) 基本的な単体テストは30分ごとに実行され、期間は10分未満です 統合テストは2時間ごと、1時間ごとに実行されます UI / Webtestsは、成功した統合テストで数時間実行されます スプリント中のビルドの安定性の責任者(スプリントごとに責任が渡される)によっては、ビルドを安定させるための中間的なアドホックな「コミット停止」が存在する場合があります。 だから、私たちが欲しい: 開発チームは、スプリント中に変更を開発してコミットします 後続のビルド結果にはほとんど意味がないため、ビルドステップが失敗した場合に放棄するビルドプロセス 開発者にタイムリーに質の高いフィードバックを提供するビルドプロセス (2)を考えると、ポイント(1)と(3)は互いに矛盾しているように見えます。誰もこれに対処する良い方法を持っていますか? (現在、ポイント(2)を緩めており、失敗したビルドステップでもビルドの継続を許可しています。それが品質にどのように影響するかについて、まだフィードバックがありません。) ありがとう、サイモン

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