アジャイルな開発者であるためのTips

Last updated at 2019-04-03Posted at 2019-03-26

はじめに

私がスクラムのプロジェクトに開発者として参画してアジャイルコーチの指導を受けたり、いくつかのアジャイル研修を受講したりする中で、参考になったことをTips化してみました。

結果としては、アジャイル宣言の背後にある原則を「開発者視点で」具象化した内容になっていると思います。

私個人はスクラムしか経験がないので、スクラムをベースとした内容になっています。
この記事の内容はあくまで私個人の見解であり、所属企業における立場、戦略、意見を代表するものではありません。

a) こっち↓よりも…

b) こっち↓の方が価値を早く生み出しており、プロダクトオーナーからの信頼を得やすい。

ストーリー	サブタスク	担当	状態
ストーリー#1	1-1	A	完了
	1-2	B	完了
	1-3	C	完了
ストーリー#2	2-1	A	仕掛
	2-2	B	仕掛
	2-3	C	仕掛
ストーリー#3	3-1	A	未
	3-2	B	未

上のように、価値を素早く生み出すためには、「○○はAさんしかできない」というチーム構成は不向きです。
技術的にフルスタックであることはもちろん、デザインやテスティングに関する知識も持っている方がベターです。
プロダクトオーナーと議論したり、提案するためには業務知識も必要です。
- 対してウォーターフォールの場合は、末端の技術者が「自分が誰のために何を作っているのか知らない」という状況が良くありますよね。
各開発者の得意分野はあれど、他のどんな分野の業務も「手伝える」レベルを目指すことが重要です。

技術的負債は、借金と同じで、長く放置すると利息がついて返済しづらくなります。こまめに返すべきです。
こまめに、ためらわず、リファクタリングを行うべきです。
- ウォーターフォール脳のエンジニアには、これが案外難しいと思います。
- 「既存ロジックをなるべく触らずに拡張しよう」という考えは捨て去るべきです。それが、多すぎる引数や、複雑すぎる条件分岐を生み出しがちです。
リグレッションテストを自動化することは必須と言って良いでしょう。
変更に強くあるためには、アーキテクチャーが重要です。
- モノシリックよりもマイクロサービスを。

私のスクラム実践時の大反省点なのですが、新しいストーリーの開発に意識を奪われて、バグ修正が後回しになりがちでした。
アジャイルソフトウェア開発宣言に『（包括的なドキュメントよりも）動くソフトウェアを』とありますが、英語版では"Working software"となっています。英語の"Work"には「期待通りにやりとげる」というニュアンスがあります。
日本で開発者が「動く」というと「とりあえず動いてる」みたいなニュアンスがある気がしますが、アジャイルでは、インクリメントは常時「期待通りに機能する」状態にする必要があります。
要するに、仕様ミスだろうが単純バグであろうが速やかに修正しなければなりません。期待通りに機能しないソフトウェアには価値がないわけですから。

デイリースクラムはスクラムマスターに進捗報告をする場ではありません。
開発者は「チームに」「ありのままに」報告します。
私が個人的に良いと思う報告の仕方
- 毎日、「私は今日、これを終わらせます」と宣言する。
- そして翌日、前日の宣言通りの状態であれば問題なし。
- 宣言通りに終わらなかったとしたら、その理由を正直に言う。
問題・課題は、チームが解決するのです。スクラムマスターは「こぼれ球」を拾ってくれたら良い。
スクラムマスターが「で、どうやってキャッチアップするの？」とか言い出したら、スクラムチームの"死"だと思います。
コミットメントにバッファを含めないことも、大事だと思います。

良いアジャイル開発者であるためには、向上心と学習意欲を持ち続けることが必要で、シンドイ面もあります…

でも私は、アジャイルがもっと普及すれば、ソフトウェア開発はもっとクリエイティブでエキサイティングな仕事になると考えていますので、今後も精進したいと思います！