問題タブ [scrum]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
agile - 要件、仕様、およびアジャイル環境での管理
私の会社は、スクラムの方法論を採用しようとしましたが、成功はまちまちでした。論文は、私たちが問題を抱えているいくつかの分野です。これらをどのように処理しますか?
- 製品マーケティングから製品までの要件の追跡。すべての要件を個別に追跡するために JIRA を試しており、実装のために選択されたときにそれぞれにリリースを割り当てています。
- ストーリーを作成するのは誰ですか? 効果的な小さなストーリーを作成するのに十分な知識がない製品管理者、ドメインの知識を持たない可能性のある開発者、その中間のアナリスト?
- 機能仕様
- それらを書きますか、それとも単にストーリーの定義に取り入れようとしますか?
- ストーリーごとに機能仕様を書いていますか? 機能ごと?
- 機能仕様とストーリーの関係をどう捉えていますか?
- 役職に VP が付いている人からの質問に答える: 「[今から 8 か月後] までに何が得られるでしょうか?」
scrum - スクラム - 機能/営業チームからより良いインプットを得る方法
私たちは、機能的に複雑な製品を開発している 3 人の開発者 (2 人は経験豊富ですが、この特定のビジネス セクターでは新しい) の小さなチームです。私たちはスクラムを使用しており、各スプリントの終わりにデモを行います。機能チームが多くのアイデアを持っていることは明らかですが、これらは開発チームに十分に伝えられておらず、デモは答えよりも多くの質問を提起しています.
機能的な人々からの入力の質を改善するための推奨事項はありますか?
詳細情報:問題の一部は、仕様やユーザー ストーリー自体がないことだと思います。個人的には、彼らはある種の要件を書き留める必要があると思います。どのようなものを書き留めるべきで、アジャイル プロセスを考えるとどのくらい複雑になるのでしょうか?
agile - スクラム: 抵抗は無益である (ではない)
私は 2 番目の開発者で、PHP/MySQL ショップで最近採用されました。私が雇われたのは、混沌とした混乱からある種のプロセスを論争した経験が主な理由です。少なくとも、前の会社ではそうでした。;)
私がここに来てから (ここ数か月)、上司、プロダクト マネージャー、その他数人の主要人物 (ただし、スクラム ベースの固定観念をお許しいただければ、ほとんどがニワトリです) を迎え入れました。また、1 年以上遅れている主要製品の開発サイクルを可視化するのにも役立ちました。人々はそれを愛しています!
しかし、私の同僚 (今ここにいる唯一の他の開発者) はそれに興味がありません。彼女はドアを閉めて仕事に集中し、一人にされることを好みます。自分?私は、コラボレーション、協力、オープン性のアジャイル アプローチ全体に興味があります。彼女の意見がなければ、私はスクラムの実践を始めました (毎日のスクラム、バーンダウン チャート、および私と私の以前のチーム (H. Kniberg のクールなウォール チャート) でうまくいったことがわかったその他のもの)。私たちは実際に彼女のドアのすぐ外に立っていなかったかのように私たちを. (私たちは実際に. それはかなり驚くべきです. 私はそのような抵抗を見たことがありません.
質問... どうすれば彼女を乗船させることができますか? 同調圧力は機能していません。
仲間のスクラムボーグからの感謝
美しい
project-management - スプリント速度の計算
スプリントのチーム ベロシティを計算するためのアドバイスが必要です。
私たちのチームは通常、約 4 人の開発者と 2 人のテスターで構成されています。スクラム マスターは、すべてのチーム メンバーがベロシティの計算に平等に貢献する必要があると主張しています。つまり、スプリントでどれだけのことができるかを計算するときに、開発者とテスターを区別してはなりません。スクラムによると正しいですが、ここに問題があります。
反対の提案にもかかわらず、テスターはテスト以外のタスクを手伝うことはなく、開発者は開発以外のタスクを手伝うことは決してありません。また、さまざまな提案にもかかわらず、テスターは通常、各スプリントの最初の数日間、何かをテストするのを待っています。
その結果、通常、スプリントで実際に処理できる能力よりもはるかに多くの開発作業を引き受けることになります。たとえば、開発者はベロシティの計算に 20 日間、テスターは 10 日間貢献する場合があります。ただし、スプリント計画の後にタスクを合計すると、開発タスクは最大 25 日、テスト タスクは最大 5 日になります。
皆さんは、このような状況にどのように対処していますか?
scrum - SCRUM - 非協力的なチームメンバー
スクラムミーティング中にチームのメンバーが協力的でない場合はどうしますか? 彼らは、現在取り組んでいることの非常に高いレベルの定義を提供するか (「機能 x に取り組んでいます」)、またはSCRUM 方法論について十分に教育されているにもかかわらず、非常に無関係な詳細に入ります。これにより、スクラム ミーティングは効果がなく、退屈なものになります。
スクラム マスターとして、会議中に人々を最大限に活用するためのテクニックは何ですか?
追加するために編集:
しゃべりすぎている人を攻撃的にならずに止めるには、どのようなテクニックを使用しますか?
より詳細な回答を提供するよう誰かを促すには、どのようなテクニックを使用しますか?
自分だけが耳を傾け、他のチーム メンバーはただそこに座って眠りにつくことさえあるとわかった場合、どのように反応しますか?
agile - スクラム バーンダウンの問題
約 9 か月間スクラムを使用しており、おおむね成功しています。ただし、当社のバーンダウン チャートが「モデル」チャートのように見えることはめったにありません。代わりに、上り下りを誘発する吐き気のある恐ろしいジェットコースターに似ています。
これに対抗するために、スプリントのプロトタイピングと設計の前により多くの時間を費やしていますが、それでもスプリント中に最初に考えていたよりもはるかに多くの作業を発見しているようです. 注: これは、バックログの新しい項目を特定したというよりも、バックログを満たすために必要な作業が最初に考えられていたよりも複雑であることを意味します。
これはスクラムの一般的な問題ですか?スムーズに進めるためのヒントはありますか?
私たちの開発作業のほとんどはグリーンフィールドではないため、既存の大規模で複雑なアプリケーションの機能を維持していることを指摘しておく必要があります。既存のコードがどのような問題を引き起こすかわからないという理由だけで、スクラムはこの種の開発にはあまり適していませんか?
スプリントが開発の詳細を検討し始めるまでに、どれくらいの時間を費やす必要がありますか?
更新: 現在、より多くの成功とよりスムーズな乗り心地を実現しています。これは主に、見積もり時に悲観的な見方をしているため、計画どおりにいかない場合に対処するための余裕ができたためです。そのおかげで、私たちはより「アジャイル」になることができたと言えます。また、バーンダウン チャートはスコープ v リソースを示すものではなく、ある種のスケジュールであるという認識を変えようとしています。
project-management - 大規模プロジェクトのユーザー ストーリーの管理
私たちは、多くのサブプロジェクトを含むかなり大きなプロジェクトを開始したばかりです。現在、名前付きプロセスは使用していませんが、バックドアから何らかのアジャイル/スクラムのようなプロセスを取り入れたいと考えています。
私が最も力を入れている分野は、プロジェクト全体の良好なバックログを持つことであり、少なくとも私の頭の中では、バックログからいくつかのものを取り出し、より詳細に検討し、合理的な期限まで開発する反復のアイデアです。 .
プロジェクトを分割してバックログに入れるために人々がどのような手法を使用しているのか、そしてバックログが作成されたら、それがどのように維持および順序付けされるのか疑問に思います。また、要素間の関係をどのように維持するか (つまり、これを行う前にこれを行う必要がある、またはこれが 1 つのストーリーであった場合は 5 つになる)
この質問に対する答えがどのように見えるかはわかりません。最も役立つのは、何らかの方法でバックログをオンラインに保持しているオープンソース プロジェクトがあれば、他の人がどのようにそれを行っているかを確認できることです。
私から+1を得る他の何かは、実際のプロジェクトからの実際のユーザーストーリーの例です(「ユーザーがログオンできる」というストーリーは、私のプロジェクトで物事を想像するのに役立ちません.
ありがとう。
agile - スプリントのバックログをどのように視覚化しますか?
ほとんどのスクラム チームは、現在のスプリントのストーリー/タスクを視覚化するホワイトボードまたはその他のボードを持っています。
人々がこの掲示板をどのように組織しているか気になります。付箋を使っていますか?それらは色分けされていますか?タスクをどのようにグループ化しますか? タスクの状態をどのように区別しますか? 等...
project-management - Bugzilla はスクラム プロジェクトの管理にどの程度うまく機能しますか?
私たちは MS Sharepoint を持っています -- これは、タスク リストを管理するのに悪いことばかりではありません。データは公開されており、変更や割り当てが通知されます。
Bugzilla は、管理とレポートの目的で少し簡単かもしれないと思います。優れたオープン ソース スクラム管理ツールがいくつかありますが、私は自分の政治資本の多くを使い果たしたので、今あるもの以上のものを求めることはできません。目的はお金ではなく、明らかに、私のチームには特殊なツールが多すぎるという考えです。
Bugzilla は、バグ修正以外の、より一般的なプロジェクト管理ツールとして機能しますか?
ひどくがっかりして、何か他のものをダウンロードして、より優れたプロジェクト管理ツールを求めていたらよかったのにと思いますか?
agile - SCRUMのような反復的なアジャイル開発手法を使用するときに、要件を待つことをどのように回避しますか?
私たちは現在の仕事でアジャイル開発を試みており、ほとんどの部分で成功しています。主な問題は、プロジェクトの開発者がスプリントの最初に要件を常に待っていて、最後まで物事を取り下げるために急いでいることだと思われます。要件を提供しているビジネスアナリストは、要件を達成するために常にノンストップで作業しています。
編集:追加情報: 私たちは、内部使用のためにCOTSアプリケーションをカスタマイズしています。私たちの「ユーザーストーリー」は、特定のスプリントでカスタマイズするアプリケーションの部分と、内部で統合するシステムで構成されています。さまざまなシステムとの統合は、すぐに作業を開始できるため、通常はかなりうまく機能します。「x画面のカスタマイズ」は、開発者がそれから何もできないため、主な問題領域です。BAから要件を取得するまで待ってから、実際に何かを実行する必要があります。
編集:より多くの洞察/混乱おそらく: これは大幅にカスタマイズされているCOTS製品であるため、問題の一部はカスタマイズされている画面がすでにそこにあることであるかどうか疑問に思います。人々は、ユーザーストーリーは「Xを実行する画面を作成する」の線に沿っているべきだと提案しています。それはすでに行われています。たぶん、これらの要件に対してユーザーストーリーを作成する良い方法はありません...たぶん、これはまったく新しい質問である必要があります。