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

私は、スクラムモデルに大まかに沿ってプロジェクトに取り組んでいます。2週間のスプリントを行っています。私が明確にしていない（そして相談する本がない）ことは、スプリント間で起こるはずのことです。製品が構築されて配信される「ラップ」プロセスがあるはずです。 これには通常どれくらい時間がかかりますか？ チーム全体が関与する必要がありますか？ 開発者が次のスプリントアイテムの作業を開始する前に、厳密に終了する必要がありますか？ コードのレビューとテストが行​​われるのはこれですか？ 3人の開発者がいて、合計で約1人のFTEがいます。したがって、スプリントは実際に非常に短いです。

11 agile  scrum  sprint 

典型的なソフトウェア開発環境では、プロジェクトの終了はプロジェクトの終了を示します。 プロジェクトの記録が完成してアーカイブされ、 解放されたリソース、 問題と教訓が文書化されている お祝いのために開催される正式なディナー/パーティー。 最後のステップはオプションですが、参加者にとって非常にやる気になります。:-) これをスクラムと比較してください。スクラムはバックログのストーリーで実行されることを知っています。したがって、技術的には、すべての反復が特定のストーリーを閉じます。したがって、ここには2つの質問があります。 複数の同時プロジェクトに取り組むグループの場合、プロジェクトクロージャはどのように適合しますか？ 複数のグループを含むプロジェクトの場合、この概念はどのように適用されますか？ または、プロジェクト終了期間はT＆Mプロジェクトにはまったく適用されませんか？

11 scrum 

アジャイルの原則の1つは、動作中のソフトウェアを測定することです。 動作するソフトウェアは進歩の主要な尺度です-アジャイルの12の原則 問題は、出来上がったストーリー、つぶれたバグ、欠陥レポートの減少などの観点からソフトウェアを測定できる一方で、ソフトウェアの価値を測定する方法に固執しています。 Mike Cohnを例として使用し、SalesForce.comが支援することで、SalesForce.comが前年に比べて500％高い価値を顧客に提供している場合、その増加をどのように測定すればよいですか？私が今いる場所をどのように測定しますか？ 彼が使用する他のメトリックは、機能の数と開発者ごとの機能の数です。これは私のバックログが順調で、ストーリーが「機能」によって分割されていた場合に解決できるものですが、アジャイルから始めたばかりなので、私たちが今どのような価値を提供しているかを解決する何らかの方法が必要です、たとえば6か月間で同様のメトリックを使用して、出力が増加したかどうかを確認します。 収益の増加、または顧客満足度の向上によってソフトウェアの価値を測定することを聞いたことがあります（しかし、どのようにそれを測定しますか？）私の部門が行っている仕事に直接。 それでは、ソフトウェアの価値をどのように測定し、どのように始めましたか？ * アジャイルで成功する -マイク・コーン

11 agile  scrum 

統合されたテストサポートと独立したQAスタッフを持たないスクラム環境から、テスター（QA担当者）はどのようにスクラムチームと最適に統合されますか？彼らは何をすべきでしょうか？ 参考のために、いくつかのテスト関数は次のとおりです。 単体テスト 統合テスト 機能テスト 性能試験 受け入れ試験

11 testing  scrum 

スクラムマスターの職務に対する私の理解は次のとおりです。 プロセスを実施する 障害を取り除く（開発者が自分で取り除くことができない） 外部からの中断を防ぐ スクラム会議を促進します（スタンドアップ、回顧など） チームの開発者が統制されている場合、彼らは誰かが指導することなくプロセスに従います。また、回顧会議やその他のスクラムミーティングの開催にも問題はありません。組織の他のメンバーがスプリントの境界を理解していれば、スクラムマスターを必要とする外部の中断や障害はすでに最小限に抑えられています。 チームのパフォーマンスが向上し、組織がスプリントの境界を理解するようになると、スクラムマスターの必要性が減少するように見えます。チームが最終的にスクラムマスターが不要になるポイントに到達することは可能ですか？

11 project-management  agile  scrum  team 

プロジェクトにはPivotal Trackerを使用しており、次の3つのポイントスケールから選択できます。 0,1,2,3 0,2,4,8 0,1,3,5,8 そして、私たちの決定を導くのに役立つリソースを探しています。（2回の反復で0,1,2,3を使用した後、他の1つがはるかに有用または意味のある場所を確認できます。）

10 agile  scrum 

私は、毎日のスタンドアップでのスクラムルールは、チームは昨日何をしたか、今日何をしているか、そしてそれらを妨げるものについてのみ話すべきだと言っていることを知っています。他には何もありません。しかし問題は、開発者が1日を自分のタスクに関係のない作業に費やし、それについてスタンドアップで話し合うことです。彼らが昨日やったことです！ 私の経験では、ボード上のタスクについて話し、スタンドアップに焦点を合わせ、全員のタスクに焦点を合わせ続け、見積もりを確認してレコードを毎日追跡する方がより効果的であることがわかりました。 ディスカッションをボード上のタスクに限定することは有効ですか？

10 agile  scrum  meetings 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 約束は約束であり、約束を守る必要があると私たちは皆教えられました。しかし、各スプリントのコミットメントを維持することは現実的ですか？時々人々は病気になり、時には技術的アプローチが間違っていることが証明され、すべてを再考する必要があります。製品の所有者またはユーザーとのさらなる議論の間に、機能は当初考えられていたものとは大きく異なるはずだと理解します。 公式のスクラムガイドは、おそらくこれらの問題に対処するために、コミットメントではなく「予測」という言葉を使用していることを知っています。 したがって、私の質問は、組織内のチームがコミットメントを維持する頻度と、このアプローチが好きか、それとも変更したいかです。 ありがとうございました。

10 scrum 

2つのスクラムチームが同じソフトウェアコンポーネントを使用する場合、そのコンポーネントの明確なアーキテクチャビジョンを提供し、コードベースの進化に合わせてこのビジョンを維持/開発する責任を持つのは誰ですか？スクラムでは、共同でコードを所有することになっているので、チームAが行った開発がチームBが行った開発に干渉しないようにする方法を教えてください。

10 architecture  scrum  code-quality  configuration-management 

基本的にはスクラムに従って、アジャイルなソフトウェア開発を行っています。私たちはスプリントレビューを行おうとしていますが、難しいと感じています。私たちのソフトウェアは多くのデータ処理を行っており、ストーリーはしばしばこれに関するさまざまなルールを変更することについてです。 UIまたは目に見えるワークフローの変更がない場合にスプリントで発生した変更をデモするためのいくつかのオプションは何ですか？その代わり、変更は数十分または数時間かかることもある処理ジョブの微妙なビジネスルールです？

10 agile  scrum  sprint 

私はスクラムのいくつかの側面（2週間のタイムボクシング）を取り上げたチームと作業を始めたばかりです（現在、チームはすべての見積もりまたはスプリントのポイント数に同意していませんが、これを変更します製品の所有者は、ある程度の開発経験を持つ技術リソース（科学者）でもあります。 製品所有者のタスク（主に研究が関係する）をチームのタスク（いくつかは研究といくつかの開発である）と混合するのが適切ですか。

10 scrum 

私は現在スクラムを使用しているチームに所属しており、チームのクロスファンクショナルスキルを向上させ、「2つのヘッドは1つよりも優れている」という哲学で欠陥を減らすのに役立つペアプログラミングを追加することを検討しています。 私たちのチームでは、各チームメンバーは通常、スプリントの計画中にフルワークロードにサインアップします（「フル」は週40時間未満の数であり、会議やコラボレーションなどが可能です）。各タスク。これはスクラムチームではかなり一般的だと思いますが、必ずしも本ではそうではありません。 特に、チームメンバーが作業するための独自のタスクを持っているためにチームメンバーがペアリングをためらうような状況は避けたいと思います。これは、ペアリングのための時間を確保せずにチームが単に自己組織化する場合に発生する可能性が高いと思います。 これを踏まえて、ペアリングの時間を適切に割り当てていることを確認するために、ペアリングシナリオでの労力/時間/ストーリーポイントを説明する最良の方法は何ですか？ 考慮されるいくつかのオプションは次のとおりです。 2人が各タスクにサインアップできるようにし、（おおよそ）推定時間数を2倍にする 「キーボードを操作する」チームメンバーだけが各タスクにサインアップします。これは、その人の推定時間に基づいて推定されます。ペアリングをサポートするチームの誰もが、ペアリングをサポートする時間を確保するために、スプリントのより少ないタスクにサインアップします。

10 scrum  pair-programming 

見積もりが約束ではない場合、製品所有者として、どのくらい時間がかかるかわからないままプロジェクトを提供するにはどうすればよいですか？ 時間の見積もりを約束として扱うと、スクラムチームはより効率的に機能しますか？ ストーリーの調査（準備、問題を理解するための努力）はどれだけ適切な見積もりを出すのに十分ですか？ 作業を見積もった後に発生する予期しない技術的な問題（最初の見積もりを実際に混乱させる可能性がある問題）はどうですか？

10 scrum  project-planning 

休業。この質問には詳細または明確さが必要です。現在、回答を受け付けていません。 この質問を改善してみませんか？詳細を追加し、この投稿を編集して問題を明確にしてください。 6年前休業。 私はプロジェクトに取り組み始めたばかりであり、ドメイン駆動設計（Eric Evansが定義するDomain-Driven Design：Tackling Complexity in the Heart of Software）を使用しています。私たちのプロジェクトは確かにこの設計の候補だと思いますエヴァンスが彼の本でそれを説明するパターン。 私は絶えずリファクタリングするという考えに苦労しています。 私は、どのプロジェクトでもリファクタリングが必要であり、ソフトウェアの変更に伴って必然的に起こることを知っています。ただし、私の経験では、リファクタリングは、ドメイン変更の理解としてではなく、開発チームのニーズが変化したときに発生します（Evansが言うように、「より深い洞察へのリファクタリング」）。私は、ドメインモデルの理解におけるブレークスルーに最も関心があります。小さな変更を加えることは理解していますが、モデルに大きな変更が必要な場合はどうなりますか？ より明確なドメインモデルを取得した後、リファクタリングする必要がある自分（および他の人）を説得する効果的な方法は何ですか？結局のところ、コードの編成またはパフォーマンスを改善するためのリファクタリングは、ユビキタス言語コードの観点から表現力を高めることとはまったく別のものである可能性があります。時々、リファクタリングするのに十分な時間がないように思えます。 幸いにも、SCRUMはそれをリファクタリングに役立てます。SCRUMの反復的な性質により、小さなピースを作成し、それを変更することが容易になります。しかし、時間の経過とともにそのピースは大きくなり、そのピースが大きくなりすぎて変更が困難になるとしたらどうでしょうか。 ドメイン駆動設計を採用するプロジェクトに取り組んだ人はいますか？もしそうなら、これについていくつかの洞察を得ることは素晴らしいでしょう。DDDを正しく理解するのは非常に難しいため、私は特にいくつかの成功事例を聞きたいと思います。 ありがとう！

10 design-patterns  architecture  object-oriented  scrum  domain-driven-design 

バックエンド開発をユーザーストーリーに垂直に分割することを計画しました。しかし、私たちのチームのバックエンドの男は、これにより彼らの仕事が見えなくなると不平を言い始めました。 私の答えは スプリントの計画とレビューのミーティングでは、関係者の前でバックエンドのタスクについて話し合い、それが見えるようにします。 プロジェクト中に高品質を維持すると、他のチームよりも起動のペースが遅くなりますが、プロジェクト中は速度が安定します。そして、速度は利害関係者に非常によく見えます。 「開発者として、ビジネスロジックをカプセル化できるように、ドメインレイヤーを用意する必要があります。」 チームを汚染する前に問題を解決するにはどうすればよいですか？ 問題の根本は、私たちの経営陣が体系的にバックエンドの仕事を目に見えないものと見なし、支援された開発者の鉱夫やその他の軽蔑的な言葉を呼ぶことです。

10 agile  scrum  team  user-story