タスク管理 -k8凯发

  1. 目的
    1. 過去のタスクを分かりやすくする
      1. これから何年も開発し続けていくのであれば、過去のことを知りたくなることがある
    2. 第三者がどんなタスクをやっているか分かりやすくなる
      1. デジタル化
        1. 付箋以上のことが書ける
        2. いつでもどこでも確認できる
          1. アネックスができても、本社でいつでも確認できる
      2. web
        1. urlを教えればすむ
      3. レビューする人もし易いはず
        1. 確認すべきことを書いておけば
    3. 1つのタスクにどんな変更がされたがわかる
      1. チケットにコミットログを紐付けることができるので
        1. 現状、コミットログだけでは何のタスクのコミットなのかわからない
    4. デメリット
      1. チケットに登録する手間が増える
  2. 方法
    1. githubのissue
      1. メリット
        1. コミットに自動で紐づく
        2. issue同士の紐付けも自動
      2. デリット
        1. 俯瞰しにくい
          1. ラベルでしか分類できない
          2. 誰がどんなタスクをしていてどんな状態なのかが把握しにくい
          3. 複数のリポジトリにまたがったissueを作ることができない
          4. web,ios,androidすべてのタスクをまとめて見れない
      3. 運用案
        1. どんな小さなタスクにもissueをつくる
        2. コミットコメント
          1. 一行目
          2. issue名 ＃issue番号
          3. これで自動にissueにコミットが紐づく
          4. issue名を入れるのはtigやgit logで見た時に分かりやすくするため
          5. 三行目
          6. やったこと
        3. マージしたらclose
          1. マージするときに「fixed #xxx」でクローズする
        4. 大きいタスクはマイルストーンを作って複数のissueに分ける
          1. マイルストーンをストーリーみたいな使い方するかんじ
          2. マイルストーンには日付が設定できる
          3. 計画に対しての進捗が分かりやすくなる
          4. 新機能だからコードレビューはちゃんとやったほうがよい
          5. 細かいタスクに分けてそれぞれレビューするかんじにしたい
          6. 案
          7. マイルストーン用のブランチを作成
          8. タスクは↑のブランチからさらにブランチを切って作業
          9. 終わったらマイルストーンのブランチにプルリクエスト
          10. この時にコードレビュを行う
      4. 考えないといけないこと
        1. ラベル
          1. 案
          2. 新機能
          3. バグ
          4. リファクタリング
          5. 着手中
          6. レビュー中
          7. 緊急
          8. 優先度低
        2. issueにどんなことを書くべきか
          1. 案
          2. タスク
          3. 概要
          4. 詳細
          5. 第三者がみてわかるように(こういう操作をしたらこうなる的な)
          6. 必要に応じて画像があると分かりやすいかも
          7. (あれば)関連するissue
          8. バグ
          9. 概要
          10. 再現手順
          11. ログ
          12. 修正方法
          13. (あれば)関連するissue
        3. プルリク
          1. 基本、最初のマージは1issueに1プルリクになるはず
          2. プルリクエストのタイトルどうする？
          3. 「#xxxのプルリク」とかでよい？
          4. issue名とまったく同じだと紛らわしい
          5. issueをプルリクエストにすることができるけど、この機能は今後廃止するかもなんで使わない方がいいと思ってます
        4. デザインもタスクをissueにしてもらう？
          1. 開発のissueに紐付けることができる
          2. issueにするメリットがあんまりない？
          3. このデザインにした理由とか経緯とかあるとあとで役立つ気もする
        5. 他のツールを使う？
          1. 俯瞰できないというデメリットを解消するため
          2. タスク看板あるから大丈夫かも？
          3. 有料
          4. zenhub
          5. https://www.zenhub.io/
          6. コスト
          7. 30日間無料
          8. 5人まで
          9. ＄25/月
          10. 6人以上
          11. ＄5/人/月
          12. 26人以上
          13. ＄3.75/人/月
          14. メリット
          15. タスク看板的なものをgithubに直接増やせる
          16. chromeの拡張をいれて、githubのホームページを拡張してくれる
          17. サイトを行き来する必要がない
          18. ステータスを追加できる
          19. デメリット
          20. githubの変更に弱そう
          21. githubをchrome拡張でむりやり変えているので
          22. リポジトリごとになってしまう
          23. web、ios全体の俯瞰ができない
          24. huboard
          25. https://huboard.com/
          26. コスト
          27. 14日間無料
          28. organisation課金
          29. $24/月
          30. ユーザ(チームメンバなら)もプロジェクトも制限なし
          31. ユーザ課金
          32. $7/月
          33. メリット
          34. ステータスをラベルで管理
          35. github上でもステータスが分かる
          36. slack連携
          37. 表示するissueにフィルターがかけられる
          38. 別のリポジトリも追加できる
          39. デメリット
          40. ステータスを足せない
          41. カードになるのはコメントのみ
          42. コミットログがみれない
          43. waffle.io
          44. https://waffle.io/
          45. コスト
          46. $7/１user
          47. ただし、現在無料
          48. メリット
          49. タスクの粒度を設定できる
          50. ステータスをラベルで管理
          51. github上でもステータスが分かる
          52. デメリット
          53. リポジトリごとになってしまう
          54. けど、ボードの切り替えは簡単なのでそこまで気にならないかも
          55. カードになるのはコメントのみ
          56. コミットログがみれない
          57. ステータスを足せない
          58. 無料(すでに使っている)
          59. trello
          60. メリット
          61. issueをカードにできる
          62. デジタルなタスク看板が作れる
          63. markdownに対応
          64. 詳細が見やすい
          65. デメリット
          66. 手動でステータスを変更する必要がある
          67. issue作成時にカード作るだけ
          68. 更新はしない
          69. pivotal tracker
          70. issueを自動で登録できない
          71. コミットのみ
          72. 参考
          73. http://qiita.com/androhi/items/4badefa6e6867a853791
        6. ユーザからのフィードバックはissueにしてもらう？
          1. 現在はpivotal
          2. エンジニアがissueに登録しなおすのは二度手間
          3. でもどのリポジトリのissueに登録すればいいのかとか、 フィードバックの内容によってはエンジニアが判断したほうがいいこともあるはず
    2. pivotal tracker
      1. メリット
        1. タスクの粒度が分かりやすい
          1. pointがつけられる
        2. storytypeとlabelで分類できる
        3. コミニティチームが登録しているタスクを流用できる
        4. 俯瞰できる
      2. デメリット
        1. githubとの連携がコミットログのみ
          1. 自動で状態が変わらない
        2. ツールが分散
          1. githubとこれになる
          2. プルリクはissueになってしまう
      3. 運用案
        1. どんな小さなタスクでも必ずpipotalに登録する
        2. タスクをはじめたら「points」を設定する
          1. マージされたら「deliver」する
          2. 本番環境で確認したら「accept」にする
        3. コミットログにタイトルとidを入れる
          1. [#88666894] xxxx
        4. プルリクエストにはpipotalのurlをはりつける
        5. 大きいタスクは複数にわける
          1. それらをまとめるタスクをつくる
          2. tasksにidを書けば紐付けられる
      4. 考える事
        1. デザインのタスクも登録してもらう？
          1. issueの時とおなじ
网站地图