こんにちは!
現場に参画したばかりのエンジニアの方などは、開発手法を選べる立場ではない事が多いと思います。
しかし、チームの仕事の進め方が円滑でないときや、自分の任せられた仕事の進め方をより改善したい時など、知っていると役に立つときが来るかもしれません。
そういった点からアジャイル開発を中心に主な開発手法について紹介します。
1、アジャイル開発とウォーターフォール・モデルの開発の違い
[アジャイルソフトウェア開発]
反復(イテレーション)と呼ばれる短い期間(1~4週間など)で、
開発対象の機能を分割し、リスクを最小化する手法を指すことが多いです。
利点は、突発的な仕様変更などにも柔軟に対応でき、短い期間で成果物をリリースしていけるところです。
例として、ECサイトの商品更新、機能追加など
短い単位でリリースが必要な時に多く採用される手法です。
[ウォーターフォール・モデル]
要件定義、外部設計、内部設計、開発、テスト、運用のように、作業工程をトップダウンで分割し進める手法を指します。
前工程が完了しないと次工程に進めないので、品質を確保し、前工程の後戻りを最小限にする。
利点は標準的な開発手法なので慣れていること、また工程の進捗管理がしやすいことです。
<比較してみて>
一般的にですが、開発期間が短くリリースが頻繁に起こる状況だとアジャイル開発が採用されることが多いです。
また、開発期間が長くまたチームの規模が大きいプロジェクト程工程管理がしっかりされるので、その場合はウォーターフォールが採用される傾向があります。
2、アジャイル開発の進め方など
立ち上げたばかりで最初からエンジン全開の最効率で開発できるチームはなく、
どのチームも最初は課題が多いと思います。
各個人の能力・長所、チーム全体のパフォーマンスを知り、効率よく開発することが大事です。
そのために、まずは計画を立て次回のイテレーションの中でチームで達成すべきタスクを決定していきます。
一つのイテレーションが終えた後に振り返りを実行し、前のイテレーションの改善点などを出し合います。
「計画を立て実行し改善する」その繰り返しでチームをより良く作り上げていきます。
もちろん、イテレーションの中でも話し合いの場が多々あります。
また、各個人の良かったことを褒めるなどしお互いを認め合うことも大事な要素です。
3、アジャイル開発を踏まえた経験、感想
<利点と感じたこと>
- チームで話し合う時間、相談する時間が増えコミュニケーションがより円滑になった
- ペアプログラミングなどで参画したばかりのメンバー間の理解が深まった
- チームの課題に対する話し合い、振り返りのKPTなどを通して自分が発言する機会が増えた
- 他メンバーの意見を聞く機会が増えまる
- 自分のタスク管理に対し、よりシビアになった
短い期間でリリースをする必要があるので、いつまでに何を終わらせる必要があるのかなど、期限から逆算して物事を考えることになります。
この機能は見積工数が多いため、今回のリリースから外してもらう調整をチームを含めしたいなどの考えもでてきます。
<取り入れにくい点>
- 慣れるまで時間がかかる
- 覚えることが多い
アジャイル開発を取り入れているプロジェクトは、最新のチーム管理ツールやチャットツールなど使用しているところが多いので、それらのツールの使い方に戸惑うことがあります。
また、チームで話合う時間、他チームとの調整などミーティングに時間も少なくないので、自分の作業を進める時間とチームに使う時間の調整をしていく必要があります。
自ら考えチームを巻き込んでいく行動力が必要になるので、マインドを切り替えないとタスクに追われる日々になってしまいます。
「慣れるまで」の期間は、今までのやり方に囚われずこれからチームとしてどうしていくのが良いかという方向に考えが切り替わるまでです。
些細な事でも気になったら相談するとか、仕様を決めるためチームで話し合いたい、理解を深めるためチームで勉強会を開きたいなど積極的に働きかける姿勢が大切です。
4、リモートワークとアジャイル
新型コロナウイルスによりリモートワークに移行している企業も少なくありません。
開発手法で見ると、アジャイル開発、ウォーターフォール開発どちらともリモートワークを取り入れて問題ないと考えています。
リモートワークする点で大事なのは「コミュニケーション」です。
いつまでに誰が何をどこまで作成するのかなど基本的な進捗管理は、手法の違いはあれど根本は同じなので、正しくメンバー間で共有できているかが大事になります。
5、まとめ
簡単にではありますが、アジャイル開発についてまとめました。
総括しますと以下のようになります
- アジャイル開発はウォーターフォール開発の上位互換ではない
- 無理にアジャイル開発を取り入れたり特定の手法にこだわると逆にパフォーマンスを下げてしまうことがある
- 開発手法より、自分たちのチームのやり方、改善点を定期的に振り返ることが大事である
- 何よりコミュニケーションが一番大事
<参考にした書籍>
とあるエンジニアを主軸とし、ストーリー仕立てで次々と問題が起こり、
その問題に対して様々な手法を取り入れてチームで解決していく本です。
フィクションではありますが、手法は実際に使われているものなので、
使い方・導入の例として参考になります。