More Related Content Similar to タスク管理ってどうやってやるんだ? Similar to タスク管理ってどうやってやるんだ? (7) More from komeshogu n (20) タスク管理ってどうやってやるんだ?16. こめちゃん @kome 1分
補足)プロセスの7つのムダ
① 未完成作業の無駄 :WIPの個数を増やすこと
② 余分な機能の無駄 :作り過ぎほど無駄なことはない
③ 再学習の無駄 :過去の失敗を忘れて解決策を再度学ぶこと
車輪の再発明なんて揶揄されることもある。
④ 引き継ぎの無駄 :多くの情報が失われる
⑤ 遅れの無駄 :フィードバックが遅いと、
原因と結果を結びつけるのが難しくなる
⑥ タスク切り替えの無駄 :コンテキストスイッチが発生すること
⑦ 欠陥の無駄 :システムのヘルニア。
バグを前提にして、それに依存したコードを書いてしまう
15
プロセスのムダを7つの観点で整理。
どれも見に覚えのあることばかりではないでしょうか。
このページだけでディスカッションできそうです(笑)
19. こめちゃん @kome 1分
参考)
アンチパターンを是正するためのチェックリスト
カンバン上のすべてのステップに「完了」列と完了基準があることを確認しているか。
すべてのステップにWIP 制限が設定されているか。
WIP 制限を使って「作業中」列と「完了」列のカードの合計枚数を制限しているか。
最後のステップのWIP 制限は作業中の項目にのみ適用される。
カンバンのボードをいつでも更新しているか。
チームのメンバーにも同じようにすることを勧めているか。
デイリースタンドアップミーティングの後に、設計についての話し合いやチームの一部の
メンバーに関係する問題のための時間を割り当てているか。
チームのメンバーがオンラインボードを扱いにくいと感じている場合に、物理的なボード
を使用しているか。
あなたの戦略やパートナーに合わせてバックロックの計画を慎重に立てているか。
「分解」ステップを追加するか、「分析」ステップに完了基準を設けることで、大きな作
業項目が小さなタスクに分解されるようにしているか。
品質がすべてのステップに組み込まれるように完了基準を設定しているか。
品質が先送りになるような依存関係に対処する方法を決定しているか。
顧客のフィードバックやデモを顧客の予定に合わせてスケジュールしているか。
18
Kanban_GuestArticle.indd
http://web-cache.stream.ne.jp/www11/nikkeibpw/com/sp/Kanban_GuestArticle.pdf
また見といて。
21. こめちゃん @kome 1分
チケット駆動開発(TiDD)とは?
チケット駆動開発 (ticket-driven development; TiDD) とは、プログラム開発手法の一
種で、作業をタスクに分割しBTS(Bug Tracking System/バグ管理システム)のチケッ
トに割り当てて管理を行う開発スタイル。細かな修正作業の多い従来開発の中で生まれた
が、アジャイル開発との親和性が高いことから、エクストリーム・プログラミングをはじ
めとするアジャイル開発でも実践されている。
ルール
チケットをプロジェクトの情報の中心とする
チケットによる作業の割り振りと進捗管理
チケットなしのコミットは禁止とする
20
開発作業は、すべてチケットを起票してから取り組む。
体裁や分類はあとでも整理できるので、とにかく始める。
ただし、できるだけ早めにルールを決めること。
22. No Ticket, No Commit!
チケットなしのコミットは禁止(No Ticket, No Commit!)
コミットのログにチケットIDを入れておけば、コードとチケットが紐づく
個人的な管理ではなく、構成管理上のコミットをしないということ。
Gitなら No Ticket, No Push!
このルールによって開発メンバーの仕事が把握しやすくなるだけでなく、
成果物の更新が必ずチケットと関連付くので変更理由が明確になる、
というチケット駆動開発のメリットが生まれる。
21
https://flic.kr/p/adhX1Q
23. TiDDの3つのメリット
1. 必ずチケットと紐付けるため、誰が何のためにどのコードを編集したかがわかる
チケットとコードが紐づくため、コードの可視化ができる。
編集したコードに問題があるのかもわかるし、プログラマーの作業のブラックボック
ス化を避けることができる。
2. ソースから変更履歴が無くなる
コミットログやチケットに記録することで、ソースに変更履歴は不要となる。
コードは常に最新で綺麗な形に残せる。
担当者間のちょっとしたやり取りなどメタな開発プロセスを
チケット上に実現できる。
3. コード修正に伴うタスクや情報を整理することができる
チケットにコードレビュー、設計書の修正など管理項目を設けることで
コード修正に伴う作業の漏れを防ぐことが出来る。
チケットごとの工数を登録すると結局全部の工程でどれくらい時間がかかったのか
集計を取ることもでき、実績を元にした見積りやコスト計算をする材料にもなる。
22
24. チケットの書き方
追跡ID (where)
電子的なツールの追跡ID
タイトル
必ず会話につながりやすいタイトルにする
作業の種類
バグ:赤、技術タスク;:緑、機能要求:黄色
説明 (what)
簡潔に
要点を押さえる
チーム全員が理解できるように
納期 (when)
作業が完了する日付
サイズ
予定工数と実績工数
進捗インジゲーター
どの程度完了したか
23
25. こめちゃん @kome 1分
コミットコメントの書き方
情報価値が高いコメント
コミットコメント以外では記録できない情報
5W1Hのうち、自動でかけないのが「WHY」(なぜ)
適切な文脈で変更内容を捉える
今なにをしていたのか
そもそも何のためにそれをしようとしていたのか
チケットと紐付ける
Redmineでは「IssueID #チケット番号」
24
https://flic.kr/p/5uyLSB
チケットに詳細を書いているので、WHY(なぜ)を
1行だけ書けば十分かと。
WHYを書けば、前回と同じコメントになることはないはず。
28. こめちゃん @kome 1分
ほかにも注意すべきこと
チケットを出す人と処理する人のコミュニケーションが
密に取れていれば良いのですが、そうでない場合、
そのタスクや機能が本当に必要か、必要な場合でもそのタイミングで必要か
どうか、ちゃんと精査されていないチケットを発行したり処理することにな
ります。
チケット発行側とチケット処理側の関係が浅かったり、
コミュニケーションの距離があったりすると、
チケットを簡単に却下することもできなくなります。
都度ミーティングして対立した意見を出すくらいなら
さっさとチケットクローズさせる、みたいな流れになると、
不毛な作業をすることになったり、
もしくは無駄なチケット放置してカオスな状態になったりします。
27
いいことばかりじゃない。
あくまで手法(ツール)なので、使い方次第で悪化する危険も。