22【NE-WG】看板でスクラム検証してみたいGitHubスクラムzenhub目的スクラム使って看板使うとどうなるのか検証してみたい。使うツールが職場じゃ使えない?使えるようにしてください(;_;)。最近色々言われすぎてなんだかもう精神的に辛すぎ諦めモード。ZenHubについて超簡単に説明すれば、GitHubの看板(Project)機能の強化版です。GitHubに慣れている場合は看板機能でスクラムやる場合ZenHubがかなりおすすめ。導入方法もこちらのサイト見たくGitHubにプラグ繋げるだけという滅茶苦茶簡単なのが取り柄。地獄しか見ない態々複雑化された環境構築なんて御免です。やってみよう!職場や諸事情がカオスすぎるので毎日運用できるかカオスですがとにかくやってみる。新規案件来ました(仮)!とにかく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機能のガントチャート(進捗)作成でものすごく効力を発揮します。看板形式はデフォで良いと思います。一応カラムの簡単説明。新しいタスクを突っ込む。割り込みタスクとか入れる。優先度高いストーリーやタスクを突っ込む。1スプリントで出来ない量を入れないこと。優先度低いものを突っ込む。ここが溢れるのは問題なし。終わったり聞いたりしたいものはここに投げる。技術力が高い開発者は誰がやる云々問わず、できる限り早めに応答して撤去する。ここを溢れさせるのはNG。レビュー完了したら入れます。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分最大です。グータラやっても何も進みません。up!看板で、今日の進捗はこんな感じになったようです。看板があるので情報が流れてこなくてもある程度の現状はわかります。本来は複数の方が業務進めてるのでタスクはもっと沢山貼られます。フィルター機能が充実しているので誰が何のタスクをやっているとかわかります。今回は、初めから全部私にタスクを振っていますが...実際は当日の朝会でじゃこれ私〜とかが定番だと思います。人によってスピードが違いますし精度も異なります。無茶に仕事を押し付けて爆死させるより自ら取る形の方がうまく運用できると思います。1ユーザストーリーにおけるタスクの進捗状況も見ることができます。これだけだと、進んでいるか遅れているかは曖昧ですがそこらへんは後ほどのグラフを見ればすぐにわかります。WHの名残りみたいですね。flowここからZenHubの腕の見せ所。現状のタスクの運用状況がパパッと見れます。うんうん、IceBoxにあったタスクが処理され始め、現状のタスクが減ったことがわかります。見て分かる通り、現状どれくらいタスクが終わっているのかわかります。これを見れば実際はもうすでに遅れていることがわかるんですよね〜。気づいたらカオスになっていたを防げます。今回のシミュレーションではもっとWHでやったら即死するレベルでカオスにする予定です。他の表は統計が少ないためまだ表示が特に何もないので飛ばします。開発者の話によると、一部のタスク量が予想より大幅に多かったりバグが酷かったためタスクを急遽増やしたみたいですね。看板もともとA->B運用がバグ云々で逆転したり、先にやってしまおうと目標日付からずれたりとカオスになりつつあります。今回は見やすさ重視のため日付も記載していますが、こんな感じで日付通りにいかないのは当たり前なのであくまで目標であって絶対にしてはいけません。日付ではなくEstimate機能を使って、「◯数字」におおよその処理時間を書くのもありです(UserStory(Epic)はストーリーポイントを意味しているのでまた別物ですけどね〜)。1日8Hであることとチームの効率も測定しているため、稼働を下手にあげるとチームの正しい生産性がわからなくなります。1ユーザストーリーにおけるタスクの進捗状況は以下の通りですね。flowタスクを処理していますが、全体タスクは増える一方ですね。ユーザーストーリーが何も終わらないでリリースはNGなので、やはり今回は週2のストーリーは無理かもです。chart1日あたりのチームの生産性が測定できます。生産性は上がっているようですね。report処理スピードはあがれどタスクが増えて話にならない状態です。今日はここまで、まだエググします。今日の教訓として、目標は壊れる前提として動きましょう。毎度恒例の追加/変更要件きました。スプリント中のため、やってほしいと言われても無視します。進捗は変動があったものみで。看板1ユーザストーリーにおけるタスクの進捗状況です。こっちはリリースできるまで持って行きました。片方は状況に応じて決めましょう。優先順位はAに比べ低めのはずなので無理なものは無理とします。report今日は問題もなく進んだので余裕が出来始めました。スプリント中は余計なタスクが来たら全て保留なり何なりでRejectしてしまうのがSMの役目です。5日目スプリント中はスプリント以外の仕事はしないが定番ですが、システム障害らしく緊急対応追加です。緊急対応とかが発生するとやるべきことが出来なくなります。最低限スプリントの後には何かしらリリースが必須なので出来るだけユーザーストーリーは小さめにし、余計な弊害が来てもじゃあこれは捨てるねーとできるようにしたほうが良いです。Aのユーザーストーリーはリリース準備まですることがないのでタスクの進捗は以降記載を略します。本来はSWや開発者は常に確認するべきです。flow減っても増える悪循環。WHでも基本はこうなりますね・・・。Issuesの違いがわからない・・・。report見てわかる通りバグ修正とか入ったこともあり、目標に達しそうにありません。最低限のリリース資産は出来ているのでそれは問題ないです。この結果をKPT等を生かして反省し、次回のスプリントに生かすことがスクラムの重要性になります。無事リリース作業完了しましたー!これからKPTを実施です。今回は擬似で実施しただけなので反省らしい反省はしませんが、ZenHubで取れた統計は次回のスプリント計画等で物凄く役立ちます。この結果を生かし、POやSMと連携をして次回のスプリント量を決めます。flow看板の動きが表になっています。見積もりに対し終わらないのは大抵タスクの増加(思うようにできない)や追加注文が原因です。この表にもある程度見受けられます。それを前提にスケジュール組めとかWH古参勢は言っていますが、それで組むと見積もり甘すぎでrejectされて終了がブラック帝石です。ZenHubはそこらへんへの打開策が強くなっています。chartこれを見れば、チーム内での大体の処理速度がわかります。英語なんてよくわからなくても雰囲気である程度わかっちゃうのがGitHubなりZenHubなりの凄いところです。今回はまだ初動なのでブレは激しいですが、1-2ヶ月もすれば大体安定します。reportこの子はスクラム中の進捗で効力を発揮したことが良くよくわかったと思います。チームにバカみたいに残業させてこのグラフでの仕事減少量を増やしてもメリットはありません。志位が落ちるだけです。仕事支援ツールを間違った使い方で運用しないでください。この一週間ほぼ毎日深夜2時までかけてこの資料を作っていた私が言う発言ではないと思いますが・・・。tracking今までは機能していなかったツールですが1スプリント(1milestone)が終わると機能が開始されます。1スプリント(1milestone)で出来たタスク量を見ることができます。次回のスプリント計画におけるタスク割付時に役立ちますし、チームの生産性の向上も見ることができます。私は個々の技術力にはあまり興味ありません。report同じく1スプリントが終わったのでその結果が反映され始めました。スプリントではなく最終リリース日までに対する現状の進捗が表示されます。本来だったら2週間で余裕だったはずなのに余計なタスクがガンガン来ていて収集つかなくなったのが目に取れます。ZenHubではそういった余計なタスクがいつ何時に存在したのかが結構簡単に見ることができます。その結果終わるのか終わらないのかも瞬殺です。ゼーハー言いながら仕事している開発者に進捗正しく報告しろと言うだけで鬼だと思います。ZenHub等の機能を正しく使えば、開発者は看板を使って自身のタスクを見やすく管理し、管理者は統計結果から今後どうすれば良いのか瞬時に判断できます。スクラムで言うならば、全員で次回のスプリント計画を立てるときにこれだけの材料が整えばかなり安定したスクラム計画も立てれるはずです。upLoginユーザーは見つかりませんでした。