【アジャイル】【設計】設計、実装に曖昧なところがあったので、スパイクを実施してみた

アジャイル システム開発

はじめに

備忘録レベルですが、同じような思いをしている方たちが
たくさんいるはずなので自分がやったことを書きます。

経緯

先月の話になりますが、転職をしまして職場に慣れるという意味で
実装を任されるとばかり思っていました。

しかし、経歴の考慮、タイミングにより基本設計から
アサインされることになりました。

いきなり設計？

今までの経験上、実装は追っていればすぐにわかる内容だったので
良かったですが、業務知識、システム知識がない状態でのアサインだったため
不安が先行していました。

まずは要件確認

設計、実装するのにもまず「何がやりたいのか？」ということを
はっきりさせて、自分の中に落とし込まなければいけないので
リーダーから事前にMTGがあり、それを復唱するような形で
要件を再確認しました。

設計と見積りの間に実施したこと

要件は確認できて、さてどうしたものか？と考えました。
まず、自分で設計して実装するだけなら自分であーだこーだやれば
いいのですが、今回は若手メンバー含めての対応なのでそうはいきせん。

そこで、設計と見積りの期間を多めにもらい（もらっていたとも言う）
実施したのが、アジャイルプラクティス（スクラム）のスパイクです。

Spikes « Scaled Agile Framework

これは技術的なリスク、機能的なリスクが事前にわかっている場合に
実際の実装行程ではなく、最初に「動くもの」を作るというものです。
さらに心配症な人に取っては、ありがたいもので少しでも「これでいける！」
と思えれば自信を持って案件に着手できます。
さらにメンターに取っては事前に技術的、機能的な道筋が立っているので
教える立場となったときも「教える計画」を立てることができます。

そして、最後に自分の中で考えついた設計、見積りを共有して
「こんな感じでやります」というのを実施しました。

スパイクをやってみて

結局、メンバーは2人にしてもらい、案件リーダー兼技術リーダーっぽい
状況になりましたが、自分である程度、道筋を立てているので予定通りにいけば
それで問題ないです。

ただし、スパイクで実装したときはあくまで「プロトタイプ」の位置づけなので
実際に実装行程となった場合、考慮していなかったことや疑問点が必ずと言っていいほど出てきます。
しかし、道筋を立てているので、少しのズレがあっても修正できますし
大きなズレがあった場合も気づきやすいという点も大きなメリットがありました。

まとめ

「アジャイルプラクティス」というのはすべてをいっぺんにやろうとすると
崩壊する確立が高いですし、計画倒れ、形骸化する傾向があります。
ただ、自分だけでやれることがあれば、自分の頭の整理になったり
プロジェクトの計画も立てやすくなると思うので、小さいプラクティスを
少しずつ導入して、効率が良く不安要素がない開発にしていければと考えています。

最後になりましたが「スパイク」という単語が出てこないため
Twitterでぼやいたところ、プラクティス名を教えていただいたぺらさんに感謝です。