タグ付けされた質問 「task-organization」

私は最近、開発プロジェクトに参加しましたが、突然主任開発者の仕事を与えられました。私の主な責任は、プロジェクトのプログラミング部分をタスクに分割し、これらのタスクを他の開発者に与えて、それらの部分が連携して動作することを確認することです。 問題は、これを行う方法がわからないことです。私は週末を鉛筆と紙でそれを理解しようとして過ごしましたが、並行してではなく順番に取り組むべきタスクのリストを考え出し続けています。機能に分割することを考えたかもしれませんが、同じファイルを編集する必要があるタスクになります。開発の早い段階のため、タスク全体を完全に書き直す必要があります。プログラムがもう少し完成してタスクを作成しやすくなるまで開発者を待たせることもできましたが、その後、何週間かを知っている人たちに手を貸してもらいました。 私はこれを行う資格について上司と会話しましたが、この問題について選択肢は与えられませんでした。自分が何をしているかわからないので、正しい方向へのヒントやナッジは大歓迎です。

164 team-leader  task-organization 

私が現在取り組んでいるプロジェクトには問題があります。バグやタスクは、あまりにも新しい人や経験の浅い人に割り当てられることが多く、彼らの仕事は将来的にさらにバグを生み出すことになります。問題は、コードの品質の問題のために、ソフトウェアの一部が他の部分よりも「危険」であるということです。私は、タスクに関連するリスクを推定し、どの開発者にどのタスクが割り当てられるかに細心の注意を払うことで、この問題に対処しようとしています。 JIRAを使用しているため、この推定を追跡するために問題のラベル付けを開始しました。バグ/タスクを分類するためにいくつかのメトリックを使用することになったことに気付きました： それがどれほど明確/単純か。たとえば、多くの設計作業が必要なのか、単純なUIのバグ修正が必要なのかなどです。 コードの影響を受ける領域の保守性。うまく設計されたエリアなのか、泥だらけの大きなボールなのか。 必要な変更の影響を受けると思うプログラムの量。 考えられるカテゴリが何であるかを始めたとき、私は明確な考えを持っていなかったので、私のラベルは少し厄介です。仕事を誰かに割り当てる前に見積もりを要求できるように、新しいフィールド（「リスク」のようなもの）の追加を要求することを考えています。 誰もこのようなことを以前に扱ったことがありますか？

17 project-management  task-organization  jira 

私は、新しく形成されたスクラムチームのスクラムマスターにノミネートされました。すでにいくつかのスプリントを行っています。最初は、チームが一度に1つのストーリーに取り組むようにしようとしました。しかし、うまくいきませんでした。私のチームは、1つのストーリーで同時に作業できるようにタスクを分散するのが困難でした。たぶん私たちは何か間違ったことをしているのでしょうか？ たとえば、新しいダイアログを作成するストーリーがあります。次のタスクを作成します。 モデルクラスを作成する データベースからモデルデータを読み取る モデルクラスをビューに接続する ダイアログ処理を実装する 閉じるときにデータを保存する テスト文書 ソリューションの説明 一度に複数の人がこれらのタスクを実行できますか？タスク-多かれ少なかれ-は互いに構築されます。または、間違った方法でタスクを設計していますか？

12 scrum  task-organization 

私のチームは、次のプロジェクトでVisual Studio Team Servicesを使用します。アジャイルツールを使用すると、次のようにユーザーストーリーとタスクを階層的に整理できます。 エピック>機能>ユーザーストーリー>タスク/バグ 高校生とアドバイザーのためのStudent Org（クラブ）管理システムを設計しているとしましょう。学生とアドバイザーはクラブに参加したり、役員になったり、イベントを企画したり、お知らせを送信したりできます。 アナウンス機能を例に見てみましょう： ユーザーストーリー： 学生として、自分が所属しているクラブのお知らせを読んで、スケジュールの変更を認識したいと思っています。 アドバイザーとして、自分が所属しているクラブの告知を読んで、スケジュールの変更を認識したいと思っています。 アドバイザーとして、所属するクラブに通知を送信して、生徒がスケジュールの変更を認識できるようにしたい 管理者として、すべての学校のクラブにアナウンスを送信して、スケジュールの矛盾を認識させることができます。 等 これらが適切に記述されたユーザーストーリー（そうではない可能性があります）であると想定すると、開発チームとこれらの項目を開発タスクに分割するために座るときに混乱します。複数のユーザーストーリーの一部を単一の開発タスクでカバーできます。たとえば、お知らせのプロパティを定義するだけで、UIからDBまでのすべてのレイヤーのCRUDアクションを生成するツールがあります。したがって、いくつかの「送信」および「読み取り」ユーザーストーリーの部分は、単一の開発ステップで完了します。 私が読んだことから、各ユーザーストーリーは他のユーザーストーリーから独立している必要があり、それは理にかなっています。ただし、ユーザーストーリーのそれぞれが「UIとDBを生成する」タスクを共有しています。これは、この方法で（カスタマイズする前に）ベ​​ースレベルのUIを作成するためです。ユーザーストーリーごとに「UIとDBを生成する」タスクを書くべきではありません。冗長性が高すぎます。しかし、ユーザーストーリーを開始する前に完了する必要がある「UIとDBを生成する」タスクの記述方法がわかりません。 私の許可システムにも同様の混乱があります。Student、Adviser、Adminなどのさまざまなアカウントタイプがあり、すべて[お知らせ]ページにアクセスできますが、ページ内の機能は異なります（このアイデアは上記のユーザーストーリーでキャプチャしました）。アクセス許可システムを他の機能で使用できるようにモジュール化することもできますが、「モジュール化されたアクセス許可システム」を作成するタスクをどこに書き込むかわかりません。 このユーザーストーリー全体が混乱しているようです。はい、それはシステムの機能をキャプチャするのに最適ですが、開発タスクを通して考えるとなると、私はそれに頭を抱えているようには見えません。どんなアドバイスでもいいでしょう。 TL; DR：あるユーザーストーリーで行うプログラミングの一部は、他のユーザーストーリー（アクセス許可システムなど）のプロジェクトの他の場所で使用できます。この可能性を説明するために、ユーザーストーリーのタスクを作成/整理するにはどうすればよいですか？

8 agile  user-story  task-organization  task