問題タブ [agile]

私たちは、多くのサブプロジェクトを含むかなり大きなプロジェクトを開始したばかりです。現在、名前付きプロセスは使用していませんが、バックドアから何らかのアジャイル/スクラムのようなプロセスを取り入れたいと考えています。

私が最も力を入れている分野は、プロジェクト全体の良好なバックログを持つことであり、少なくとも私の頭の中では、バックログからいくつかのものを取り出し、より詳細に検討し、合理的な期限まで開発する反復のアイデアです。 .

プロジェクトを分割してバックログに入れるために人々がどのような手法を使用しているのか、そしてバックログが作成されたら、それがどのように維持および順序付けされるのか疑問に思います。また、要素間の関係をどのように維持するか (つまり、これを行う前にこれを行う必要がある、またはこれが 1 つのストーリーであった場合は 5 つになる)

この質問に対する答えがどのように見えるかはわかりません。最も役立つのは、何らかの方法でバックログをオンラインに保持しているオープンソース プロジェクトがあれば、他の人がどのようにそれを行っているかを確認できることです。

私から+1を得る他の何かは、実際のプロジェクトからの実際のユーザーストーリーの例です（「ユーザーがログオンできる」というストーリーは、私のプロジェクトで物事を想像するのに役立ちません.

ありがとう。

ほとんどのスクラム チームは、現在のスプリントのストーリー/タスクを視覚化するホワイトボードまたはその他のボードを持っています。

人々がこの掲示板をどのように組織しているか気になります。付箋を使っていますか？それらは色分けされていますか？タスクをどのようにグループ化しますか? タスクの状態をどのように区別しますか? 等...

最近、BDD について聞いたことがありますが、TDD と非常によく似ていることがわかりました。

この 2 つのうち、どちらを使用しますか (もしあれば)。

それぞれの長所と短所はどれですか？

私は常に、ソフトウェアの開発にアジャイル機能駆動開発プロセスを使用してきました。他の人は何を使用していますか?なぜそれを好むのですか? 私が FDD を好むのは、大学を出たばかりの私が FDD から始めたからです。大学では、すべてが非常に自由な形式であり、私の「顧客」は通常、大学で研究を行う以外に業界での経験があまりない教授でした。

現在、私の顧客はそれほど寛容ではなく、私は医療分野で多くの仕事をしています. 敏捷性と高レベルの品質は必須です。

私たちは現在の仕事でアジャイル開発を試みており、ほとんどの部分で成功しています。主な問題は、プロジェクトの開発者がスプリントの最初に要件を常に待っていて、最後まで物事を取り下げるために急いでいることだと思われます。要件を提供しているビジネスアナリストは、要件を達成するために常にノンストップで作業しています。

編集：追加情報： 私たちは、内部使用のためにCOTSアプリケーションをカスタマイズしています。私たちの「ユーザーストーリー」は、特定のスプリントでカスタマイズするアプリケーションの部分と、内部で統合するシステムで構成されています。さまざまなシステムとの統合は、すぐに作業を開始できるため、通常はかなりうまく機能します。「x画面のカスタマイズ」は、開発者がそれから何もできないため、主な問題領域です。BAから要件を取得するまで待ってから、実際に何かを実行する必要があります。

編集：より多くの洞察/混乱おそらく： これは大幅にカスタマイズされているCOTS製品であるため、問題の一部はカスタマイズされている画面がすでにそこにあることであるかどうか疑問に思います。人々は、ユーザーストーリーは「Xを実行する画面を作成する」の線に沿っているべきだと提案しています。それはすでに行われています。たぶん、これらの要件に対してユーザーストーリーを作成する良い方法はありません...たぶん、これはまったく新しい質問である必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

よろしく、ビクター

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

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

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

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

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

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

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

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

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

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

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