アジャイル開発お悩み相談会 vol.5 質問と回答

Transcript

1. 当日出た質問 アジャイル開発 全般についての 感じている課題 があればご記載 ください 2024/02/14 ～メトリクス何をどう使う? ～ 回答 メトリクスを見てどこに課題があるか 分析するときに、どういった観点で見 ているのかとか、メトリクスの中でこ の指標は必ず確認するとか、何か気を 付けていることがあれば教えてくださ い! メトリクスのインプットとし て、どのようなデータを収集 するか。データ収集にあたり 入力が苦にならない工夫は何 かあるか。 ウォーターフォール型開発の 品質指標の考え方から脱却で きない。または、それを上か ら求められたときにどう説明 したらよいのか知りたい。 メトリクスをとる目的・メトリクスによって変えてます。 よくとるであろうメトリクスの具体例の1 つを挙げると、 ベロシティの場合、複数スプリントで安定しているか（安定傾向に あるか）に着目して見ています。 ① 上がることを目指すこともあります。一方、あくまで見積もりは 相対的なもののため、見積もりのインフレという悪影響をおよぼす 可能性もあるので、重視しすぎないようにはするかも。 ② 不安定な場合、バックログの粒度が大きすぎる、プロセスのどこ かが安定していない、差し込みが多いなど、の課題がある可能性を 考えます。何が課題かは、その他の定量的・定性的な状況も踏まえ て考えます Four Keys が最近注目されている と思いますが、実際にこれ をどんなPJ で使っていて、 どんな良い効果があったか 事例を教えてください。 私の場合、メトリクスとるために新たに入力してもらうことはあま りないかもしれません。 すでにあるデータをどうやって加工、算出するかに苦戦している方 が多いです>< 現状は、 ・既存のツールやプラグインでとれるものはそのまま使う ・Excel の関数使ったテンプレート作ることで少し手間削減 ・あとはパワープレイで... という感じです もっとコード書けるようになって自動化・ラクしたいです 上の方は、その品質指標から、何をし たいのか、何に使いたいのか聞いてみ る。 代わりにこういうことで明らかにでき ると思いますがどうですかねーって投 げてみる あと、質問者の方自体 が脱却できずに困って いることが気になりま す 明日から使えるメトリクス アジャイル開発の 中で、プロダクト 品質はどういった メトリクスを取れ ば良いのか。 とはいえ、制約上、 必要ってなった指標 はとれるようにする メトリクスを取ることは重要だと 思いますが、開発チームに負荷な く取る工夫が必要だと思います。 その良い事例を教えてください。 【補足】詳細タスク 別に時間入力させて 、分析に活用する系 の入力負荷が高いの かな? と思います。こ れってあまりやらな いのですかね? メトリクスを見てどこに課題があるか 分析するときに、どういった観点で見 ているのかとか、メトリクスの中でこ の指標は必ず確認するとか、何か気を 付けていることがあれば教えてくださ い! そもそもプロセス面は見える 化のため。順調かどうかわか る、順調じゃなかったら対応 する、と「みればわかるじゃ ん」となること メトリクスをとる目的・メトリクスによって変えてます。 よくとるであろうメトリクスの具体例の1 つを挙げると、 ベロシティの場合、複数スプリントで安定しているか（安定傾向に あるか）に着目して見ています。 ① 上がることを目指すこともあります。一方、あくまで見積もりは 相対的なもののため、見積もりのインフレという悪影響をおよぼす 可能性もあるので、重視しすぎないようにはするかも。 ② 不安定な場合、バックログの粒度が大きすぎる、プロセスのどこ かが安定していない、差し込みが多いなど、の課題がある可能性を 考えます。何が課題かは、その他の定量的・定性的な状況も踏まえ て考えます 実体験として、 ちゃんと取って いるPJ いたこと ない、、、 ×2 きっちりとれてるチームは そうそうないかな、、、ま ずちゃんとスプリント毎に リリースできているチーム が少ない。そこまで出来て たらデプロイあげたい、と つながるので成熟したチー ムが使うものとして、かな ぁ 安定性は見 ているとこ ろはあるか も知れない リードタイム（JIR A のコントロール チャートとか）は ふりかえりのとき 見て、外れ値があ れば議論する JIRA から勝手にとれ るものを活用しかし ていないので、負荷 かかっていないとこ ろしかできていない かも・・・　むしろ ＋α おしえてほしい！ JIRA から勝手にとれ るものを活用しかし ていないので、負荷 かかっていないとこ ろしかできていない かも・・・　むしろ ＋α おしえてほしい！ 開発チームに新しい ものをとってもらう 、は出来るだけしな いようにして、すで にあるものをどう加 工するか？をまず考 えている。 加工とか出せるもの はSM ががんばってる 。自動化まで出来れ ばベストだけど。コ ピペぐらいで出来る までの工夫とかはし ていたりする。 開発チームに新しい ものをとってもらう 、は出来るだけしな いようにして、すで にあるものをどう加 工するか？をまず考 えている。 ↑ のとおり。付け加え ると習慣化が大切。 それが当たり前だよ ね、という認識をし てもらう。 理屈からではなく、ある程 度有無を言わさずまず体験 してもらって、これがある と役に立つよね、とか自分 たちを守るためにいいよね 、とかメリットを感じても らう→ このためにＳＭが事 前準備しておく必要はある Chrome のJira の拡 張機能もあります が、チームで使っ て効果がありそう なものはあります か? Jira でデプロイ頻度が分かる という話がありましたが、Ji ra 側ではアプリがデプロイ されたことはどのように把 握できるのでしょうか?GitH ub Actions やCodePipeline など と連携する形でしょうか? なんの分析につ かうのか？が気 になった。ここ の内容次第かも 。 その通りです。ど んな作業にどれだ け実時間がかかっ ているかを知りた いです。 予実管理をした い、ところでそ のためにやって いるチームもあ った 不満におもって るかもだけどト ップダウン的に やってた そんな重要なの？と もおもう。スプリン ト終わったときに価 値がでているかにフ ォーカスしたほうが いいのではないか。 というのも、人をいかに 効率よく「働かせるか？ 」になってる気がするの がどうかな、とおもう。 総量としてどうかな？を みていったほうがいいと おもうんだけどなー むしろ、スプリ ントでやるとき めたことが出来 ているのか、を 重視する やべ、Chro me 拡張つか ってないや ｗ プラグインなら。正式名称 わすれたんですが、チャー トの上位互換的なものがあ る。レポートのベロシティ が標準であるけど、そこを カスタマイズできる（JQL で 絞ってラベルがついたもの だけにするとか、3 スプリン トの移動平均出せるとか） 職場でのアジャイル開発の導入が 初めてです。アジャイルのため、 仕様変更が入ると作成したコード やデータベースの変更も発生する ため、開発メンバーのモチベーシ ョンが少し下がります。変更を前 向きに捉えるために心がけている こと(PO やSM) などありますか? リードタイムがわかる＝ コントロールチャートは JIRA でみれるけど、デプ ロイ頻度はJIRA では連携 しないと、、、（ごめん なさい、たぶんです） アジャイル開発の導入にあ たり、品質管理部門への説 明に苦労しています。プロ ダクトの品質が十分に満た せている( 過剰な品質ではな い) ことを示すために、どの ような説明や取り組みをし ていますか? POC 段階での品質 保証を求められて います。リリース 前に品質を上げる 活動は何かありま すか? お客様にスクラム マスターの活動成 果をアピールした い場合に有効なメ トリクスがあれば 教えてください。 ここらへん参考になるかも... ？ https://support.atlassian.com/ja/ jira-​ software-​ cloud/docs/view-​ and-​ understand-​ your-​ deployment-​ frequency-​ report/ 同じように思った ！　はじめは面倒 、手間とやはり聞 く。成功例を早め に体験できるとい いのかも。 （SM がとくに）何か追 加されれば何か落ちる、 ということを周りに見え るようにしてコミュニケ ーションをしっかりとれ るような雰囲気にしてい くことが大切。 技術的な面では、変 化・追加に強い構造 にするためにリファ クタリングをタスク として組み込んでお くようにしておくこ とも大切 私もめっちゃ悩んでる！ スクラムをやったからと いって生産性はいきなり あがらないよ。でも早く 課題は見つかる。これが 感謝してくれるところに なる。早いほど打てる手 も多いし手段も多い。 問題がありましたというよ うなメトリクスは・・・？ → 毎スプリント物をだして フィードバックをえる、と か、チームから問題だ、と 上がった数とか。些細なこ とでもいいのでその動きを キャッチすること 今までの経験で使 って良かったなと 思えた具体的なメ トリクスを教えて ください。 どれだけFB をもら ったか？とか、チ ームからあがった 不安の数、とかを KPI としてもいいか も 品質管理部門の方 かぁ、、、どこを 気にされているの か？を深堀するか なぁ、、、 リリースの判断と して数値がほしい のか、とか。それ を聞いた上で出せ そうな数値の提案 をするかも アジャイル開発では リリースのときに品 質担保されているは ず。つまり、完成の 定義を一緒に考えて おくというのが一つ の手 品質管理部門の方 は従来のPJ 、アジ ャイルは別で、と 割り切ってもらう ように組織に働き かける まず、人として仲良 くしましょう。その うえで、アジャイル の品質管理指標とか そういうのを一緒に つくりましょうよ、 で一緒につくった。 このツールを使う と、こんなメトリ クスが取れて便利 だよという事例で もOK です。 メトリクスをベロシティで設定し ていた時、安定しないことがよく ありました。。 案件上、定期的に新しくやるタス クがバックログとして入っていた こともあり見積もり精度があまり よくなかったことが原因だったと 思うのですが、 皆さんはインフレしないor 見積も り精度を上げるために何か気を付 けていることってありますか? 最終的にスプリン トレビューに一緒 にでてきてもらっ て完了、にできれ ばいいよね！ POC なのに ？？？と思 ったりする けどw そもそもリリース前に急に 品質あげるというのは無理 だと思う。使ってもらうた めにプロダクトって始まっ ていると思うので作るとき から必要な品質ってなに？ という会話をして作りこん でおく POC が作り捨てなら品質 はいらないと思うけど、 AB テストをしたいなら 当然リリースレベルの品 質いるので通常と同じよ うに対応するしかない。 何かあったときにロール バックできるとか、問題 を検知できるとかも大切 。普段から品質を意識し て（ユニットテスト、自 動テスト、CI/CD とか） おく まずはベロシテ ィ！　バーンダ ウンを毎日みて チームの状況を みる！× ２ 何がよかったかというと 、チームで次のスプリン トの予測を立てるのに自 分たちでちゃんと出来る ようになっている。その よりどころとして安心し て進められた！ 基本は↑ と一緒。それが 基本だけどまず そこが出来てい ることが大切。 にこにこカレンダ ーとかチームの状 況（いかに楽しく とか）がわかるよ うなメトリクスも 重要！ さらにいうと、プロセス 面じゃなくてPO として サービス面（どれぐらい のユーザ数とか）そうい うプロダクトのKPI は考 えて取得していくことも 大切 ゼファースケールという 管理ツール。これを使う とどれぐらいテストとし て成功・失敗とか見れる 。さらに不具合率とかも 自動で見れるのが良き。 JIRA とも連携可能！ CAT よりも？→ うーん、CAT 使 ったことないか らなんともいえ ないかも・・・ zephyr scale 基本的にJIRA 標準 やはり使えるかも 。あとはPowerAut omate とか使って たりするよ！ JIRA のAPI からどうの こうの、ということ もできるよ！　まず はJIRA 標準ｄでもう 一歩やりたいなぁ、 がでてきてからで十 分ではないか GAS+Looker studio で可視化とか 、聞いたことはあり ます https://cloud.google. com/looker-​ studio?​ hl=ja まずは基本（ベロシ ティ）から。数値化 できないとカイゼン できないので。自分 たちどれだけできる ？という現在地の把 握が大切。 （どう使えばいい？ ）現在地なので、そ の数値を基準に全部 やるといつ終わるの か？を見える化すれ ばよい。無理に上げ ていく必要はない。 （そのほか 意識してい ることあり ますか？） メトリクスをとる目的・メトリクスによって変えてます。 よくとるであろうメトリクスの具体例の1 つを挙げると、 ベロシティの場合、複数スプリントで安定しているか（安定傾向に あるか）に着目して見ています。 ① 上がることを目指すこともあります。一方、あくまで見積もりは 相対的なもののため、見積もりのインフレという悪影響をおよぼす 可能性もあるので、重視しすぎないようにはするかも。 ② 不安定な場合、バックログの粒度が大きすぎる、プロセスのどこ かが安定していない、差し込みが多いなど、の課題がある可能性を 考えます。何が課題かは、その他の定量的・定性的な状況も踏まえ て考えます まず安定に関して は、準備不足をな くすことを意識す る。つまり、Read y になっているか？ をしっかりする。 見積精度をあげる には、できるだけ 小さくわける。大 きくても13 まで。 分割して一桁にな るまでやる。 全部1 とかまで小さ くしすぎない。一 桁ぐらい。そこま で細かい作業であ ればサブタスクと したい。 不具合率、不具 合の原因分布（ どういう理由が 多いとか） 自動化環境をつく って常にグリーン だよ、と正常系を 絶対担保している ぜ！を示すことか も 補足： スプリントごと or Epic 単位でとって 、推移をみるよう にしてます