Recomendados
Mais conteúdo relacionado
Semelhante a タスク管理ってどうやってやるんだ？
Mais de komeshogu n
Último
Último (10)
タスク管理ってどうやってやるんだ？
- 2. 1
- 4. 3
- 5. 4
- 6. 5
- 7. 6
- 8. 今回のターゲットとゴール ターゲット タスク管理を上手くしたい って方 ゴール 1. こんなタスク管理があるんだって知る 2. このやり方を詳しく調べてみたいってなる 3. もっと良い方法あるよって話したくなる 7 このゴールに向かって 発表します。 気楽に聞いて下さい
- 13. タスクかんばんとは？ それぞれの仕事をチケット（付箋紙）に書いて 「TODO」「DOING」「DONE」という3つのステージに分割し、 仕事の状態を付箋紙に書いて貼り付けたかんばん。 バリューチェーン(※)全体を仕事がすばやく流れるようにするためのもの。 (※)バリューチェーンとは、アイデアやコンセプトがソフトウェアとして動作し、顧客を喜ばせるまでの一覧のプロセス 誰がその仕事をやっているのか 自分が何をやっているのか 仕事がどう進むか 機能要望をもとにどんな仕事をすればよいか をタスクかんばんから学ぶことができる。 12
- 14. こめちゃん @kome 1分 タスクかんばんの３つの原則 見える化によるチームの協調支援と透明性の確保するために 1. 見える化 2. WIP（仕掛り）の制限 3. 流れの管理 をして、仕事がプロセスを流れるようにする。 そうすれば、改善の機会を簡単に見つけられる状況を実現できる。 13 タスクかんばんに、この３つの原則があることを覚えておこう。 詳しくは、次のページへ
- 16. こめちゃん @kome 1分 補足）プロセスの７つのムダ ① 未完成作業の無駄 ：WIPの個数を増やすこと ② 余分な機能の無駄 ：作り過ぎほど無駄なことはない ③ 再学習の無駄 ：過去の失敗を忘れて解決策を再度学ぶこと 車輪の再発明なんて揶揄されることもある。 ④ 引き継ぎの無駄 ：多くの情報が失われる ⑤ 遅れの無駄 ：フィードバックが遅いと、 原因と結果を結びつけるのが難しくなる ⑥ タスク切り替えの無駄 ：コンテキストスイッチが発生すること ⑦ 欠陥の無駄 ：システムのヘルニア。 バグを前提にして、それに依存したコードを書いてしまう 15 プロセスのムダを７つの観点で整理。 どれも見に覚えのあることばかりではないでしょうか。 このページだけでディスカッションできそうです（笑）
- 18. こめちゃん @kome 1分 Doneの定義 なにが出来たら完了なのかを決める チームとして定めた「出荷可能な製品」を作成するために実施しなければいけないこと。 例えば、コードを書く、ユニットテストする、統合テストをする、リリースノートを書く、 など。 フィーチャー単位でのDoneの定義、スプリント単位でのDoneの定義、リリース単位 でのDoneの定義をすることを推奨。 Doneの定義はチームの成熟度や時間によって変わって いくが、Doneの定義なくしてのScrumはあり得ない。 17 Doneの定義のサンプル(1) | Ryuzee.com http://www.ryuzee.com/contents/blog/3285 タスクかんばんを始めるときは、必ず一緒に決めておく。 ぶーすかの運営でもタスクかんばんを取り組んでいますが 同じ問題が発生しました。
- 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分 チケット駆動開発（ＴｉＤＤ）とは？ チケット駆動開発 (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. ＴｉＤＤの３つのメリット 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(なぜ)を １行だけ書けば十分かと。 WHYを書けば、前回と同じコメントになることはないはず。
- 26. チケット駆動の注意点 チケット駆動を始めると、チケットが飛び交うようになります。 「レビューお願いします」「対応をお願いします」 でも、職場はしーーーーーん。 リアルに会話している人がいない！？ 25
- 28. こめちゃん @kome 1分 ほかにも注意すべきこと チケットを出す人と処理する人のコミュニケーションが 密に取れていれば良いのですが、そうでない場合、 そのタスクや機能が本当に必要か、必要な場合でもそのタイミングで必要か どうか、ちゃんと精査されていないチケットを発行したり処理することにな ります。 チケット発行側とチケット処理側の関係が浅かったり、 コミュニケーションの距離があったりすると、 チケットを簡単に却下することもできなくなります。 都度ミーティングして対立した意見を出すくらいなら さっさとチケットクローズさせる、みたいな流れになると、 不毛な作業をすることになったり、 もしくは無駄なチケット放置してカオスな状態になったりします。 27 いいことばかりじゃない。 あくまで手法（ツール）なので、使い方次第で悪化する危険も。
- 29. 28
- 30. GTDとは？ 頭の中の「気になること」をすべて頭の外に出す ① 気になることすべてを１箇所に「収集」する。 ② それぞれの意味と何をすべきかを明らかにする 「処理」を行う。 ③ その「処理」の結果を「整理」する。 ④ それらの行動の選択肢を「レビュー」する ⑤ 選んだ行動を「実行する」 29 GTD（Getting Things Done、ゲッティング・シングス・ダン）とは 個人用のワークフローの管理手法である。 ハッカー文化の一つで、LifeHack（ライフハック）の中でも代表的なものである
- 32. 努力なく続けられる仕組みをつくる 習慣化するためには、努力なく続けられる仕組みをつくる。 信頼できるシステムを利用して、定期的に見直す。 私が信頼できるシステム 移動中や待ち時間など、”ふとした時”にでも見直したり足したりできる ようにスマフォアプリが用意されているシステムを利用する。 －Redmine ・・・プロジェクトでの実務タスクの管理。 －Trello ・・・ぶーすかの運営タスクの管理。 －Wunderlist ・・・プライベートのタスクの管理。 私の習慣化までにかかる期間 習慣化のステップを意識し、「意識的にやる」⇒「無意識にやる」になる ように根気よく続ける（すくなくとも２ヶ月続ける） 31
- 34. 約束を破らないための３つの選択肢 1. 約束をしない 約束を守れなかったときの代償がわかってくるにつれ、 どの約束をすべきか、頭の外に追い出すものを意識して選ぶようになる。 「仕事を具体的にリストアップしておけば、自信を持ってNOと言えるようになる」 2. 約束を果たす ２分で出来ることなら直ちに終わらせよう 簡単にできることから片付けて、自信をつけていこう 「やるというプレッシャーから逃れ、やったという平安を得よう」 3. 約束を見直す 約束自体を思い出せなければ、それを見直すことも出来ない 常に嫌な気分を抱き続けることになる 33
- 36. 35
- 37. 36
- 41. みなさんへ質問 ① チームタスクの見える化（かんばん）ってやってますか？ ＷＢＳにない細かなタスクの見える化は？ 課題に感じていることはありますか？ ② 個人のタスク管理はどうやってますか？ チームではなく、個人ではどんなやり方？ プライベートや日々の作業など忘れない工夫は？ 40 あとで教えてください
- 42. 41