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

私は、スクラム方式を使用したソフトウェア開発会社において、継続的インテグレーションワークフローがどのように適合するかをよりよく理解するためのアプローチを研究しています。 私はこのようなことを考えています： それは素晴らしいワークフローでしょうか？

16 testing  development-process  scrum  continuous-integration  workflows 

あなたの経験では、スプリントプランニングミーティング（スクラム）の期間はどれくらいですか？8時間？それとももっと短く（簡潔に）、スプリントの一部としてさらなる議論を計画すべきですか？私たちのスプリントは10日間です。

16 agile  scrum  planning 

これは珍しいテーマではないと確信しています。ストーリーポイントを使用してユーザーストーリーを推定する大丈夫な仕事をしている2つのスクラムチームがあります（チームメンバーは数年のスクラム経験がありますが、現在のチームの星座はわずか8か月です）。しかし、会社のビジネス部門がユーザーストーリーに関連することは困難です。実際の時間単位（または「ストーリーポイントを時間に変換する式」）が必要なため、いつ準備が整うかを計画できます（「Feature Xが生産中であることを顧客に伝えることができる時期を知る必要があります」 "）。 私と私のスクラムマスターの前任者は、もちろん、「ストーリーポイントと実際の時間の間に明確な関係はない」と「ストーリーポイントはチームがスプリントにどれだけフィットできるかを決定するために使用される」と説明しました。彼らがその答えにどれほど満足しているか推測できることを確認してください。彼らは、カレンダーの時間に、バックログの27番目のユーザーストーリーに到達する時期を知りたがっています。 いずれにせよ、私はいくつかの統計情報をコンパイルされている、と私たちのSP推定値はに変換乱暴に異なる実時間費やした結果（チケットは列「に取り組ん」に費やすどのくらいの時間を追跡し、当社のスクラムボードソフトウェア、によって測定されます）。1-SPユーザーストーリーの場合、もちろん非常に短い期間（ときどき爆発する）への大きなバイアスがありますが、特に2-SPストーリーの場合、それらはいたるところにあります。 「最速」と「最遅」の完了間。3、5、および8 SPストーリーの場合、スプレッドも2倍以上です。 これは、（a）チームが（同様の）複雑さのユーザーストーリーの推定においてはるかに一貫性を保つ必要があること、および（b）チームが時間レポートの精度を向上させる必要があることを示します（つまり、会議中、昼食時、またはフーズボールをプレイしているときに「作業中」）。 私は（a）と（b）の両方を改善する計画がありますが、これらのイニシアチブがもたらすものよりも「具体性」をビジネスが期待しているだけでは不十分だと感じています。 ビジネス側を和らげるいくつかの良い戦略は何ですか？それは私たちがどのように仕事をするかをあまり邪魔しないようにするためです（たとえば、個別の時間追跡の使用を課すことによって現在の「自動」追跡）、同時にストーリーがいつ行われるかについての具体性のある程度の測定値を取得できるようにしますか？ （歴史的に、計画中にユーザーストーリーをワークアイテムに分割し、実際の作業時間で個別に推定しましたが、ここで話しているのはバックログのユーザーストーリーで、そのレベルの詳細やブレークはありません-ダウン。） 更新：私のマネージャーは、ストーリーポイントごとの時間のベル曲線分布のようなものがあるという予感がありましたが、私が照合したデータと彼が作成したグラフは、彼の考えを徹底的に否定しました。:-)

15 scrum  estimation 

私たちのビジネスアナリストとプロジェクトリーダーは、ストーリーとしてのクライアントの要件を教えてくれます。すべてのスプリントプランニングでは、開発者はプランニングポーカーをプレイするよう求められます。 彼らは私たち全員に、「努力」ではなく「複雑さ」を考慮するように頼みました。私たちは本当に混乱しており、会議に時間を浪費しています。ある開発者は、「何を本当に検討したいのですか？この要件（時間の見積もり）で行う必要があるコード/ DDLの変更に関するものですか、それとも要件を理解したかどうかに関するものですか？ しかし、彼ら（ビジネスアナリストとプロジェクトリーダー）は、「要件を理解する」と「カードを調達する」とはどういう意味ですか？ さらに、個々のスクラムチーム用のスライス会議があり、各開発者が各スクラムチームの特定のタスクの時間を見積もります。それで、彼らはPlanning Pokerで本当にどんなことを話しているのでしょうか？ 例を使用してこれを説明できる人はいますか？彼らが「複雑さ」と「努力」と言うとき、彼らが本当に話していることを区別するようにしてください。

15 agile  scrum  planning 

一部のチームメンバーは、作業する可能性が最も高いストーリーが議論されるまで待ってから参加します。それ以外の場合、彼らは自分の携帯電話で遊ぶだけで、耳を傾けません。 どういうわけか私はこの立場を理解しています。Sprintでの開発に役立つとは思われない機能に関する議論を聞くのはなぜですか？ 何をすべきだと思いますか？

15 agile  scrum 

新しいプラットフォームに移植する必要がある既存の言語があります。既存のコンパイラのバックエンドを変更することで、おそらくこれを試みます。 バックエンドを書き直すのはかなりの作業です。INVEST基準に違反することなく、これを理にかなったストーリーに分解する方法はありません。 各ストーリーがどのように交渉可能であるかはわかりません-それらはすべて、動作するコンパイラに必要です。ストーリーの優先度はすべて同じであり、配信する順番は関係ありません。それらすべてを行う必要があります。 私が実装しているソフトウェアには、他の部分より優先度が低い部分があり、それを段階的に提供できることがわかります。ただし、Must Haveという重要なコアがあります。 私はスクラムを追いかけようと計画していますが、私はただ動きをしているだけですか？ この種のプロジェクトに推奨されるプラクティスはありますか？

15 scrum  compiler  porting 

現在、大学で提供されているソフトウェアエンジニアリングおよびキャップストーンデザインコースの新しいカリキュラムを開発するために、大学の教授と協力しています。 最近まで、両方のコースでウォーターフォールモデルを排他的に使用していたため、学生は長い時間をかけてレポートを作成していました。私からの多くのプレッシャーの後、私の教授は、この学期にスクラムをソフトウェアエンジニアリングカリキュラムに含めることにしました。 学期の前半はまだ滝のようで、学生は40ページの設計レポートとソフトウェア仕様書を書きました。学期中期には、すべてのチームがアプリケーションのデモをリリースする必要がありました。その時点で、コースはスクラムに切り替わり、3週間のスプリントが2回行われました。現在、ウォーターフォールを完全に排除し、スクラムベースのカリキュラムのみを作成する方法を考えています。 残念ながら、スクラムと学生の間でいくつかの非互換性が発生しました。 毎日のスクラム会議は、学生にとってほぼ不可能です。授業中であっても、教授が通常講義しているため、学生がスクラム会議を開催するのは不便です。 学生は経験が浅いため、何か時間がかかるのを正確に予測できないため、ポイント/時間の推定は困難です。 スクラムは、常勤の同じ場所にいる開発者に最適ですが、学生もそうではありません。せいぜい、学生はコースに週15〜20時間を捧げ、仕事の会議を開催することは非常に困難です。チームには最大10人の生徒を含めることができます（常に1人または2人の怠け者がいます）。 教授はドキュメントを切望しています！スクラムレポートは聞いていません。バックログとバーンダウンチャートだけです（アカデミックをなだめるのに十分かどうかはわかりません）。 学生はしばしば、アジャイルは「すぐにジャンプして、振り返らずにコーディングを開始する」ことを意味すると思います。これは、想像できる最も恐ろしいコードの一部につながります。したがって、50ページのドキュメントやUMLダイアグラムの山を必要とせずに適切な設計を実施する方法を探しています。 これらの問題を考えると、教授と私はスクラムをアカデミックな環境で機能するようにどのように適応させることができると思いますか（そもそもスクラムを気にする必要がありますか）。また、ウォーターフォールモデルを教えることにはまだ価値がありますか？ フィードバックを事前にありがとう！

15 agile  scrum  documentation 

私は、会社の新しいプロジェクトの開発チームのリーダーです。これは、会社がスクラムを使用する最初のプロジェクトです。ウォーターフォール/反復SDLCがあります。BAは要件のドキュメントを作成し、開発者とテストに引き渡し、開発者は開発を開始し、反復してテストにリリースします。テスターは、開発者が開発を継続するリリースだけでなく、現在のリリースのバグ修正をテストするのに長い時間がかかります。少し質問があります 5つのストーリーがあるスプリントでは、いつテストのためにリリースしますか？開発者がストーリーを完了した直後か、すべてのストーリーが完了した後、スプリントの終了前に、テストに必要な時間を与えますか？ BAがユーザーストーリーを作成する場合、詳細を何にするか。従来、すべてのUIレイアウト、動作、テキストなどをまとめて仕様を作成するには、長い時間がかかります。私の質問は、実装可能でテスト可能なストーリーをどのように書くかです。 テストチームは技術的ではありません。スクラムのUIテストを自動化することの重要性。UIはWPFに基づいています。 アジャイル手法（TDD、コードレビュー、リファクタリングなど）を使用した確かな開発経験がありますが、スクラムは初めてです。 編集：反復によって、100の要件がある場合、100の要件がすべて完了するまで待つのではなく、30、35、35の要件を完了したときにテストにリリースできることを意味します。

15 scrum 

組み込みシステムのスクラムには2つの問題があります。第一に、特に初期段階では多くのタスクを実行する必要がありますが、それは実証できません。開発ボード、OS、ディスプレイ、シリアル通信などから始めました。6つのスプリント用のディスプレイはありませんでした。 最初の4つのスプリントは次のとおりです。 取得RTOSを起動して実行 ネットワークおよびシリアルドライバーを作成するタスクの作成 ボタン、通信などの割り込みルーチンの作成 プライマリデータベースのクラスとメソッドの作成 シリアルデバッグメニューの作成 これらのタスクのほとんどは、ユーザーストーリーにはあまり適していません。実際、システム全体への唯一のインターフェースは、スプリント3に組み込まれたシリアルデバッグメニューであったため、スプリントの最後にデモンストレーションするものはありませんでした。シリアルメニューでさえ、エンドユーザーではなく内部使用を目的としていました。それにもかかわらず、私はまだスクラムを介してこれらの開発活動を追跡および管理したいと考えています。 「開発者として...」などの「ユーザーストーリー」というフレーズを書くことになりましたが、これは満足できませんが、ターゲットプロセス（www.targetprocess.com）を使用する場合、バックログアイテムという概念はありません。タスクまたは雑用。 次に、リリースとテストをどのように処理しますか？テスターに​​はハードウェアデバッガーがないため、非常に苦痛です。したがって、コードのフラッシュバージョンをビルドし、テストするために開発ボードに書き込む必要があります。テスターは技術的には開発者ほど鋭くなく、多くの場合、初期段階（ボードのリセット、シリアル通信の接続など）で作業を行ったり、出力を理解したりするのに多くのサポートを必要とします。 最後に、完了の定義に関して、スプリントはすべてのストーリーが完了するまで完了できません。すべてのストーリーは、テスターに​​よって検証されるまで完了しません。開発者がテスターに​​与える時間を「奪う」ことを避ける方法はありません。つまり、スプリント内の最後の3つのユーザーストーリーのテストに5日間かかる場合、スプリント終了の5日前にコーディングしてユニットテストを行う必要があります。開発者は何をすることになっていますか？仕事をやめる？ 私は面白く思っていますが、ルールに準拠しようとするのは本当の問題です。今、私はルールを曲げることに問題はありませんが、私が抱えている問題は、テストされるまで物事をマークできない場合、すべてのバーンダウンメトリックを台無しにします。 他の人がこれらの状況をどのように処理したか聞いてみたい。

15 agile  scrum  embedded-systems 

最近、スクラムプロセスに移行し、スプリント内のタスクとユーザーストーリーに取り組んでいます。コードを頻繁にレビューして、手間を軽減したいと考えています。ユーザーストーリーレベルでそれらを行うことを考えていますが、これを説明するためにどのようにコードを分岐させるのかわかりません。 VSとTFS 2010を使用しており、6人のチームです。 現在、機能の分岐を行っていますが、スクラムの分岐への変更に取り組んでいます。 現在、シェルフセットを使用しておらず、他に利用可能な技術がある場合は実際に実装したくありません。 ユーザーストーリーごとにコードレビューを実装することをどのようにお勧めしますか？

15 agile  code-reviews  scrum 

私は過去9年間に多数の小さなチームで働いてきました。それぞれには、短い会議、改訂管理、継続的統合ソフトウェア、問題追跡などの明らかな優良事例がありました。 この9年間、開発方法論についてあまり聞いたことはありません。たとえば、「私たちはスクラムをやっている」、「アジャイルをする」、または参照を超えるものはありませんでした。すべてのチームはうまく機能しているように見えましたが、多くのプロセスを踏まなくても、ただのフリーフローで、自然にうまく機能していました。 スクラム/アジャイル/その他に遭遇することなく、他の誰かが長期間進歩しましたか？ 私がこれらにさらされた唯一の露出は、このようなサイトを通してです。私はスプリント会議のような質問を読みます-何を話すべきか ...そしてすべての話は方法論の有限状態機械に従う人々のようなほとんどロボットのことを説明しているようです。それは本当に（誇張されていますが）そのようなものですか？インターネットに投稿している人々は、「ベストプラクティス」を大声で支持しているだけで、教科書の見方も同じで、実際に人々がどのように働いているのかを反映していないのでしょうか？ さらに（私は英国にいるので、関連があるかもしれません）...私が取り組んでいるチームのいずれかに方法論が導入された場合、彼らはそれを愚かで不必要であるとして拒否するでしょう...オン。同意する傾向がありますが、次のプロセスは少し不自然に思えます。これは典型的ですか、それとも一般的ですか？

15 development-process  agile  scrum 

理想的なアジャイルの世界では、目的のエンドシステムの小さいながらも有用なサブセットをすばやく構築し、ユーザーに提供します。彼らは興奮している、なぜならそれは便利だからだ。彼らはそれを使い始め、フィードバックを与える。次に、何を追加するのかを考え出し、それを構築し、時間がなくなるまで繰り返します。 私は最近、いくつかの種類の作業システムの交換を伴うプロジェクトをいくつか行ってきました。上記のモデルはまったく機能しませんでした。既存のシステムのほぼすべての機能を含むシステムを構築するまで、ユーザーはまったく興味を持ちませんでした。彼らはそれを使用しません。 「最小の有用なサブセット」が「すべて」の場合、どのようにアジャイルを適用しますか？

15 agile  scrum  users  iterative-development 

1週間のスプリントのスプリント計画に5時間以上かかりました。それは多すぎるようです。 ほとんどのチームメンバーはシニアではないため、スプリント計画で詳細を議論します。そうしないと、実装中にミスが発生し、スプリント中に再設計されます。 これにどう対処しますか？ 1週間のスプリントあたりわずか2時間の長さに合わせるために、計画中にどの程度詳細に議論する必要がありますか？

14 agile  scrum  planning  sprint 

スクラムを正しく理解していれば、次のスプリントでチームが引き受けることができる仕事を決定する方法は次のとおりです。 過去数回のスプリントで完了したポイントの数を平均します。 この量は平均速度です。次のスプリントでは、多くのストーリーポイントを取り上げます。 これは平均であるため、履歴が繰り返される場合、このスプリントは、ストーリーポイントが少なすぎる可能性が50％あり、ストーリーポイントが多すぎる可能性が50％あります。 50％のケースでは、できる限り多くのストーリーポイントを使用しました。 スプリントを完了できません。これは、スプリントのコミットメントを半分の時間で満たさないことを意味します。 追いつくために余分に働く。問題は、これが一方向にしかラチェットしないことです。スプリントを達成し、完了したストーリーポイントの数はそれを反映します。私たちは常に時間をかけて終了するので、私たちの平均は常に多くのストーリーポイントを達成し、遅れている点まで上昇傾向にあります。 平均速度とスプリントのコミットメントについての私の理解は正しいですか？ もしそうなら、平均より遅れているスプリントの50％に対して何をすべきでしょうか？ そうでない場合、何が間違っていますか？

14 scrum  user-story  sprint  scrum-master 

私が現在働いている会社では、スクラムプロジェクトを始めました。管理者に滝からスクラムに移行するよう説得することはそれほど難しくありませんでした。プラットフォームをゼロから再構築するプロジェクトを行っています。（ほとんどの）機能は既知であり、ほとんどの改善はかなり技術的です。 これでは、ユーザーストーリーではなく技術的なタスクを持つことを正当化できます。バックログには、次のようなあらゆる種類の技術的なタスクがあります。 MySQLからPostgreSQLにDBクラスを書き換えます。 システムロギングを実装します。 オブジェクトキャッシュを書き換えます。 スタンドアップ中に出てくるものには、長い「研究タスク」が必要であるが、決して実行されないことが含まれます。また、チームメンバーは、スプリントの途中で、計画外のタスクを追加する必要があると主張します。 スクラムマスターはこれにどのように対処する必要がありますか？この種のプロジェクトにとって、スクラムは進むべき道ではないのでしょうか？

14 project-management  scrum  user-story  product-backlog