読者です 読者をやめる 読者になる 読者になる

冥冥乃志

ソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。

follow us in feedly

Atlasssian Tools利用のスナップショット

こういうことをやっていました。そのうち、開発のカンバンが欲しくなりWaffle.ioを導入したりしてツールの関係はさらに複雑になってくるのと比例して、情報の同期を取るのがしんどくなってきました。

mao-instantlife.hatenablog.com

それを解消するためにちょっと身銭を切って、Atlassian Toolsを導入して検証しています。2イテレーションほど回して、FeatureMapとWaffle.ioはプロジェクトから切り離して情報の同期も少なくなったので、開発チーム内のみで本格採用しています。

このエントリは、その間で試してみたことや、現時点での運用についてまとめます。

前提

元のツール構成になった理由を整理してみましょう。手作業での同期も辞さなかったのは、プロジェクトに関わる各レイヤー、フェーズによってみたい情報の質と見せ方が変わる、という仮説に基づいていて、それは変わっていません。

各役割

  • FeatureMap => ストーリーの構造化
  • Github + Waffle.io => ストーリーの進捗可視化
  • redmine => プロダクトマネジメントタスクの進捗可視化とビジネスサイドも必要な各種ドキュメントの管理、ロードマップの可視化

問題点

もうそれ以外ないんですが、それぞれのツールが連携していないので、動機を取るのに人間の手作業が必要だということです。特にロードマップの計画のズレなんかがステークホルダーと生じてしまうと目も当てられません。

置き換え

Atlassian User Group 中国地方勉強会中にJIRA向けのアドオンや他の製品を見ていたら、ちょっとの身銭でいけるんじゃないかな、と思うようになってきたので1か月の検証期間を設けてみることにしました。ちなみに、身銭でスターターライセンス買ったのは、会社で本格的に導入する時には新規にライセンス購入してもらって、スターターライセンスは自分のプライベートマシンに検証用に引き上げることを想定しているからです。

というわけで、以下のような構成で仮運用がスタート。

  • JIRA => チケット管理
  • Agile Story Map for JIRA => ストーリーの構造化
  • Portfolio for JIRA => ロードマップの可視化

ちなみに社内サーバに構築しています。評価期間が終わったのでHSQLからPostgreSQLに乗り換えようとしたら、エラーで立ち上がらんようになった話はちょっと別にまとめます。

利用の流れ

JIRAで統一できるようになっただけで、以前のツールから計画や管理の流れはあまり変わっていません。

  1. ユーザストーリマップでストーリーのロードマップを計画
  2. ストーリーマップを元にPortfolioでリリース計画を作成(見積もりのキャパシティ)
  3. リリースに入ったものをカンバンで進捗管理
    1. 簡易見積もりができたチケットから「開発予約」レーンに
    2. コードレビューが終わったら「受入テスト中」レーンに
  4. リリース後にふりかえりしてバージョンをリリース
    1. リリース作業そのものの確認と次回の改善タスク
    2. イテレーションの見積もりを再確認(精度の話)
    3. 次期イテレーションの計画と設計

これらを同じデータソースを使いながらビューの切り替えで把握することできるのがかなりストレスフリーです。

カンバンのワークフロー、トランジションはデフォルトから変更しておらず、レーンと必要なフィールドを運用に合わせて追加しただけです。

とりあえず開発では本格導入決定

2イテレーション試して、FeatureMapもWaffle.ioもなくて困らない、という結論になったので開発チームでの移行は完了しました。

次の段階でビジネスサイドを巻き込もうかと思っています。まずは、ビジネスサイドの実務者レベルで使い方を広げてみて、というところですかね。

ConfluenceとService Desk(これは課題コレクターでいいのではないかという考えもある)を試してドキュメントやビジネス系タスク管理などを一緒に行ってもらうことを考えています。

以下、管理上のメモ

ユーザ管理

  • 匿名ユーザは使えない(おそらくService Deskでは可能)
  • ユーザグループは一度作成したら名称変更はできない模様
  • パーミッションスキームはグローバルなのでユーザグループではなくプロジェクトロール当てた方が管理が楽
  • プロジェクトロールはグローバルな設定として追加(設定 > システム > プロジェクトロール)

まだ使っていませんが、課題レベルのセキュリティという機能があるので、セキュリティ上見せたくないチケットをパーミッションスキームでコントロールとかしなくていいようです。チケットごとにコントロールできるようになるため、基本誰にでも見せるようにして課題レベルで参照をコントロールするのが良さそうですね。

要注意事項

Portfolioの参照、管理権限には必ずjira-administratorを入れて、ユーザグループやらプロジェクトロールやらは本格運用開始する前にある程度固めておきましょう。Portfolioの参照権限を使っていて、

ユーザグループ作成 > グローバルなパーミッション変更 > 見直し

の流れで取り組んで、

プロジェクトロール追加 > パーミッションスキーム見直し > ユーザグループ再作成(名前変更できないし)

したら、ユーザグループに紐付けてる計画まで参照できなくなりました。

PortfolioとEasy Agile Story Map for JIRA

  • PortfolioとStory Mapでロードマップと価値の計画をする
    • 計画は見通すもの
    • ラッキングを精緻にするのはまた別の話
  • EpicはStoryマップの縦軸(アクティビティ)、Portfolioのユーザにとって意味のある大きな計画単位として捉える
  • StoryはStory Map上の分割ステップ、Portfolioの分割ステップとして捉える

ラッキング項目について

  • バグや個別に出てきた課題(タスク)などはエピックに紐付かなくてもいい運用とする
  • Portfolioでタスクもトラッキングして計画に入る設定にした
  • 重要視すべきは次以降のイテレーション計画とキャパシティ(ベロシティ上限コントロール)

プロジェクトスタイルとアドオン

  • Easy Agile User Story MapはScurmプロジェクト前提で、カンバンだとエラーがでる
    • プラグインがバージョンアップして対応
    • ただし日本語で使っていると課題タイプ名の変更が必要(課題タイプ名にEpic, Storyが入っているかで判断しているため)
    • カンバンボードで使う場合はエピックが必須になるので、簡易フィルタで見えなくする扱いができなくなった
      • エピックはラベルに近いので完了をしない
      • とりあえずエピックの優先順位を暫定的にLowestにした

作業ログの記録の仕方

  • デフォルトの設定では作業ログ記載できないので、時間トラッキングをonにする
  • 見積もり時間を使い切ってしまう作業ログを記録すると、Portfolio上の進捗は終わった扱いになる
    • 進捗管理はカンバンボードでしているのであまり気にしていない
  • プロジェクトの見積を Story Point -> Hour(1 * 2)で運用開始(Portfolio上)
  • 残がなければリリースはクローズにする

受入テストについて

ここがまだ運用としていけてないというか固まってないところです。ちなみにFeatureMapの時は、ストーリーにチェックボックスが作れたので、それでテストシナリオを作成していました。同様にTODO付けられるアドオンを探したんですが、7.1.9までしか対応してないようで、インストールすると警告が出るので、まだ導入を見送っています。

とりあえずの代替案としては、テキストのカスタムフィールド + テキストのマークの表現でなんとかする形に落ち着きました。(i)と(/)と(x)で表現されるマークで進捗を見れるようにしています。

ステークホルダーへの定期報告について

おそらくJIRAを導入したからといって、今redmineを見ない人が急に見てくれるわけではないので、定期報告みたいなものは結局なくならないし、続けた方がいいとは思っています。ただ、リリースの画面 or ScrumボードのバージョンレポートのPDF印刷が見栄えが良いことに気づいたので、次の定期報告からそれを使ってみようかと思います。

Githubとの連携

  • OrganizationでOauthキーとシークレットを発行してログインするだけ
  • コミットメッセージに課題IDをつけることによって自動的に連携
  • ポーリングしているようなので状況の反映には少し時間が掛かる

各スキームについてのとりあえずの理解と設定

  • 課題タイプスキーム > どの課題をセットにして使うか
  • ワークフロースキーム、ワークフロー > 状態遷移の定義(どういう遷移が可能か?)、だいたいデフォルト
  • 画面スキーム > ボード(プロジェクト)ごとの課題作成などの画面構成とそのスキーム、どの画面にどの項目を表示するか、課題のタイプごとに画面スキームを分けることができる
  • フィールド構成スキーム > フィールドと画面の紐付け、必須かどうかの決定などを行う

課題(というか要調査とかやりたいこととか)

社外からもアクセスできる環境への以降

  • 出張中とか自宅作業中とか
  • HSQLの検証環境にして運用しているので、外部データベースに移したい
    • 失敗したので再チャレンジ

タスクの完了とPortfolioの計画トラッキングの問題

  • カンバンでストーリーを完了したら、Portfolio上のリリースから消えてキャパシティが減った
  • 進捗度合いがあんまり見えないが、今は計画ビューとして割り切っている
    • 作業ログを入力すると進捗は見える
    • 完了の定義をどう運用しているかいろんな人に聞きたい

PortfolioのStageとSkill

  • 現状使っていない
  • カンバンのワークフローというよりも人員計画で主に使う
  • 仮想的人材を計画してステークホルダーへの要望出しとか

ServiceDeskを導入検討

  • 社内からの要望の起票や参照を匿名ユーザからできるようにしたい
  • 課題コレクターとプロジェクトのパーミッションスキームで実現可能ではないか、説