BacklogWorld/アジャイル開発とプロジェクト管理ツールの相性
@yohhatu
ギルドワークス、エナジャイル
現場コーチ/アジャイルコーチ
ギルドワークス
2014年に創業
仮説検証型のサービス企画や開発、現場改善する現場コーチなどでクライアントの事業を推進する
現場コーチとは?
現場に行ってコーチングをする
「正しいものを正しくつくる」現場を増やす
42チームに関わってる
プロジェクト管理ツール
デジタルなITS=Issue Tracking Systemを指す
BacklogとかJIRAとか
プロジェクトの特性
不確実性の高い領域
グループではなくチームで進む
アジャイルに進めるのが良さそう
例えば「北京ダックを作る」というプロジェクト
GoogleとかCookpadで作れるけど
煩雑だけど確実性が高い(ベストプラクティスがある)
チームでやる必要もない
割り当てだけやれば動ける
というプロジェクトではないものを取り扱う
"Agile"とは?
「素早い、身軽な、機敏な、頭の回転が速い」
「活発な・いきいきとした」
という感じならアジャイル
アジャイルソフトウェア開発宣言
プロセスやツールよりも、個人と対話を
包括的なドキュメントよりも動くソフトウェアを
契約交渉よりも顧客との協調を
計画に従うより変化への対応を
「アジャイルはドキュメント要らないんでしょ?」「計画ないんでしょ?」は間違ってる
意味のあるドキュメント作りましょう
大枠の計画はちゃんと作る
手元は作るがそこから先は再計画する
とか
宣言の背後にある原則12個
顧客満足を最優先する
都合とかではなく
変化を味方につける
競合他社の動向とかも取り入れて再計画していく
影響を小さくしていくとか
数ヶ月に1度のリリース日を固定しちゃうとかはやらない
遅くても2週間に1回
ビジネス側と開発者は日々一緒に働く
顔をあわせて働く
プロとしてお互いを信頼する
意欲に満ちた人々を集める
環境と支援を与える
動くソフトウェアことが進捗の最も重要な尺度
ウォーターフォールだとたまにWFとかできました、が意味なくなっちゃったりする
アジャイルは持続可能な開発を促進する
技術卓越性と優れた設計に対する不断の注意が機敏さを高めます
シンプルさが本質
無駄なく作れる量を最大限にすること
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます
誰かが指示するとかではなく
自分たちで実験を繰り返していく
自分たちのやり方を最適に調整します
自分たちの効率的に働ける方法を定期的に振り返る
2012年のアジャイルの平鍋さんの図
ゴール:顧客満足・市場創造
物をつくるのがゴールではない
協働でゴールに向かう「チーム環境」
高速に石橋を叩いて渡る「開発環境」
https://gyazo.com/df4b8576b96c4e9398f49606fa12bf7c
代表的なアジャイルな開発のやり方
エクストリームプログラミング
スクラム
リーンソフトウェア開発
われわれはなぜアジャイルに向かうのか
市谷聡啓
アジャイル宣言の背後にあるプロジェクト管理ツール
変化に対応
やってみて分かることがある
作るという視座ではなく作ったものがどう役立つかの視座
「以前こう言っていました」では変化を味方につけることはできない
目的に忠誠を誓う
アジャイルサムライに出てる方法
プロジェクトの全体像
異なる役割の人々の間でプロジェクトに対する共通認識を作る
10個のタフクエスチョン
関係者全員で
1デッキ60〜90分
1回やって終わりではない、作って終わりでもない
全員同席
お互いの得意技を活かして目的に向かう
どっちが上とかは無い
お互いのことを知ることで関係性が構築され、チームとなっていく
物理的な距離や掛け持ちによる濃度の低下
形成期・混乱期・統一期・機能期
知らない・衝突・安定・目標に向かう
よく知らない段階で人を入れたり分解したりすると混乱する
自分は何が得意か
どういう風に仕事をするか
大切に思う価値はなにか?
メンバは自分にどんな成果を期待していると思うか
顔をあわせての対話
会話することで他の情報も入ってくる
見える化することで同じ情報をインプットにして話し合う
推測で話すことはムダ
「チケットに書いてあるから見ておいてね」もムダになる
アナログでお互い話せるようになってからデジタルを使う
動くソフトウェアが重要
動くもので状況を判断する
受入条件とそれを実現するための計画づくり
「チケットはだいたい終わっています」「一部が終わって80%です」は意味がない
「あと2時間」とかならまだ意味があるけど
振り返りと改善
前提を置かないでもっとうまくできるやり方を実験していく
説明責任と改善責任
デジタルツールの制限を制約に置いてしまい、最適なやり方にするのを妨げる
まとめ
プロジェクト管理ツールを使うだけで良い仕事ができるわけではない
プロジェクト管理ツールを使うなら、使いながら自分達の仕事のやり方を実験する
時にはプロジェクト管理ツールを捨てる選択も必要