Help us understand the problem. What is going on with this article?

[補足・蛇足版] アジャイルとは何か?今あらためて誤魔化さずに実践的に説明してみる

More than 1 year has passed since last update.

アジャイルとは何か?今あらためて誤魔化さずに実践的に説明してみるの続編、補足版です。

大きな話としては上の投稿の通りですが、そこでは表現しきれなかった細かな「アジャイル ≒ Scrum」のテクニックが存在しています。みなさん知りたいことはそれぞれなので、そういうものを補足的に離散的に説明。どれか1つでも知りたいことにヒットすることを願って。

もし、ここにはない知りたいことがあったら、コメントにでも書いてくれたら可能な限り説明試みてみますのでお気軽にどうぞ。

Sprintを短く区切る心理的な理由。夏休みの宿題症候群、パーキンソン症候群を防げる

1年のタスクがあっても、1週間 x 52回のタスクがあっても、同じではないのか?
算数で考えると一緒ですが、実際は違います。
1年後にリリース日が決まっていた場合、最初の1日は、まだリリースまで1年ある!です。1週間Sprintに設定した場合、1週間後にリリースだ!急がないと!です。
Sprintを短くする、つまりは小さなGoalを定期的におくことで、ムラなく、1日1日を集中して作業することで、作業効率が上がります。

良く使われる機能は全機能のうちの7%

一般的なシステムのうち、全機能のうち7%が良く使われる機能、64%がまれに使う/まったく使われない機能といわれる

アジャイルでは、大きな1つの要件ではなく、小さな要件100個に分けて管理します。

トラディショナルな手法では全要件が完成するまでリリースしませんが、もし7個作ってリリースしてみてうまくいくのであれば、残り93個を作らなくてもいいかもしれません。その93個は、システムではなく、10年に1回マニュアル運用で十分回避できるかもしれません。
ほとんど使われない93機能を頑張って作るよりは、今使われている機能をブラッシュアップしたり、より使われる機能を検討する時間に使う方が建設的です。

🔖 引継ぎも1要件として扱う

引継ぎも「作業タスク(バックログ)」です、要件の1つです、リスクの1つです。他のバックログと同じく優先度を決めて対応します。

もちろんメンバが急に明日から来なくなる可能性も否定できません。では、そのために毎日引継ぎをするべきでしょうか。その引継ぎ先も本当に引き継いでくれる保証はありません。どこまでリスクを許容するかという問題です。
例えばプロダクトオーナーが「引継ぎ」を絶対的に最優先にするのであれば、「Doneの定義」に入れてしまうことも可能です。その場合、もちろんその分他の作業効率は落ちます。

アジャイル(Scrum)では、チーム全員が平準的にどんな作業でも出来るような構成を目指します。アジャイル(XP)ではコードの共同所有を目指します。無駄なドキュメントを作らない中でも、チーム内でノウハウを溜めるとともに最低限のリスク回避は目指しています。

なんにせよ最悪なのは、引継ぎ先もわからず、引継ぎ時期もわからない中で、優先度を無視して使われないドキュメントを作り続けることです。引継ぎが必要な時に、必要なだけ行う、というシンプルな理屈です。

🛁 見積もりも意外と普通に行う

基本的には他の開発手法と大きな差はありません。作業する前には見積もりをします。

細かなテクニックとしては、スプリントの最初に、プランニングポーカーで行う、というのが有名です。本質的には、作業の直前に、開発チーム全員でなっとくした見積もりを出す、ということが重視されます。アジャイル(Scrum)では「個人」ではなく「チーム」での開発を行いますので、見積もりもPMやリーダーや誰か1人の裁量ではないということです。

あとは、スプリントが細かく分かれるので、見積もりの精度がどんどん上がっていきます。1年に一回の見積もりよりも、1週間ごと52回の見積もりの方が熟練度も上がって精度があがるのは自然なことです。

🗿 どんなプロジェクトでもアジャイルでやった方がいいわけではない

1か月のプロジェクトにScrumは向きません。
超少人数(2人とか)にもScrumは向きません。
Scrumではチームを醸成するのに2~3か月かかると言われています。開発メンバ + Scrum Master + Product Owner が必ず必要なので、1人とか2人とかのプロジェクトにも使えません。
Kabnanとかなら使えると思います。

✨ サービス保守にアジャイルは使える?

何とも言えないです。
わたしは、開発はScrumでしてましたが、サービス保守でScrum使うのはやめました。

理由はシンプルです。 Scrumでは、リリースの日程が固定されますが(Sprintの最後になります)、例えばクリスマスにあわせて画面を変えたいとしてクリスマスは必ずしもSprintにタイミングがあってくれません。
なのでScrumはやめました。

ITILなどにのっとった社内システムなどでリリースタイミングが調整可能なのであれば十分使えると思います。B2Cシステムでは、Scrumのプロセスをそのまま使うのは困難な気がします。Scrumのエッセンスは使えると思います。


ということで思いつく限りで。

567000
組み込みからWebサービスから機械学習からオブジェクト指向から開発プロセスから認定ScrumMasterからなんならUI/UX/HCD/デザイン思考まで。 投稿した内容でなにかあったらTwitterなどへ気軽にどうぞです。
https://twitter.com/aka567000
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away