伝わるプロジェクト課題の書き方（Backlog） - Qiita
はっきり言うと表題の書き方独自ルールなんて覚えたくありません。 よく「パッと見でわかりやすくしたい」と言われます。 そのパッと見はすべてのシチュエーションに対応できているのでしょうか？ その強調は本当に必要ですか？ もっと重要な他の課題の主張を潰してませんか？ BACKLOG-1 ○○画面で■■のボタンが押せなくなる 種別： 社内FB これでも十分見やすいし伝わります。 重要なことは詳細に追記する（詳細を編集する） BACKLOG-1 ○○画面で■■のボタンが押せなくなる 種別： 社内FB 詳細： 再現できません。 状況を確認してください。 修正が必要なら修正をお願いします。 ... コメント： ○○の画面で◇◇を行うと発生する不具合です。 コメントで調査結果が報告されたとします。とても重要なコメントです。 このまま放置すれば別のコメントによってログが流れてしまいます。 調査した人と修正す
Redmineをスムーズに使うちょっと良い話 - komagataのブログ
Redmineのタスクの更新メール、自分に関係あるものだけ届くようにしてるんですが、複数のプロジェクトが平行して動いているのでいかんせん数が多い。（ミーティングが多い日などは１日でいきなり１００通超える） Gmailでj,kを使ってどんどん見て行くんですが、最近高速に処理するコツが分かって来た。 チケットメールを素早く処理するコツ 基本、（HTMLメールにした場合）このhr線から上だけを見て行けばサクサク処理できる。 ハマってるところで知ってることがあったら「たしかxxxってブログに乗ってましたよー」とか書く。 チケットの内容がよくわからない場合は「イミフ」とだけ書くと、チケット作成者が内容を見直すという合意をしておく。 チケット作成で繰り返し起きるコミュニケーションミスを減らすコツ 新規チケットを作る時にテキストエリアにデフォルトのテンプレを設定しておくと書かなきゃ行けないことがわかりや
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
