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

アジャイル手法（SCRUMなど）では、ユーザーストーリーに必要な複雑さ/労力はストーリーポイントで測定されます。ストーリーポイントは、チームが反復で取得できるユーザーストーリーの数を計算するために使用されます。 推定工数のように、具体的な測定値を使用できる抽象的な概念（ストーリーポイント）を導入する利点は何ですか？推定工数を使用して、速度を計算したり、反復のカバレッジを推定したりすることもできます。 対照的に、ストーリーポイントは使用するのが難しく（概念が抽象的であるため）、関係者に説明するのも困難です。どのような利点がありますか？

132 agile  scrum  estimation  user-story 

私たちは1つの製品を持つ小さなソフトウェア会社です。 私たちはscrumを使用し、開発者は各スプリントに含める機能を選択します。残念ながら、過去18か月の間に、チームはスプリントのためにコミットした機能を一度も提供していません。 「ソフトウェアは、完了したらすぐに、すぐに、もうすぐに...完了します。チームにプレッシャーをかけたり、より多くの人を投入したりするのには役立ちません。 ...」スプリントの成功率をどのように改善できるかという質問に対して、開発者の1人から同様のフィードバックを受け取りました。ああ、そうです、私たちは回顧展を使用しています。 私の質問は基本的に： 開発者の質の問題を探すのはいつですか？ 独自の作業/機能を選択しても、各スプリントに失敗する場合は、次のように考え始めています。-独自のコードの複雑さを監督することはできません。-または、コードが非常に複雑であるため、誰もその複雑さを監視できません。 何か不足していますか？

124 scrum  planning 

バックストーリー： 私は過去3年間このチームの一員として働いていましたが、今回は3つの異なるスクラムマスターがいます。 スクラムマスターの変更とショーの運営方法のため、原則が一貫して実施されておらず、スクラムマスターの1人がアジャイルを信じない人だったため、私のチームはスクラムのアイデアに無感覚になりました。開発と企業の決定に従うための初心者としてのイベントとアーティファクトの保持。 私のチームメンバーは、スクラムイベントを行うときにイライラして退屈し、特に一人はこのことについて非常に口頭で話します。 現在： 2か月前、会社はアジャイルとその原則に専念するために、私のチームのスクラムマスターを任命しました。 私は、チームメンバーがスクラムを実行したくないという大気圧の下で非常に苦しんでいます。 前述したように、彼らは全体のプロセスに悩まされており、プランニング、レトロスペクティブ、およびデイリースクラムを効果的にするために必要な会話に参加していないため、私にとって非常に困難です。 彼らにとって、計画は時間の浪費です。なぜなら、私たちはオーバーフローを新しいスプリントに移し、とにかく作業を完了しないからです。 振り返ってみると、彼らは「スクラムをやめる」と言いたいと思うだけです。一人はそうしますが、他の人は黙っており、私は毎回これに対処しなければなりません。 デイリースクラムもまた、彼らにとっては時間の無駄です。彼らは「昨日はタスクXに取り組みましたが、今日もまたタスクXに取り組みます」と述べています。そしてほとんどの場合、彼らは冗談を言って冗談を言った。 これらのイベント中に彼らがどのように時間を過ごしたかということになると、私は非常に大きくなりました。しかし、私はこれに情熱を傾けており、彼らはもう気にしないので、内側で死にかけています。 今日、私に常に反対している人は、「彼らはこのスプリントのためにコミットしたことだと言った」と言うのをやめるように言った。次のスプリントでクォータを埋めます。実際にKanBanを実行します。 なぜ彼がこれを言うのか理解していますが、彼とチームの他の全員が気にしないので、これがそうであることを理解していないようです。障害を処理するのではなく、単に機能します。彼らは障害について文句を言いますが、それらについては何もしません。そして、私が彼らを助けようとするとき、彼らはそれをすくい取るだけです。 かつて彼らは気にかけていましたが、過去2年間で彼らの意欲は多少なりとも底に落ちました。 これらの会議中に冗談を言ったり時間を無駄にしたりすると、会社に多額の費用がかかることを彼らに見せることができますか？

109 agile  scrum  scrum-master 

私はジュニア開発者であり、変更を正当化することができ、チームが作業を完了するのに役立つ場合、チームのプロセスを形作るのに役立つ能力を与えられています。私の過去の企業は、管理から来るプロセスを多かれ少なかれ厳密に定義していたので、これは私にとって新しいものです。 私のチームはかなり小さく、やや新しい（<3歳）です。彼らは欠けています： 明確に定義されたソフトウェア開発/作業管理フレームワーク（スクラムなど） 強力な製品所有権 明確に定義された役割（たとえば、ビジネススタッフが手動テストを行う） 定期的なスタンドアップミーティング 統合された問題追跡プロセス（ツールがあり、プロセスはまだ開発中です） ユニット、システム、リグレッション、または手動テストスイートまたはリスト ビジネスロジックとプロセスに関するドキュメント 社内および顧客向けのヒントを文書化するナレッジベース そしてリストは続きます。経営陣は、価値が正当化され、最も重要な作業（開発）が完了するのを助ける限り、改善の実施に対してオープンです。ただし、基本的な前提は、誰もあなたのためにそれをするつもりはないので、実装の所有権を取る必要があるということです。そして、言うまでもなく、上記のプロジェクトのいくつかは、時間のかかる疑いもなく、重要なものであり、明らかに開発作業ではありません。 時間が経つにつれて上記のことを試してプッシュする（後輩の）開発者の努力の価値はありますか？または、「自分のレーンにとどまり」、開発に集中し、プロセスの定義と最適化の大部分を管理者に任せることが最善でしょうか？

108 project-management  scrum  development-process  process  product-owner 

私は3人の開発者と1人のデザイナーのチームで働くWeb開発者です。アジャイルスクラムソフトウェア開発方法論を実装したのは、約5か月です。しかし、私はこのサイトで共有したかっただけの奇妙な気持ちを持っています。 人間の生活における重要な要素の1つは、意思決定プロセスです。ただし、意思決定には大きな違いがあります。一部の決定は内部または外部の力の結果にすぎませんが、他の決定は完全にあなたの自由意志に基づいており、一部の決定は単なる中間的なものです。意思決定の自由度が高いほど、仕事はより自己主導的になります。これがルールのようです。私たちは自分自身の人生を形作る傾向があるからです。 あなたが何をするかを決めるか、何をするかを言われるかには大きな違いがあります。 スクラムの前に、開発、分析、実装の優先順位付けなどに関連する決定をより自由に行えるようになりました。自分がやっていることを決定しているように感じました。 ただし、スクラム方法論により、多くの決定は製品所有者から単純に下されます。彼はPBIを優先し、ソフトウェアがどのように動作するか、時にはUIと機能をどのように実装するかを分析します。これはスクラム方法論の一部であることを知っています。また、これにより将来的に製品の売り上げが向上する可能性があることも知っています。しかし、私は今、何かをすることを決心するのではなく、常に何かをするように言われているように感じています。この症候群により、私は仕事に対してより受動的になりました。 より良いソリューション、アプローチ、またはテクニックを見つけるために、検索回数を減らす傾向がある 楽しい仕事ができると期待して朝目が覚めない。むしろ、生きるために働くことを余儀なくされるような気がします 仕事の後、自分の趣味のプロジェクトに取り組みたいと思っています より高い技術レベルに到達するためにチームをプッシュすることはもうありません 夕食やお茶の時間に今より多くの時間を費やしているので、仕事に戻る意欲があまりない 私は家に帰ることができるように、仕事をもっと早く終わらせたいと思っています 大きな問題は、同僚でもこの動作を確認して診断することです。それはスクラムの結果ですか？スクラムは、開発チームに、ソフトウェア全体の形成に関与していないように感じさせ、プロジェクトを受動的にさせますか？どうすればこの気持ちを克服できますか？

103 agile  self-improvement  scrum 

私のマネージャーは最近、生産性の目標と尺度として速度を使用することを本当に推し進めています。現在、平均速度50ストーリーポイントで作業しています。私のマネージャーは、ストーリーポイントを40％増やして70ストーリーポイントにすることを望んでいます（チームメンバーの増加はありません）。この増加が達成されない場合、彼はその理由を説明する完全な内訳を提供することを望んでいます。 チームのパフォーマンスを速度で測定し、それをターゲットとして使用するという考え全体は間違っているように思えますが、その理由を説明するのは難しいと感じています。助けがありますか？なぜ生産性を測定し、インセンティブを与えるのにこれが適切な方法ではないのですか？

89 agile  scrum 

多くのスクラムの本や記事では、スプリントの失敗（チームがスプリントバックログの一部の機能を完了できなかった場合）はそれほど悪いことではなく、時々発生します。そして、次のスプリントで何かを改善します。そして、チームは彼らがコミットした仕事を完了しないことで罰せられるべきではありません。 これは開発者の観点からは素晴らしいように見えますが、深刻なクライアント向けに何かを開発しているソフトウェア会社「Scrum-Addicts LLC」（「Money-Bags Corporation」）があるとします。 Scrum-Addictsマネージャーは、Money-Bags用のソフトウェアを作成することを提案しています 彼らは機能のリストに同意し、Money-Bagsは出荷日を提供するように頼みます スクラム中毒マネージャーはスクラムチームに相談し、チームはすべての機能を完了するには3週間のスプリントが必要だと言っています Scrum-Addictsマネージャーは、安全のために1週間を追加し、1か月でソフトウェアを出荷することを約束し、Money-Bagsと契約を結びます 4回のスプリント（出荷期限）後、スクラムチームは機能の80％しか提供できません（新しいシステムでの経験不足、本番環境の以前の機能の重大なバグを修正する必要性など）。 スクラムが示唆しているように、この時点で、製品は潜在的に出荷可能ですが、Money-Bagsは契約で述べられているように機能の100％を必要とします。だから彼らは契約を破って何も支払わない。 スクラム中毒者は、マネーバッグからお金をもらえず、投資家は結果に失望し、それ以上会社を助けたがらないため、破産寸前です。 明らかに、スクラム中毒者の立場になりたいソフトウェア会社はありません。アジャイルとスクラムについて私が理解できないのは、チームが上記の状況を回避するために計画と期限に対処することを提案する方法です。要約すると、2つの質問があります。 誰が悪いのか？ 適切な計画を立てることが彼らの仕事だからです チーム。彼らができる以上の仕事をすることにコミットしたから 他の誰か 何を終わらせるべきなのですか？ マネージャは、期限を元のチームの推定値の2倍（または3倍）遅らせる必要があります。 チームメンバーは、何をしてもコミットしたすべての作業を行うように奨励する必要があります（失敗したスプリントに対してペナルティーを発行することにより） 会社の締め切りポリシーに適合しないため、チームはスクラムを削除する必要があります 私たちは皆、ソフトウェア開発をやめて修道院に参加すべきです ???

80 agile  scrum  sprint 

この質問はしばらく私の頭の中で調理されてきたので、開発環境でアジャイル/スクラムのプラクティスに従っている人に尋ねたいと思いました。 私の会社はついにアジャイルプラクティスを取り入れることに挑戦し、トライアルベースでアジャイルグループの4人の開発者のチームから始めました。3回の反復で4か月が経過しましたが、他の人にとっては完全にアジャイルになることなく、それを続けています。これは、経営者がビジネス要件を満たすための信頼が、上記の非常に多くのアドホックタイプの要求であるという事実によるものです。 最近、私はこのイニシアチブの一部である開発者と話をしました。面白くないと言われます。彼らは彼らのスクラムマスターによって他の開発者と話すことを許可されておらず、作業エリアで電話を取ることも許可されていません（ある程度は問題ないかもしれません）。たとえば、アジャイルチームに所属するキックについて友人と話したい場合、スクラムマスターの承認なしでは許可されません。アジャイルチームのすぐ隣に座っています。 このすべてまたはアジャイルのアイデアは、アジャイル開発者に中断が生じないように完全な真空を提供し、6時間以上の生産時間を確保することです。まあ、私はアジャイルの第一人者ではありませんが、ヤフーのアジャイルロールアウトドキュメントや他の組織の同様の記事を読んだことから、アジャイルは安くないという印象を与えます。チームにアジャイルを浸透させ、到着した問題を修正して軌道に戻すには、リソースと予算が必要です。 まず、開発者向けのトレーニングとマネージャーなどのコーチングが必要です。現在のスクラムマスターは、管理者が支払うアジャイルトレーニングクラスを数日間受けたマネージャーで、現在このアジャイルチームを率いています。また、アジャイルマニフェストはアジャイルが石に設定されておらず、会社ごとにカスタマイズされていることを指示しないと会議で聞いたことがあります。まあ、それはすべて良いと理にかなっています。 結論として、私はアジャイルが開発チームに調和をもたらすはずだと常に思っていました。ただし、アジャイルチームの開発者と話をするとき、私は非常に反対の気持ちになります。彼らは仕事以外は何も話せないのに不満であり、一日中静かに座って仕事をしているだけであり、経営者が仕事をより良くするための別の方法だと感じています。 これがより多くのドルのために利己的な優位性の目的のために使用される良い習慣の例であるならば、私に教えてください？あるいは、私のような開発者だけがこのアジャイルチームであり、仕事をしているために仕事をするだけの環境で働くのは好きではないと感じています。 これは、全米にオフィスを持つヘルスケア分野の会社です。それは間違いなくカウボーイスタイルのアジャイルのように感じられるので、現在の会社では特に、アジャイルをまったく望んでいません。 それはすべて、管理が完全に安価であることと関係しています。安価なバージョンのために高価なコーヒーを切り取り、可能な限り無駄を省きながら、節約と生産性を重視します。 私は、ドアの後ろの経営陣がこのアイデアを捨て、アジャイルにより生産性が向上し、同じ人員でより多く生産している上司に見せることができると感じています。または、もしそうであれば、人員を減らすことができます。 彼らは毎日5分間の会議を開いています。ただし、チーム外の人とチャットや会話をすることはできません。すべての焦点は仕事にあります。

80 agile  scrum  methodology 

ここまで読んで研究してきたすべてのことは、アジャイル/スクラムが約4〜6人、さらにそれ以上のチームでどのようにうまく機能するかを説明しています。 私の現在のショップには、約8人の開発者がいますが、プロジェクトの量とサポートする部門の数を考えると、特定のプロジェクトに1人または2人以上の人が割り当てられることはありません。 1人または2人の開発者のチームでアジャイル/スクラムを使用できますか？私はこの方法論で作業を開始するためにマネージャーにピッチを作成しようとしていますが、小さな開発者クルーのために物事を縮小する方法を説明するか、特定のメンバーを増やすように説得する必要があります事業。

63 scrum  methodology  agile 

顧客満足の狩野モデルは、製品機能のさまざまなクラスを定義します。それらの中には 必須の品質：これらが実装されていない場合、顧客は製品を受け入れません。 魅力的な品質（喜び）：顧客が最初に期待することさえないが、発見されたときに興奮と喜びをもたらす機能。 魅力的な資質は明らかに多くのビジネス価値を持っています。5.000未満の使用済みフィアットがすべての必須要件を満たす場合、人々は500.000でフェラーリを購入します。 ただし、私が知っているすべてのアジャイルプロセスは、必須の要件を強く支持しています。これらは常に最高の優先度を取得します。アジャイルには魅力的な資質がある場所すらありません。 アジャイルプロセスはソフトウェア開発に非常に役立つと思います。しかし、どうすればそれらを適用して、必須の要件をかろうじて満たす最低限のものだけでなく、楽しい高品質のソフトウェア製品を作成できますか？ 補遺：最初の2つの答えが指摘したように、必須要件に最高の優先順位を与えることは理にかなっています。しかし、私たち（および顧客）は、必要な要件が何であるかを事前に常に知っていますか 私は、最初に高い優先度が与えられた要件が、後で役に立たないとしても、それほど重要ではないことが判明したことを何度か経験しました。したがって、私は、必要な要件に慎重に焦点を合わせるべきではないと考えています。

61 agile  project-management  scrum  requirements 

私たちは3人の開発者、1人のデザイナー、スクラムマスター、およびプロダクトオーナーのスクラムチームです。ただし、チームには公式のテスターはいません。私たちに常にある問題は、アプリケーションをテストし、それらのテストに合格してバグを削除することが、PBI（製品バックログアイテム）が完了したと見なす基準の1つとして定義されていることです。 しかし問題は、アプリケーション（実装された3人の開発者と1人の設計者）がどれだけアプリケーションをテストしようとしても、いくつかのバグが見られず、利害関係者へのプレゼンテーション（マーフィーの法則）を台無しにすることです。 改善策として、新しいテスターを雇うことをお勧めします。仕事をしている人はテストであり、テストのみです。公式のプロテスター。 ただし、問題は、スクラムマスターと利害関係者が開発者（または設計者）もテスターである必要があると考えていることです。 彼らは正しいですか？開発者（デザイナーも）もテスターに​​すべきですか？

60 testing  scrum 

私が働いているところでは、3週間の反復でスクラム駆動のアジャイルを実践しています。はい、繰り返しが短くなればいいのですが、それを変更することは現時点では選択肢ではありません。 繰り返しの終わりに、私は通常、最終日が非常にゆっくりと進むことに気付きます。実際の作業はすでに完了し、受け入れられています。いくつかの会議（回顧と次の反復計画）がありますが、それ以外はあまり進行していません。 チームが最終日まで勢いを維持するためにどのようなテクニックを使用できますか？欠陥に対処する必要がありますか？とにかく次のイテレーションの作業を早期に開始しますか？他に何か？

56 agile  development-process  scrum 

あなたの経験（逸話的またはその他）で、アジャイルを非アジャイル組織または会社に導入するための効果的な方法は何ですか？ 更新：アジャイルを導入しようとしたが「撃ち落とされた」ケースについてだれでも話せますか？また、なぜあなたが「撃down」されたのかを振り返って理解していますか？

55 agile  scrum  methodology  culture 

スクラムを使用した滝からアジャイルへの移行のほぼ中間です。テクノロジー/規律サイロの大規模なチームから、部門を超えた小規模なチームに変更しました。 予想どおり、アジャイルへの変更はすべての人に適しているわけではありません。アジャイルに慣れるのに苦労している開発者は少数です。私は本当に彼らを引き付け、挑戦し続け、最終的には毎日仕事に来ることを楽しみたいです。これらは賢く、幸せで、やる気のある人であり、私は個人的レベルと職業的レベルの両方で尊敬しています。 基本的な問題は次のとおりです。一部の開発者は、主に難しい作業をし、設計を熟考し、潜在的な問題を熟考し、次に他の人との最小限の相互作用のみで問題を部分的に解決する喜びに動機付けられます期間。彼らは通常、高品質のタイムリーな方法で作業を完了します。それらの作業は保守可能であり、アーキテクチャ全体に適合しています。作業に対する相互作用と共有責任を重視する職域を超えたチームに移行し、短い間隔で作業機能を提供することで、チーム全体がその困難な問題を克服するように進化します。多くの人がこれを前向きな変化だと感じています。最初から最後まで問題を抱えて独立してそれを所有するのが好きな人は、そのような仕事の機会を失います。 これは、人々が変化に対して開かれているという問題ではありません。確かに、変化を嫌う少数の人々を見てきましたが、私が懸念しているケースでは、個人は良いパフォーマンスをし、真に変化に対してオープンであり、努力をし、チームの残りの部分がどうであるかを確認します変化し、彼らはそれに適合したいと思う。それは誰かが困難であるか妨害者であるか、または最もジューシーな仕事を買いだめしたいというケースではない。彼らは以前のように仕事に喜びを見いだせません。 これにぶつからない唯一の場所になることはできないと思います。他の人はこれにどのようにアプローチしましたか？あなたが個人的に大きな仕事の塊を端から端まで所有することによって動機付けられている開発者であり、あなたが別の働き方に適応した場合、それはあなたのために何をしましたか？

52 agile  scrum 

私は、大きなバックエンドコンポーネントを備えたAndroidおよびiOS用の新しいモバイルアプリに取り組んでいる開発者です。私たちはこのプロジェクトの3つのスプリントに参加しており、スクラムをそのすべてのセレモニー（洗練、計画、デイリー、回顧など）で使用しています。 2つのスプリントでは、チームは残業と週末に（無給で）働かなければなりませんでした。誰もが一生懸命働きましたが、外部の依存関係と楽観的な見積もりにより、すべてのスプリントストーリーを達成するのに苦労しました。 私の経験では、一部のスプリント中にストーリーの一部が完了しないことはある程度普通であり、次のストーリーで取り組むことができます。しかし、プロジェクトマネージャーは、自分で見積もりを行ったのは私たちのせいだと言っているので、スプリントのすべての項目を完了する必要があります。 これは、私が知らないスクラムの許容可能な/一般的なバリエーションですか？ これに基づいて行動することをどのように提案しますか？

52 agile  project-management  scrum  development-process