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

コードは、古典的なASP / ASP.NETの組み合わせの完全な混乱です。スクラムは、大きな混乱を修正するか、それを追加することで構成されます。書き直しを始めるのに忙しいので、不思議に思っています。 スクラムのどこに、開発者が十分に十分であると言うことができ、大きな書き直しを開始する時間を与えることを要求することができる部分がありますか？古いコードに「Stories」をパッチするだけの無限ループのようです。 そのため、コードベースがどれだけ悪くなったのか理解していないため、書き直そうとは思わない非技術的な人々によって物事が実行されています。 では、誰がこの大きな書き換えの変更を担当しているのでしょうか？開発者ですか？スクラムマスター？ 現在の戦略は、時間を見つけて、より高いレベルの人が関与することなく自分でそれを行うことです。なぜなら、彼らは主に現在の混乱に責任がある<-からです->。

23 scrum  maintenance 

私はアジャイルチームの開発者であり、スクラムを使用しようとしています。 そこで、状況を説明するために仮想問題をここに入れます。 面倒で保守性の悪いJQueryコードを使用した非常に古いアプリがあります。また、Reactを使用したアプリの一部もあり、それらの部分は更新/保守がはるかに簡単です。それに加えて、会社の目標は、Reactでクライアントシングルページアプリを作成することです。そのため、JQueryを使用すると、さらに離れることができます。 計画を立てるときは、常に開発時間の観点から簡単な解決策を探します。たとえば、新しいダイアログなどを作成する場合は、以前のJQueryを使用します。後で整理してReactに変換しますが、それはめったに起こりません。 ユーザーストーリーから、必要なことの要件を取得します（IMOはよくできていますが、スリムですが、何をしているのか、なぜそれをしているのかを説明しています）。 新しい機能の要件は非常にスリムな場合があるため、たとえば、要件が「大量のコンテンツをロードするダイアログを作成する」と言っているが、ロード機能を実装するように言っていない場合、ほとんどの場合、実装しません、それは私たちがスプリントの目標を妥協する可能性があるという理由で、私たち全員がそれが顧客にとってより良いことを知っているにもかかわらずです（私は個人的にはそうはしないと信じていますが）。 その結果、私たちのコードベースは非常に保守性の悪い大きな混乱であり、新しい機能は非常に小さく、フルスプリントを費やすことがあります（良いコードベースで1日で達成できるもの）主にこの開発のため戦略、ただ速く行き、最小限のことをしてください。 この場合、何が間違っていますか？先週書いたばかりの悪いコードを書いたりコードを書き直したりしないように、より完全な方法で解決策に取り組むべきでしょうか？それとも、すべてのコードが書き直されていることを確認するだけでそれを続けるべきでしょうか？この問題に対するアジャイルなアプローチは何でしょうか？

22 agile  scrum 

すべてまたはほとんどのコーディングがスプリントの終了まで行われない場合、テストはコーディングと同じスプリント内でどのように処理されますか？（スプリント内の単一のPBIの「スープからナッツ」への開発とテストに言及しています。） 私がオンラインで見た回答のほとんどはQAの自動化に関係していますが、自動化されたテストを記録または作成するための機能的なUIが一般的に必要なので、それも実際には不可能です。機能を開発し、新しい要件を発見するにつれて進化し続けるストーリーボードしかありません。 私の場合、新しいデスクトップアプリケーションを開発しています。通常、デスクトップアプリは自動テストにあまり適していません。自動化された単体テストがいくつかありますが、QAの専門家が行う手動の機能/統合テストではありません。 ですから、私が今いるのは、私のスプリントが明日で終了するということです、私はまだコーディングを終える必要があります、そして私のQAの人々はまだテストするものが何もありません、そして私が手を持たずに私が彼らに与えるものをテストする方法がわかりません。 私はこのジレンマを持っている最初の人ではないと確信しています。 過去に、パイプラインを実行しました。現在のスプリントでは、テストチームが前のスプリントで実装された機能をテストします。私の現在の仕事では、PMはこのアプローチを「ウォーターフォール」と呼んでいます。

22 agile  testing  unit-testing  scrum  qa 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 6年前に移行 。 私はこの課題に何度か出くわしました。製品バックログアイテムとTFSのタスクの違いを説明する方法について、誰かが参照、トレーニング、またはアドバイスを提供できることを望んでいます。 製品バックログ項目は「何」であり、タスクは「方法」であると理解し、説明しました。また、PBIが要件であり、タスクが要件を満たす方法であることも説明しました。 私がこれを説明するとき、私は繰り返し空白の視線と頭の傷に会います。これを説明するソフトウェアエンジニアは区別できないようです。それらはすべて同じです。 私のもう一つの課題は、区別することが重要である理由を効果的に説明できないことだと思います。

22 team-foundation-server  scrum  agile 

ユーザーストーリーがアジャイルの世界を支配していることは理解していますが、これらのアーティファクトはどのように保存されるので、チームに参加する新しい開発者が要件に追いつくことができますか？ ユーザーストーリーが後で変更された場合、どのように更新され、アーティファクトとして保持されますか？多くのチームが、元のストーリーを追跡するのではなく、新しいチケット/機能のリクエスト/バグレポートを開くだけを見てきました。

22 agile  scrum  user-story 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 チームメンバーが最初に彼にではなく、スクラムマスターに割り当てられている責任をとろうとする状況で、あなたは何をしますか？

22 scrum  collaboration  meetings 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 私は一般的に、バックエンドおよびフロントエンドの開発があるストーリーを見ます。たとえば、いくつかのテーブルといくつかの動的コントロールを備えた大きなダイアログを考えてみましょう。複数のストーリーを作成します（各テーブルに1つずつ、動的制御システムに1つずつ）。 その後、開発チームはバックエンドで1人、フロントエンドで1人に分割されます。これにより、バックエンドの人はSQLレイヤーの構造を心配するだけで済み、フロントエンドの人はレイアウトなどに集中できます。バックエンドとフロントエンドの間の最初のインターフェースが合意された後、2人の開発者はスプリントの終わりまでに自分の部分を成し遂げるために注意を集中できます。 それからカオスが来る。誰がどの物語を「所有」していますか？「進行中」とはどういう意味ですか？バックエンドとフロントエンドの2つの別々のストーリーを作成する必要がありますか？もしそうなら、それは機能に基づいたユーザーストーリーのアイデアを壊しませんか？私たちのシステムには「サブタスク」という概念があり、これらの問題のいくつかを緩和します。ただし、サブタスクはさらに複雑になります。もっと良い方法はありますか？これはスクラムを使用する「悪い」方法ですか？ 過去数年間、いくつかの場所で何らかの形のアジャイルを使用しています。公式のトレーニングはまだありませんので、間違った用語やイデオロギーはご容赦ください。プロセスを改善する実用的な方法を学ぼうとしています。

21 agile  scrum 

この投稿を改善したいですか？引用や回答が正しい理由の説明など、この質問に対する詳細な回答を提供します。十分な詳細のない回答は、編集または削除できます。 私は最近、より正確にアジャイル、スクラムを行ういくつかの企業にインタビューしましたが、私にはアジャイルとは思えないものがいくつかあります。私が特に興味を持っているのは、スクラムスプリントのケースです。 私が話した特定のプロジェクトマネージャー（はい、私はプロジェクトマネージャーと言いました）は、彼女のチームの人々が、勤務時間を過ぎても家に帰らないことを理解していることを誇らしげに述べました、仕事がどれだけかかっても家に帰ります。行間で読んだことは、できる限り多くの機能をスプリントにまとめ、それを実現するために残業することです。 今、私は今までにアジャイルをやっていません（ほとんどの場合、ウォーターフォールを好む金融機関や政府機関と協力しました）が、私の理解は次のとおりです： スクラムのスプリントは、アジャイルの一般的な反復の名前です。 チームは持続可能なペースで作業し、長期的な残業を避けるように努める必要があります。これは、短時間にしか影響を与えず、その影響は長期間に発生する問題によってd小化されるためです。 私の声明は正しいですか？そして、マネージャーのプレゼンテーションを危険信号とみなすべきですか？

21 agile  scrum  development-methodologies 

プロジェクトに最近参加したプロのスクラムマスターコンサルタント[*]がいます。残念ながら、私たちは彼女の名前を知りません（彼女は私たちに自己紹介したことはありません、彼女は1日で来て、「私たちは毎日立ち上がっている」と言いました）、そして彼女は椅子a毎日のスタンドアップミーティング-私は冗談で彼女にミーティングで毎日フィードバックをするように頼んだとき、彼女は非常にf辱され、「参加せずに促進する」ことがスクラムマスターの仕事だと言った。 これはかなり反アジャイルのようです（他のアジャイルプロジェクトに取り組んでおり、チームは自己指示されていました）。これは平等主義であるはずですが、スクラム方法論でどのように機能するかはわかりません。私は彼女が一日中あまり役に立たないと思います、そしてそれがこの問題に対する彼女の防御の理由です。 スクラムマスターは、スタンドアップミーティング中に「昨日、今日、障害」という演説に参加しますか、それとも、会議の議長を務める（「促進する」）役割がありますか？ [*]彼女は自分の仕事が何であるかを実際に知らされていませんでした。

21 agile  scrum  methodology  meetings 

多数のアジャイルスクラムチームを持つ組織には、「エンタープライズアーキテクト」として任命された少数の人々のグループもいます。EAグループは、品質と意思決定の遵守のためのコントロールおよびゲートキーパーとして機能します。これにより、チームの決定とEAの決定が重複します。 たとえば、チームはライブラリXを使用するか、SOAPの代わりにRESTを使用する場合がありますが、EAはそれを承認しません。 現在、これはチームの決定が却下された場合にフラストレーションにつながる可能性があります。十分に考えれば、EAの人々がすべての力を「つかむ」可能性があり、チームはやる気がなく、あまり機敏ではないという感じになります。 スクラムガイドこれはそれについて言いたいことがあります。 自己組織化：開発チームに、製品バックログをリリース可能な機能の増分に変換する方法を教えてくれる人はいません（スクラムマスターでさえも）。 それは合理的ですか？EAチームは解散すべきですか？チームは拒否するべきですか、それとも単に従うべきですか？

20 agile  scrum  teamwork  architect 

会社が現在のプロセスをSCRUMに置き換えることを決定したときに発生した単一障害点は何ですか？ 会社がSCRUMを導入しようとしたときに本当にうまくいかなかったものの例をいくつか教えていただけますか？あなたの逸話、あなた自身が経験した何か、あなたが来るのを見たが防ぐことができなかった大きな失敗を聞きたいです。 実装の詳細、およびストーリーのサイズとストーリーの詳細レベルに関する決定に関するドキュメントがないことについて、多くの懸念を聞いています。

20 scrum  failure 

スクラムがソフトウェアの世界で広く採用されてから何年も経ちました。多かれ少なかれ独立した人々/研究所によって行われた効率性調査があるのだろうかと思います。明らかに、世界中を旅して講義やトレーニングを行うスクラムの達人は、多くの優れたショーケースを見つけますが、スクラムを販売していない人の話を聞きたいです。 効率とは、総生産性（提供される価値/コスト）を意味しますが、チーム内のコミュニケーションなどの内部特性は意味しません。 コメントの議論に基づいて更新： このような調査/分析を行う方法の1つは、スクラムありとスクラムなしで開発された同様のプロジェクトの比較に基づいている可能性があります。10年前にも、現在のプロジェクトに似たプロジェクトがあったと思います。もちろん、適用される技術が完全に異なる場合は意味がないため、これらのプロジェクトは同じ/類似の技術で実装する必要があります。

20 scrum 

アジャイルチームでは、現在のスプリントで行われている作業だけでなく、システム全体に影響する高レベルのアーキテクチャと設計の決定を担当するのは誰ですか？ プロダクトオーナー、スクラムマスター、スクラムチーム、または他の誰かでしょうか？

19 agile  scrum 

私が取り組んできたより伝統的なプロジェクトでは、プロジェクトマネージャー（および、大規模なプロジェクトでは、1人の担当者が利用できない場合、アソシエイト/代理/アシスタントのプロジェクトマネージャーが存在する可能性があります）は、プロジェクトと顧客とのコミュニケーションの責任者ですヘルスとステータスの更新、スケジューリングと予算の決定、プロセスの管理、チームがタスクを完了するために必要なものを確保するなど。 ただし、スクラムでは、これらの責任はプロダクトオーナーとスクラムマスターの間で分割されます。製品所有者は顧客の声です。顧客と直接やり取りし、ユーザーストーリーを作成し、製品バックログやその他のユーザー/顧客が直面する問題を整理して優先順位を付けます。ScrumMasterはプロセスを処理し、会議（推定と計画を含む）を監督し、障害を取り除き、プロジェクトの全体的な健全性を監視し、必要に応じて調整します。 Wikipediaを含む複数の情報源で、ScrumMasterとプロダクトオーナーの役割は2人の異なる人物が担うべきだと読みました。私は読んだだけでなく、両方のアクティビティが1人の個人によって処理される、成功した「伝統的な」スタイルのプロジェクトに取り組みました。実際、1人から3人の人々がプロジェクト（人事/人員を含む）とプロセスレベルのタスクを処理する責任があることは、彼らがしばしば手をつないで行くので、より理にかなっています。プロセスの変更は、スケジューリング、予算編成、品質、およびその他のプロジェクトレベルの目標に影響を与え、プロジェクトの変更はプロセスに影響を与えます。 スクラムがこれらのアクティビティを2つの役割に分離する必要があるのはなぜですか？これは実際にどのような利点を提供しますか？プロダクトオーナーとスクラムマスターが同じ個人であるスクラムプロジェクトで成功した人はいますか？

19 project-management  scrum  team  roles 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 当社では、3つの異なるプロジェクトに同時に取り組んでいるチームがあります。通常、各プロジェクトに関係するのは1人か2人だけです。プロジェクトの作業には、多くの場合、新技術の習得やバグの解決が含まれますが、どちらも推定が非常に難しいタスクにつながります。この状況では、管理者は引き続きSCRUMの使用を主張し、予期しない状況のためにスプリントの最後に安全バッファーを割り当てることはできません。スタンドアップミーティングはチーム全体で行われますが、ほとんどの人は無関係のソフトウェアコンポーネントや異なるソフトウェアプロジェクトを一緒に作業します。 単一の開発者とファジータスクを含むプロジェクトでSCRUMがうまく機能しているのを誰かが見たのではないかと思いますが、プロセスをどのようにうまく機能させましたか？ 新しいテクノロジーの研究/マスタリングに関連するタスクを推定する方法（これには、新しいプログラミング言語、プラットフォーム、および開発ツールの学習が含まれます） 特定のプロジェクトにSCRUMを使用しないように経営陣を説得することに成功した人はいますか？ ありがとう！

19 scrum