0

私たちはスクラムを試してきましたが、しばらくの間、アジャイル アプリケーション開発の独自のバージョンとして形式化しようとしています。これが現在のプロセスの仕組みです。現在の状態では、主な欠点が 2 つあります。あなたが同様のアプローチを持っているかどうか、そしてコミュニティが私たちが現在持っている障害に対する実用的なヒントを持っているかどうかについて意見を求めたい.

  • スクラム チーム = 開発者 4 名、QA 2 名、テクニカル ライター 1 名、PO(PM) 1 名、スクラム マスター (エンジニアリング ディレクター) 1 名
  • リリース = 3 スプリント
  • スプリント = 2 週間

PO と顧客は、ユーザー ストーリーと関連する承認基準の製品バックログを作成します。
各反復の開始時の 1 週間のスプリント計画

  • Day 1# スプリントのバックログを見積もり、優先順位について合意する
  • 2 ～ 5 日目 # スクラム チームは、ストーリーについて話し合い、スプリント バックログの各ストーリーの詳細に取り組みます (ストーリーの詳細を取得し、プロセス フローがある場合は、適用する UE ガイドラインを特定し、UI アイテム/フィールド/ウィジェットの詳細とその特定のものが必要な場合の動作、受け入れ基準の理解、およびテストの作成)
  • 2 週間のスプリントと 15 分のデイリー スクラム
  • 3週間のサイクルを繰り返す

これには、次の 2 つの大きな欠点があります。

  1. 春の計画週で議論される詳細は効果的に取り込まれず、wiki に記録されます。スクラムでそのような詳細をキャプチャするための標準的な形式がないため、多くの場合、毎日のスクラムで時間が無駄になったり、ストーリーの詳細をさらに理解するためにその後の会議が必要になります。スプリント計画において、機能的にかなり複雑な製品のストーリーの詳細を把握する最良の方法は何ですか? 問題のほとんどは、詳細なモックがないと画面/フィールドをどのようにレイアウトするかを開発者が決定できない UI に関連しているようです。
  2. チームがスプリント サイクルにあるときに、顧客から戻ってくる致命的な重大なバグをどのように予測しますか。現在、開発者はこれらのレッド アカウントの問題をサポートするために引き離す必要があり、スプリントが中断されます。

これを改善する方法について何か意見はありますか?

4

3 に答える 3

9
  1. 「標準的な」アジャイル プランはありません。計画は重要ではありません。計画は重要です。つまり、地上の現実を反映するように計画を定期的に調整するということです。計画を策定し、それを力に恵まれ、開発者を縛り付けることは、従来はうまくいきませんでした。
  2. 私が間違っていなければ、スプリント計画は 1 日で終わるべきではありません。スクラムの重要なアイデアの 1 つは、計画にあまり時間をかけないことです。もしそうなら、あなたがより明確になったときに立ち止まって再召集してください..
    • お客様から優先順位の高い一連のストーリーを入手する ~3 時間
    • 開発者は約 3 時間と見積もるために集まります
    • 見積もりを表示し、顧客がビジネス ニーズを反映するようにバケットを変更できるようにします (スプリント クォータ内で) ~rem time.

決定事項の文書化:

  • 良い筆記者を取得しますか？4 人が話すのと同じ速さでタイピングできる人.. 重要なステートメントや決定事項を、チャートや Wiki などの見やすい場所に表示します。

UX調査:

  • UX 作業のパイプライン化を試みます。開発者がそれに到達するまでに、UX 担当者が既に UI の詳細、モック画面、ワークフローなどに取り組んでいることを確認してください。開発者が反復 n に取り組んでいるときに、UX は反復 n+1 のストーリーに取り組んでいます。少し難しいですが、UX が多くの「スラッシング」を引き起こしている場合は実行できます。

バグ義務:

  • 1 つのアプローチは、すべてのバグを次のイテレーションの通常のバックログ アイテムとして作成することです。スプリントの計画中に、どれに参加する必要があるかについて、顧客の賛同を得ます。
  • それが不可能な場合は、バグの流入、修正率、およびそのための計画をトレンド分析します。これらのリクエスト専用のオンデマンド修正開発者のために、x 日間マークを付けておきます。

改善の余地: 開発者がリアルタイムで連絡を取ることができる、「顧客」ロールの専任担当者(または顧客の前に立つことができるコーチ/BA) が必要です。毎日のスクラム ミーティングは 30 分にタイムボックス化する必要があり、ストーリーの「説明」を含めるべきではありません。3つの質問に固執してください - 昨日何をしましたか? 今日は何をしますか？助けが必要な障害はありますか？
特定のストーリーを担当する開発チームまたはサブチームは、特定のタスクに取り組んでいる間に疑問が生じた場合に備えて、カスタマー/フロントと協力する必要があります。. 彼らは、開発作業の一環として詳細を抽出する責任があります。関連分野で働いていた他の開発者にも助けを求めることができます。お客様と協力して、正しい軌道に乗ってください。
HTH

于 2008-10-13T06:41:34.770 に答える
3

うん。あなたのプロセスのどこにも、開発者が実際のエンドユーザーの話を聞いたり話したりしていないことに気付きました。これは失敗のレシピです。実際のユーザーが表現するすべてのニュアンスを「PO」が捉えることは期待できません。

開発者はエンド ユーザーと話をする必要があります。発見された内容を文書化するために、PO もそこにある必要があります。これは、ほとんどの開発プロジェクトで見られる最大の問題であり、開発者とユーザーの分離です。

于 2008-10-13T04:02:13.953 に答える
1

なぜあなたは一週間の長さの計画会議をスプリントするのですか？スプリント計画の目標は、実行できる機能を備えたチームとして快適に感じるのに十分な詳細を取得し、それらを実行することを約束することです。これには通常1日未満（約4時間）かかります。実際の実装の詳細は、スプリント中に開発者によってちょうど間に合うように発見されます。そのため、POとユーザーにアクセスできることが非常に重要です。詳細をどこでキャプチャするかを尋ねる場合は、計画会議で多くのことを設計しています。詳細は、スプリント中にコードに直接組み込まれる必要があります。

ショートッパーは何でしょうか？POは、各スプリントの終了時（2週間）に進捗状況を確認し、ビジネス価値がリリースを保証するのに十分であるかどうかを判断します。重大な問題があった場合、POはおそらくそのスプリントをリリースしません。うまくいけば、機能が完了したときにPOやユーザーに毎日製品を見てもらい、スプリントの最後に問題が発生する可能性を減らすことができます。

于 2008-10-13T04:23:50.603 に答える