agile - スクラムのプログラミングタスクの詳細はどこにありますか？

Question

スクラムでスプリントタスクを行う場合、どのようにプログラムしたいのかをどこに置きますか？たとえば、テトリスゲームを作成していて、現在のスコアとハイスコアテーブルを追跡するゲームの部分を作成したいとします。機能、ユーザーストーリー、タスクはありますが、今度はそれを設計する方法について話したいと思います。

そのデザインは、それを行う方法についてどこかでスプリントに記録されているものですか、それともプログラマーが理解しているものですか。タスクxデータベースなどを使用したり、これらの列を作成したりしますか？そうでない場合は、それを記録しますか？それがtracの目的ですか？高レベルのデザインという意味ではありません。

ここで触れました： スクラムプロセスのどこでプログラミングアーキテクチャが議論されていますか？

しかし、私の現在の質問は、インフラストラクチャの後のプロジェクトの後半にあります。私は今、真ん中についてもっと話している。コードの実際の入力。途中で決めると言う人もいれば、チームリーダーもいます。これは、ドキュメントとコメントを含むコード自体を除いて、どこにでも文書化されていますか？

編集：あなたの上司はただ言うのですか、わかりました、あなたはこの部分を行います、私はどのように気にしませんか？

ありがとうございました。

Answer 1

これを少し混乱させる可能性のあるユーザー指定の要件に加えて、アーキテクチャ要件が存在する可能性があります。したがって、「これにはMVPを使用します」というものがあり、これによって設計が少し制限されます。

私の現在のプロジェクトでは、チーム外からの要件は別として、プログラマーはそれが私たちの標準的な操作手順であると理解しています。これは、チームの他のメンバーが簡単に使用して変更できるように、全員が何かをコーディングするわけではないため、後でクレイジーなことを実行してやり直すことができることを意味します。

コード、コメント、およびドキュメントは、コーディングの詳細が見つかる場所の99％をカバーしています。ウィキがドキュメントの一部であると仮定した場合、何が残っていますか？

Answer 2

スクラムはプログラミングタスクについてはまったく何も言いません。それを解決するのはあなた次第です...

スクラムは必ずしもプログラミングと明示的に関係しているわけではありません。雑誌の発行、教会の管理、美術館の展示会を整理するために使用できます。これは、ソフトウェア開発を明示的に管理する方法ではない管理手法です。

スクラム内でエクストリームプログラミングを行う場合は、反復のユーザーストーリーをタスクカードに分割し、ペアにして実行します。

Answer 3

プログラミングチームにタスクを送信すると、説明は通常、デモの形をとり、レビューのために機能がどのように表示されるかについての説明になります。

タスクを評価するときに、タスクの実装方法が決定されます。チームメンバーは、タスクを小さな項目に分割します。デザインが必要な場合、チームはそれを分割する前にそれについて話し合う必要があります。設計が複雑すぎてこの会議内で実行できない場合は、設計タスクを作成するだけです。アジャイル/スクラムは、これをどのように実行するかを強制しません（wiki、ドキュメント、頭の中で、ナプキン、あなたの選択）できるだけ少ないドキュメントを言うことはさておき。ほとんどの場合、設計は少し議論した後、その場で決定され、結果として得られる小さなタスクは、物事がどのように行われるかを説明したものです。

また、それをしている人は、デザインを変える途中で発見をすることがあります。その後、いくつかのカードを捨てて、新しいカードを作るかもしれません。重要なのは柔軟性です。

Answer 4

あなたはあなたがする必要があることをします。すべてを事前に設計することは避けてください。ただし、変更されないことがすでにわかっているものがある場合は、それらをキャプチャするだけです。ただし、YAGNIの当然の結果として、必要なものの理解が誰かがそれを行う前に変わる可能性があるため、あまり早くキャプチャしようとしないでください。

あなたの質問は、いつ、どこでではなく、誰に尋ねるべきかというように聞こえると思います。アジャイルプロジェクトが成功する理由は、人々がプロセスの一部であることを理解しているからです。失敗したアジャイルプロジェクトは、誰かの「本」の考えに従って物事を行うことを好む傾向があり、人々や彼らが持っているプロジェクトを理解していないようです。1人のシニアチームリーダーと多数のジュニア開発者がいる場合、おそらくシニアはそのような詳細にもっと時間を費やす必要があります（多分強調します）。先輩がたくさんいる場合は、個人に任せる方がいいかもしれません。チーム間の考慮事項はないと思います。その場合、複数のチームがそれに依存している場合、DBスキーマなどの詳細の一部をハッシュ化する必要があるかもしれません。

Answer 5

あなたが（チームメンバーとして）デザインについて話す必要があると感じた場合は、他のチームメンバーとブレーンストーミングを行うために、デザインについて話し合ってください。その方法については、多くのチームがこれにホワイトボードとブレインジュースを使用し、物事を軽量に保つことをお勧めします。これは私見の良い習慣です。

個人的には、少なくともプロジェクトの初期段階では、正式な文書にすべての決定と詳細を書き留めることにはあまり価値がありません。書かれた文書は維持するのが非常に難しく、かなり早く非推奨になります。ですから私は対面でのコミュニケーションを好む傾向があります。実際、書面による文書は、実際に使用される場合にのみ、非常に短期間に作成する必要があります。これは当たり前のように聞こえるかもしれませんが、（廃止された）ドキュメントを非常に誇りに思っているプロジェクトがいくつかありますが、コード行はありません。それはばかげています。言い換えれば、誰かがそれを評価する場合にのみ、可能な限り遅く、広範なドキュメントを作成します（たとえば、製品の所有者）。