エンジニアは、アジャイルは何となくわかればOK
今や開発手法はウォーターフォールでなくアジャイルがスタンダードになりつつあります。ウォーターフォールで開発したやつでも、リリース以降はアジャイル開発に切り替えるといったこともあります。
しかし、アジャイル開発ってよくわからないところがあります。
私も最近の案件はアジャイル開発ばかりですが、言葉で説明しろと言われても正直困ります。アジャイルについては、それぐらいの理解力なのですが、実務で困るかというとそうでもないんですね。
PMやスクラムマスターは、アジャイルについて精通している必要がありますが、一エンジニアだと何となく、ふんわりと知っているだけでOKだったりします。
というわけで、アジャイル関連で、エンジニアレベルではこれだけ知っていればOKというレベルでまとめてみました。
エンジニアが知っておくべきことお
チケット
これを知らないと、まずい。エンジニアでなくても、ビジネスサイドの人もほとんどの人は知っている。
ツールによってはissueといったり、課題といったりもする。ストーリーと言ったりすることもある。
Gitのコミットに、チケットIDを記載することが多い。
かんばん
これも知らないと、まずい。今のタスク管理のツールでこの機能を持っていないものは存在しない。
ボードと言ったりもする。
チケットを付箋レベルで見える化した一覧。とでも言えば良いのだろうか？ 言葉で説明するのは難しい。
縦軸がチケットのステータスで、チケットのステータス管理に適しているダッシュボード。(理屈上は・・・💧)
スクラム
スクラムはアジャイルの一種。
それだけ知っていればOK。エンジニアは、スクラム=アジャイルの認識でいても何の問題もない。
スクラム以外のアジャイルは出会ったことがない。チケット稼働とかテスト駆動とかも、厳密にはアジャイルなのかも知れないが、それをアジャイルと呼ぶ人は、いない。
スプリント
開発の1サイクルの期間、区切り。1週間とか2週間にするのが大半。1ヶ月に設定することもある。
イテレーション、バージョンと呼ぶこともある。
作業見積が上手くできていないプロジェクトは、スプリントの切り替えで大量のチケットの移動作業が発生する。
ストーリーポイント
チケットの作業見積を数値化したもの。
1ポイントがどれぐらいの作業量かはプロジェクトによる。
ポイントを時間換算しないのが重要らしい。時間という絶対値だと、人によって算出が変わるし属人化してしまう。他のチケットのストーリーポイントと比較してポイントを算出する、つまり相対見積を心がける。
マイルストーン
プロジェクトの特定の期日やゴールなど。中間地点の意味合い。リリースやテスト完了などの粒度で設定する。
エピック
大きめの課題、1チケットで管理しきれないものはエピックに移す。エピックは複数のチケットからなる。
Backlogのような、孫チケットの概念がないツールは、親チケットがエピックになる。
ベロシティ
1スプリントで消費できたストーポイントの総数。チームでこなせたタスク量。
スプリントを回しているうちに、おおよそのベロシティがわかって、作業見積しやすくなるという理屈だけど、上手くいっているプロジェクトは、あまり見たことない。人の出入りが激しかったり、未知のタスクが多いスプリント、他社への依頼事項が多い場合などは、機能しない。
プランニングポーカー
チケットのストーリーポイントの見積を、複数人でカードを使ってやる方法。
けっこう面白いけど、やっている所はあまり見ない。やるときは知らない人もいるので、マネージャーとかがやり方を説明してくれると思う。なので、特に知っておく必要はない。
デイリースクラム
朝会や夕会をかっこよく言っただけ。
たぶん大半の人がうざったいと思っている。個人的にはやめて欲しい。2，3日のまとまった時間で作業させて欲しい。
プロダクトオーナー
顧客、エンドユーザーのこと。
まとめ
以上、エンジニアがアジャイルについて知っていれば良いレベルを、まとめてみました。(少しふざけ気味で)
エンジニアがアジャイルについて勉強する必要はありません。不明な言葉が出てきたら、意味だけググるぐらいで十分です。
