目的
スクラム使って看板使うとどうなるのか検証してみたい。使うツールが職場じゃ使えない？使えるようにしてください(;_;)。最近色々言われすぎてなんだかもう精神的に辛すぎ諦めモード。
ZenHubについて
超簡単に説明すれば、GitHubの看板(Project)機能の強化版です。GitHubに慣れている場合は看板機能でスクラムやる場合ZenHubがかなりおすすめ。機能が似てます〜。
導入方法もこちらのサイト見たくGitHubにプラグ繋げるだけという滅茶苦茶簡単なのが取り柄。地獄しか見ない態々複雑化された環境構築なんて御免です。
とりあえずやってみよう！
職場や諸事情がカオスすぎるので毎日運用できるかカオスですがとにかくやってみる。
1日目
Repository作成
新規案件来ました(仮)！とにかくRepository立てます。今回は1週間プロジェクトですが、実際プロジェクト自体は何週間も続きます。
GitHubって以下のタブで大抵何を設定するべきかは教えてくれます。まあ、実際はこれだけだと全然足りませんが初心の内はこれだけで十分だと思います。今回はGit講座ではないのでほとんど割愛。
まあ、雑ですがこんな形でRepository完成です。実際はシステムのコードやらLFSやら色々突っ込むのですが今回はGit講座ではないので...(ry。
案件整理
さて、クライアント側から色々注文来ました。全部ユーザーストーリーとして突っ込みましょう。面倒臭いので内容は雑です。
内容一例
だいたい、客の注文内容、何で必要か、このユーザーストーリーをcloseするための条件を書いておけば十分です。内容が明らかに多すぎたり重すぎるものはユーザーストーリーをさらに分割します。多すぎや重たすぎを定義するのは客(PO)でもなくリーダー(SM)でもなく実際に開発する開発者です(←ここ重要)。勿論前提は全員で話し合いをして云々決めるのですが詳細をかくとカオスになるので割愛します。
案件一覧
今回の結果こうなりました。はい、どう見ても1週間で終わらせる内容ではないので残りは来週(今回はやらない)として放置です。あ？客がうるさい？知らん。客が神の時代はとうに終わってる。何故ブラック推奨企業(案件)に技術者が手を貸す必要性があるのか未だに疑問。
看板作成
GitHubにもProjectという看板はありますが、ここでは先ほど少々説明した通りZenHubを使います。使い方等は色々略します。
ZenHubの設定画面です。ZenHubの看板は1Repositoryにつき1つまでの設定になります。GitHubの看板は1Projectに1看板に対し、ZenHubは1看板につき複数のProjectを突っ込む形です。一見複雑に見えますが、フィルター機能で表示内容を絞れますし...ZenHub機能のガントチャート(進捗)作成でものすごく効力を発揮します。
看板形式はデフォで良いと思います。一応カラムの簡単説明。
| カラム名 | 簡易説明 |
|---|---|
| New Issues | 新しいタスクを突っ込む。 割り込みタスクとか入れる。 |
| IceBox | 優先度高いストーリーやタスクを突っ込む。 1スプリントで出来ない量を入れないこと。 |
| Backlog | 優先度低いものを突っ込む。 ここが溢れるのは問題なし。 |
| In Progress | 着手中。 |
| Review/QA | 終わったり聞いたりしたいものはここに投げる。 技術力が高い開発者は誰がやる云々問わず、 できる限り早めに応答して撤去する。 ここを溢れさせるのはNG。 |
| Done | レビュー完了したら入れます。 closedにするか否かは周りと要相談。 |
| closed | そのタスクが終わればclosedです。 |
個人的に割り込みPO対応はSMが実施して技術的QA等は開発者同士で片付けるイメージ。どうしても会議が必要なら、IceBoxの量は減らす必要性あり。1週間は40H(雑務時間含む)を忘れてはいけない。
こんな感じで出来上がる。
Milestone設定
1スプリントの期間設定と思ってください。こんな感じです。
Release設定
GitHubで言うところのProject機能もどきがこれになります。
ストーリー移動と設定
まず今週やるものとやらないものを分けてみる。
あと、ZenHubを使うことにより各々のユーザーストーリーにも設定できるようになるので設定してみる。
UseStoryはタスクの中のグループ見たいなものなのでepicにしています。
あと、BよりA優先なのでBはAによってブロックさせたり...1UserStoryの重さを設定できたりできます。
あ、UserStory(Epic)は上画面の右タブのEpicsを設定する必要性はありません(自身がEpicsですからね〜)。代わりにReleasesはちゃんと設定しましょう。
設定が終わると看板は以下のようになります。
△!は最優先、♢!や禁止マークはこのIssuesやる前にするIssuesあるだろと言うことを訴えています。
タスク設定
UserStoryが片付いたらいよいよタスクを分けていきます。勿論話し合いの上で決めます。今回は決まったことを貼るだけですが。当然ですが、今週やらないUserStoryはタスク作りません。
まずはタスクを作りましょう。
諸注意として、タスクはUserStory(Epic)に紐付きます。Releaseには紐付きません。なので、タスクはEpicsに設定して、Releaseは設定してはいけません！
最終的に看板はこんな感じに〜。
これが終われば開発開始です。ね？Sprint初日なにもできないでしょ？
進捗確認
まだ、始まっていませんがこれだけで知らないうちにバーンダウンチャート等の骨格が出来始めています。
例えば、UserStoryの進捗状況はこんな感じに。
Milestone(1スプリント)の進捗状況はこんな感じに。
Release(1プロジェクト)の進捗はこんな感じです。
他にもありますが、他のは実際にやって見た結果というようなものですので現状は作られていません。まあ、これはあくまで私ならこうすると言ったものですので実際の運用は多少臨機応変になるかと・・・。私だってまだ検証中なんです。今後運用を変えるかもしれませんし。
2日目
では実際に運用開始。朝会は15分最大です。グータラやっても何も進みません。ぱっぱと終わらせたければ全員stand up!
看板
で、今日の進捗はこんな感じになったようです。看板があるので情報が流れてこなくてもある程度の現状はわかります。
もちろん本来は複数の方が業務進めてるのでタスクはもっと沢山貼られます。ただ、フィルター機能が充実しているので誰が何のタスクをやっているとかわかります。
今回は、初めから全部私にタスクを振っていますが…実際は当日の朝会でじゃこれ私〜とかが定番だと思います。人によってスピードが違いますし精度も異なります。無茶に仕事を押し付けて爆死させるより自ら取る形の方がうまく運用できると思います。
さらに1ユーザストーリーにおけるタスクの進捗状況も見ることができます。
これだけだと、進んでいるか遅れているかは曖昧ですがそこらへんは後ほどのグラフを見ればすぐにわかります。WHの名残りみたいですね。
Cumulative flow
ここからZenHubの腕の見せ所。現状のタスクの運用状況がパパッと見れます。まずはCumulative flow。
うんうん、IceBoxにあったタスクが処理され始め、現状のタスクが減ったことがわかります。
Burndown report
次にBurndown reportです。
見て分かる通り、現状どれくらいタスクが終わっているのかわかります。これを見れば実際はもうすでに遅れていることがわかるんですよね〜。気づいたらカオスになっていたを防げます。今回のシミュレーションではもっとWHでやったら即死するレベルでカオスにする予定です。
他の表は統計が少ないためまだ表示が特に何もないので飛ばします。では、また明日をお楽しみに。
3日目
開発者の話によると、一部のタスク量が予想より大幅に多かったりバグが酷かったためタスクを急遽増やしたみたいですね。
看板
もともとA->B運用がバグ云々で逆転したり、先にやってしまおうと目標日付からずれたりとカオスになりつつあります。
今回は見やすさ重視のため日付も記載していますが、こんな感じで日付通りにいかないのは当たり前なのであくまで目標であって絶対にしてはいけません。日付ではなくEstimate機能を使って、「◯数字」におおよその処理時間を書くのもありです(UserStory(Epic)はストーリーポイントを意味しているのでまた別物ですけどね〜)。1日8Hであることとチームの効率も測定しているため、稼働を下手にあげるとチームの正しい生産性がわからなくなります。
1ユーザストーリーにおけるタスクの進捗状況は以下の通りですね。
Cumulative flow
タスクを処理していますが、全体タスクは増える一方ですね。ユーザーストーリーが何も終わらないでリリースはNGなので、やはり今回は週2のストーリーは無理かもです。
Control chart
1日あたりのチームの生産性が測定できます。
生産性は上がっているようですね。
Burndown report
処理スピードはあがれどタスクが増えて話にならない状態です。
今日はここまで、まだエググします。今日の教訓として、目標は壊れる前提として動きましょう。
4日目
毎度恒例の追加/変更要件きました。スプリント中のため、やってほしいと言われても無視します。進捗は変動があったものみで。
看板
1ユーザストーリーにおけるタスクの進捗状況です。ようやくこっちはリリースできるまで持って行きました。もう片方は状況に応じて決めましょう。優先順位はAに比べ低めのはずなので無理なものは無理とします。
Burndown report
今日は問題もなく進んだので余裕が出来始めました。スプリント中は余計なタスクが来たら全て保留なり何なりでRejectしてしまうのがSMの役目です。
5日目
スプリント中はスプリント以外の仕事はしないが定番ですが、システム障害らしく緊急対応追加です。
看板
緊急対応とかが発生するとやるべきことが出来なくなります。最低限スプリントの後には何かしらリリースが必須なので出来るだけユーザーストーリーは小さめにし、余計な弊害が来てもじゃあこれは捨てるねーとできるようにしたほうが良いです。
Aのユーザーストーリーはリリース準備まですることがないのでタスクの進捗は以降記載を略します。ただし、本来はSWや開発者は常に確認するべきです。
Cumulative flow
減っても増える悪循環。WHでも基本はこうなりますね・・・。
Control chart
IssueとGrouped Issuesの違いがわからない・・・。
Burndown report
見てわかる通りバグ修正とか入ったこともあり、目標に達しそうにありません。ただ、最低限のリリース資産は出来ているのでそれは問題ないです。
この結果をKPT等を生かして反省し、次回のスプリントに生かすことがスクラムの重要性になります。
6日目
無事リリース作業完了しましたー！これからKPTを実施です。まあ、今回は擬似で実施しただけなので反省らしい反省はしませんが、ZenHubで取れた統計は次回のスプリント計画等で物凄く役立ちます。自動統計は本当に便利ですね。
看板
結構残飯残りましたがこれで良いです。この結果を生かし、POやSMと連携をして次回のスプリント量を決めます。
私の好きな名言の一つ
「小さな子はみんな反省するのにどうして大きい子はしないんだ？」
Cumulative flow
看板の動きが表になっています。見積もりに対し終わらないのは大抵タスクの増加(思うようにできない)や追加注文が原因です。この表にもある程度見受けられます。
じゃあそれを前提にスケジュール組めとかWH古参勢は言っていますが、それで組むと見積もり甘すぎでrejectされて終了がブラック帝石です。ZenHubはそこらへんへの打開策が強くなっています。
Control chart
これを見れば、チーム内での大体の処理速度がわかります。英語なんてよくわからなくても雰囲気である程度わかっちゃうのがGitHubなりZenHubなりの凄いところです。
今回はまだ初動なのでブレは激しいですが、1-2ヶ月もすれば大体安定します。
Burndown report
この子はスクラム中の進捗で効力を発揮したことが良くよくわかったと思います。
仕事は1日8Hです。チームにバカみたいに残業させてこのグラフでの仕事減少量を増やしてもメリットはありません。志位が落ちるだけです。仕事支援ツールを間違った使い方で運用しないでください。
まあ、この一週間ほぼ毎日深夜2時までかけてこの資料を作っていた私が言う発言ではないと思いますが・・・。
Velocity tracking
今までは機能していなかったツールですが1スプリント(1milestone)が終わると機能が開始されます。
1スプリント(1milestone)で出来たタスク量を見ることができます。次回のスプリント計画におけるタスク割付時に役立ちますし、チームの生産性の向上も見ることができます。
私は個々の技術力にはあまり興味ありません。技術力の変化量の方が見ていて面白いと思うのですがどうでしょう？
Release report
同じく1スプリントが終わったのでその結果が反映され始めました。
スプリントではなく最終リリース日までに対する現状の進捗が表示されます。本来だったら2週間で余裕だったはずなのに余計なタスクがガンガン来ていて収集つかなくなったのが目に取れます。
ZenHubではそういった余計なタスクがいつ何時に存在したのかが結構簡単に見ることができます。またその結果終わるのか終わらないのかも瞬殺です。
まとめ
大抵炎上する理由は
多忙化する → 進捗報告・管理がガバ化する → 管理者切れる → チーム間志位低下
→ 進捗偽造が発生 → 収集つかなくなる → ドカーン
ってのが帝石な感じがします。
そして、ゼーハー言いながら仕事している開発者に進捗正しく報告しろと言うだけで鬼だと思います。
ZenHub等の機能を正しく使えば、開発者は看板を使って自身のタスクを見やすく管理し、管理者は統計結果から今後どうすれば良いのか瞬時に判断できます。
スクラムで言うならば、全員で次回のスプリント計画を立てるときにこれだけの材料が整えばかなり安定したスクラム計画も立てれるはずです。
最後に一言、「とりあえずやってみよう！」