ざっくりアジャイル開発について

2020年5月29日 17:42

はじめに

開発手法として「アジャイル」とか「ウォーターフォール」をよく聞きますよね。職場ではアジャイル開発が多いのですが、なんとなく言葉を知っているだけの浅い知識だったので、アジャイルサムライを読んでみました。

本を読んでアジャイル開発についてより具体的なイメージがついたし、現在のプロジェクトの課題を本書のパターンに当てはめて考えることができて、とても良かったのでまとめます。

エンジニアとして「お客さんにとって価値のある成果を出す」って、とても抽象的な言葉です。

どうしたらお客さんは価値のある成果を出してくれていると感じるのか？それは主に６つ大事なことがあります。

１：大きな問題を小さくする
２：本当に大事なことに集中して、それ以外のことは忘れる
３：ちゃんと動くソフトウェアを届ける
４：フィードバックを求める
５：必要とあらば進路を変える
６：成果責任を果たす

小さなサイクル（本では１週間と書いてある）でやると決めたことをやる。これがシンプルな考えです。そして、定期的にお客さんへ自分たちの方向性が正しいのか？を尋ねることも大事です。

単純に動くものを作るという以外に、テストやドキュメントなど付随する要素があります。それも大切だけど本当に大切なものに集中することを忘れず大事にしなきゃいけません。

また、開発していく中でプロジェクトの当初の計画ばかり頭に残り、「今」大事な課題ってなんだっけ？と疑問を抱くことも忘れたらいけません。

それらを意識しながら、スケジュールを守り、ソフトウェアの質に責任を持つことがエンジニアとして「お客さんにとって価値のある成果を出す」ってことなのかな、と感じました。

まずアジャイル開発の計画づくりにおいて自分が分からなかったワードをまとめます。

・ユーザーストーリー
顧客がプロジェクトで実現させたい一覧
・イテレーション
開発の期間の単位（１週間や２週間が多い）
・ベロシティ
１回のイテレーションで完了させるストーリーの量

下記の手法に、現場ごとの手法を加えていくイメージ。

・スクラム
アジャイルプロジェクトを包んで、プロジェクトの装いを与えてくれる運営手法
・エクストリーム・プログラミング
ソフトウェア開発のベストプラクティスを実践する手法
・リーン
能率を上げることをとことん追い求め、改善を続けるトヨタ生産方式

顧客はチームのコアメンバーであり、プロジェクトの協力的なパートナー。

デモを見て質問に答え、開発チームにフィードバックしてくれる存在。顧客の仕事によって魅力的なプロダクトが生まれる。

ーー「積極的に関わってくれる顧客がいなかったら、どうすれば良いのか？」

①ミーティングで「これから２週間で何かしらお客様の課題を解決します」と言う
②２週間後のミーティングでどう解決したのか報告する
→自分たちのチームが問題を解決できるチームだとお客さんに思ってもらえるまで３〜４回繰り替えす

上記をすることで信頼関係が築け、お客さんを開発に巻き込んでいけることが大事。

また、お客さんの前でソフトウェアをデモするだけで、チームは自分たちの果たすべき成果責任に対して自覚的になれる。（目の前で触ってくれるだけで嬉しいし、バグがあると次回から入念にテストしようと思いますよね！）

アジャイル開発というと小難しい開発手法なのかと思っていましたが、「アジャイルサムライ」を読んでいると、ソフトウェア開発で起こりがちな問題を解決してくれるフレームワークなんだなと思いました。

難しいものではなく、困った時に助けてくれる身近な存在というイメージに変わりました。

また、先人たちの工夫して失敗したポイント・成功したポイント、そして既にあるアジャイル手法にプラスされた独自の手法などを知ることで、

原則やプラクティスを押さえつつ、自分のプロジェクトにプラスとなるやり方を模索するヒントとなりました。

「アジャイルサムライ　１部」を読んだだけですが、とても勉強になったのので買ってよかったなと思いました。続きも読んだら感想書きたいと思います。

読書感想文

スキ頂けると嬉しいです〜