問題タブ [scrum]

現在、いくつかのプロジェクトでスクラムを使用しており、さまざまな成功を収めています。ドキュメントに関する質問があります。

スクラムでは、明らかに製品のバックログ (「アプリケーションは、ユーザーが作業していた最後のドキュメントを表示することから始まります。」) とスプリント タスクのバックログ (「パスワードを忘れた場合の画面を実装する」) があります。ただし、私が見たすべての例では、これら 2 つの項目は詳細に関してかなり高レベルです (ポストイットに収まるように設計されています)。

では、詳細はどこにあるのでしょうか? クライアントが在庫管理画面に対していくつかの非常に具体的な要件を持っている、またはバックエンドで統合する必要がある複雑な API を持っているとしましょう。これはどこに文書化され、どのように、誰がこの情報を取得しますか? バックログとは別のものですが、ジャストインタイムまたはその他の方法で入力されていますか?

明確にするために編集する

スクラムは、開発をいくつかのスプリントに分割することを提案しています。各スプリントは固定期間です。各スプリントの終わりに、ソフトウェアをリリースするかどうかクライアントに尋ねます。彼らが「はい」と答えた場合は、リリース スプリントを実行します。この間に、外部ユーザー テスト、パフォーマンス負荷テスト、サインオフ、CD の書き込み (関連する場合) など、継続的に実行したいが費用がかかりすぎるすべてのタスクを実行します。 、ユーザー中心のドキュメントの作成など

私の現在のプロジェクトでは、最初のリリース スプリントを実行したところです。バーンダウンなどのスクラムの多くの利点を失っていることがわかりました (多くのことがマイナーな調整を修正したり、負荷テストを実行できるようにサイトから一時的にセキュリティを削除したりしていたため)、どのくらいの作業が必要かという明確な目標基本的に、リリース タスクは消防に近すぎて、通常のスクラム ツールで簡単に追跡できませんでした。

リリーススプリント中に他の人が使用した方法と、回避すべき落とし穴は何ですか?

ウィキペディアを引用するには：

スクラムは、チームがスプリントの目標を達成する能力に対する障害を取り除くことが主な仕事であるスクラムマスターによって促進されます。スクラムマスターはチームのリーダーではありません (自己組織化されているため) が、チームと気を散らす影響との間のバッファーとして機能します。スクラムマスターは、スクラムプロセスが意図したとおりに使用されることを保証します。スクラムマスターはルールの施行者です。」

これに基づいて作業し、ほとんどの企業が一度に 2 ～ 3 個のプロジェクトを実行しているという事実を踏まえると、SM はフルタイムの仕事を埋めるために実際にどのような作業を行うのでしょうか? それとも、フルタイムの仕事ではなく、個人が開発、販売などの他のことを行っているのでしょうか?

そこに共有するものがある SM はありますか?

累積フロー図の読み方に関するヒントを教えてください。それが私にどのようなことを言っているのかわかりません。

スクラムに関して 2 つの関連する質問があります。

私たちの会社はそれを実装しようとしていますが、私たちはフープを飛び越えていることを確認しています.

どちらの質問も「done は完了を意味します」に関するものです。

1) タスクの「完了」を定義するのは非常に簡単です - 明確なテスト受け入れ基準 - 完全にスタンドアロン - 最後にテスターに​​よってテストされます

次のようなタスクで何をすべきか: - アーキテクチャの設計 - リファクタリング - いくつかのユーティリティ クラスの開発

それに関する主な問題は、それがほぼ完全に内部エンティティであり、外部からチェック/テストする方法がないことです。

たとえば、機能の実装はバイナリのようなものです。完了している (すべてのテスト ケースに合格する) か、完了していない (いくつかのテスト ケースに合格しない)。

私の頭に浮かぶ最善の方法は、別の開発者にそのタスクのレビューを依頼することです。ただし、完全に完了したかどうかを判断する明確な方法はありません。

では、問題は、そのような内部タスクの「完了」をどのように定義するかです。

2) デバッグ/バグ修正タスク

アジャイル方法論では、大きなタスクを行うことは推奨されていないことを知っています。少なくともタスクが大きい場合は、小さなタスクに分割する必要があります。

非常に大きな問題があるとしましょう - 大きなモジュールの再設計 (新しい時代遅れのアーキテクチャを新しいものに置き換えるため)。確かに、このタスクは数十の小さなタスクに分割されています。ただし、最後にデバッグ/修正のセッションがかなり長くなることはわかっています。

それは通常、ウォーターフォールモデルの問題であることを私は知っています。ただし、それを取り除くのは難しいと思います（特にかなり大きな変更の場合）。

デバッグ/修正/システム統合などに特別なタスクを割り当てる必要がありますか?

その場合、通常、このタスクは他のすべてに比べて巨大であり、小さなタスクに分割するのは難しい.

この巨大な一枚岩の仕事のために、私はこの方法が好きではありません。

別の方法があります。小さなタスク (バグに関連するもの) を作成し、それらをバックログに入れ、優先順位を付けて、アクティビティの最後に反復に追加することができます。

私はこの方法が好きではありません。タスクを見積もり、いつでも完了のマークを付けます。そして、新しい見積もりでバグの新しいタスクを開始します。したがって、実際の時間 = 推定時間という結果になり、これは絶対に良くありません。

この問題をどのように解決しますか？

よろしく、ビクター

スクラム ソフトウェア開発の管理に使用するソフトウェアは何ですか?

これまでに Tackle と VersionOne (どちらも無料) を試しましたが、進行中の作業を追跡するのが難しいという事実を除けば、それらは優れています。たとえば、完了までに 8 時間かかると推定されるタスクがある場合、残り 4 時間で 4 時間の作業を行った場合、そのタスクは完了とマークされるまで常に残り 8 時間と報告されます。それはゼロに落ちます。

毎週末にチームの WIP で正確な作業を行い、その作業が完了したタスクと共に締め切りに向けてどの程度の影響を与えたかを確認できるツールを使用したいと考えています。

ご意見ありがとうございます。

どうやら私たちはスクラム開発方法論を使用しています。一般的には次のようになります。

開発者は、自分のタスクを達成しようと奮闘します。通常、タスクはスプリントのほとんどを完了します。QAはDevにテスト可能なものをリリースするようにせがみ、Devは最終的にスプリントが終了する1〜2日前にバグのあるコードをQAにスローし、残りの時間をQAが見つけたバグの修正に費やします。QAはタスクを時間どおりに完了することはできず、スプリントが時間どおりにリリースされることはめったにありません。また、DevとQAは、スプリントの最後に悲惨な数日を過ごします。

リリース可能な開発タスクがスプリントの大部分を占める場合、スクラムはどのように機能するはずですか？

議論に参加してくださった皆さん、ありがとうございました。これはかなり自由形式の質問であるため、1つの「答え」があるようには見えません。以下に多くの良い提案があります。私の「持ち帰り」のポイントのいくつかを要約し、いくつかの説明をしようと思います。

（ところで-これはこれを置くのに最適な場所ですか、それとも「答え」に入れるべきでしたか？）

熟考/行動するためのポイント：

• 開発者のタスクが可能な限り小さい（きめ細かい）ことを確認する必要があります。
• スプリントの長さは、平均的なタスクの長さに適切に基づいている必要があります（たとえば、1週間のタスクを伴うスプリントは少なくとも4週間の長さである必要があります）
• チーム（QAを含む）は、見積もりをより正確にするために取り組む必要があります。
• チームにとって最適な場合は、個別のQAスプリントを並行して実行することを検討してください。
• ユニットテスト！

スクラムは最近非常に人気のある開発プロセスであり、多くの場合、プロジェクト マネージャーは突然新しいタイトル (スクラム マスター) を取得します。ただし、それは単なる新しいタイトルではなく、新しい習慣と新しいパラダイムであるべきです。あなたのスクラムマスターの悪い習慣は何ですか?

新しいシステムの開発を計画する初期段階では、どの開発モデルに従うかが最重要のようです。私は常に、クラシック ウォーターフォール (またはハイブリッド ウォーターフォール/反復プロトタイピング) が中規模から大規模のプロジェクトに最適なアプローチであると信じてきました。プロジェクトが一定の規模になると、アジャイル/XP/スクラムのパラダイムでは、複雑な要件、大規模なチーム、複数のサブシステム間の複雑さ、ドキュメントの必要性、人事異動などを説明できなくなります。等

システムのサイズ、チームのサイズ、LOC などに関して、このようなアジャイル方法論の限界は何ですか?

多くの企業がアジャイルのように振る舞っていると聞いていますが、彼らが行っているアジャイルはスクラム プロセスだけです。これはアジャイルと見なすのに十分でしょうか? スクラムを単独で使用することは、悪いマネージャーがより頻繁に会議を行うための完璧な言い訳のように思えます。私はそのような会社にうんざりすべきですか？