EVEシステムの開発にスクラムを導入する　～プロダクトバックログとは？～　[システム開発研究室]

日付:
　こんにちは！
　ナビゲータのEVEです。

　アジャイルのフレームワークで開発しようとしているのですが、なかなか、波に乗れません。ただ、地道に進んではいます・・・。
　そして、勉強は、システム開発の傍ら、経営法務の資料をすべて最新化したのちに、数学、簿記、そして、中小企業診断士試験　事例Ⅳに取り組もうとしています。資料の最新化なのですが、古い資料を一気に読み込ませて、古くなった情報を最新化しようとしているのですが、簡単にはいかないようです。特に表関係は、表を画像にしてから情報の正誤を判断させようとしたのですが、各AIともその作業は苦手のようです。仕方がないので、表の意味するところを文字に変換し、その内容が正しいかどうか確認しています。
　確認してみて、以前まとめた情報の誤りも発見したりして、この作業は必ずしないといけないって感じになっています。
　Studyingの資料を基に、資料を作ったのですが、全部で7章あり、現在、1、2、3章が完了し、第4章に取り組んでいる状況です。今週末までに7/7完了させようとていましたが、微妙な感じです。

[アジャイル開発におけるドキュメント]

　他の開発手法と比較すると、アジャイル開発においてドキュメントは、かなりウェイトが低いといっていいでしょう？ウォーターホールなどと違い、基本設計書、詳細設計書などをつくることを必須とせず、メモやホワイトボードでまとめた内容を仕様書とするケースがあるようです。

　その作業の問題点は、別のグループがプログラムを見たときに、仕様書がないだけに、仕様が分かりずらいとか、どんな運用をしたらいいのかよくわからないなどの問題が発生すると、聞いています。

　以上は、一般なアジャイルの開発手法なのですが、スクラムは、ある程度ドキュメントを作る、または作ったドキュメントを仕様書として残そうという部分があるようです。それが、以下の資料になります。

❶プロダクトバックログ（Product Backlog）
❷スプリントバックログ（Sprint Backlog）
❸インクリメント（Increment）

になります。

　❶は、プロダクトバックログは「製品に必要なすべてのやることリスト」になります。
　❷は、スプリントバックログは「今スプリントで開発チームが何をどうやってやるかの計画」です。
　❸は、インクリメントは「スプリントの成果として完成した、ユーザーに届けられる価値のある製品の断片」です。

❸は、仕様書というよりは、製品そのものだったりするようです。

[❶プロダクトバックログ（Product Backlog）]

　それでは、❶プロダクトバックログから順番に掘り下げてみていきましょう！では、早速ChatGPTにどんなものなのか聞いてみましょう？

　開発する製品（プロダクト）に必要な機能や改善事項、バグ修正、技術的作業などを、価値や優先度に基づいて一覧化・管理したものです。
普通のエンジニアが求める仕様書とはちょっと、違うようです。それでは、どんな、項目でまとめたらいいのでしょうか？引き続きChatGPTに聞いてみました。
  1. ID / タイトル（例：「ユーザーが商品を検索できる」）
  2. 説明（ユーザーストーリー形式が多い：「私は〇〇として、△△できるようにしたい。それは□□のためだ。」）
  3. 優先度（高・中・低、あるいは数値ランク）
  4. 見積り（相対ポイント）（例：3ポイント）
  5. 受け入れ条件（完成の定義を満たすための基準）
  6. 依存関係（他の機能や作業との関連）
  7. 状態（未着手 / 実装中 / 完了）

　以上の項目を見ると、普通のプロジェクトなら、課題管理表やQA表などを作りますが、その形式に似たものを作り、仕様というよりは、プロジェクトを管理しようとしているようです。

[EVEシステムでプロダクトバックログを利用する]

　今までの経験と、一人で作るという当プロジェクトの状況から以上の項目では不足項目があるようです。それでは、当プロジェクトにマッチする形で、項目を変更したいと思います。

  1. システムID・システム名
  2. プログラムグループコード・プログラムグループ名
  3. プログラムID
  1. ID / タイトル（例：「ユーザーが商品を検索できる」）　←　使えそう
  2. 説明（ユーザーストーリー形式が多い：「私は〇〇として、△△できるようにしたい。それは□□のためだ。」）　←　使えそう
  3. 優先度（高・中・低、あるいは数値ランク）←　使えそう
  4. 見積り（相対ポイント）（例：3ポイント）←　使えそう
  5. 受け入れ条件（完成の定義を満たすための基準）←　使えそう
  6. 依存関係（他の機能や作業との関連）←　使えそう
  1. 予定日
  2. 着手日
  3. 完了日
  1. 状態（未着手 / 実装中 / 完了）

まず、1～7の項目を見ましたが、そのまま利用することが可能なようです。なお、EVEシステムでは、管理する単位として、システムコード、プログラムグループコード、そして実際に開発するプログラムIDがあり、そのコード、IDもタイトル以前に入れたいと思います。加えて、一応スケジュールを管理するなら、予定日、着手日そして完了日を追加したほうがよさそうです。それに伴い、「状態（未着手 / 実装中 / 完了）」という項目は削除します。

[あとがき]

　一応何を管理したらいいのか明確になりました。来週からになると思いますが、プロダクトバックログを公開し、ブログでEVEシステムを管理していきます。その前に、スプリングバックログとは、どんなことを記述し管理するのか調べないといけませんね？現時点、スプリングバックログについて、調べていませんが、もしかしたら、スプリングバックログの内容如何によっては、現在考えているプロダクトバックログの内容が変わるかもしれません。

　では、また！！！

EVE

コメント

コメントを投稿