skillup

技術ブログ

ドキュメント作成 プロジェクト管理

アジャイル開発について

投稿日:2021年4月26日 更新日:

エンジニアとして仕事をしてから7〜8年立ちましたが、その間9割近くはいわゆるアジャイル開発でやってきたと思っていました。今は比較的大規模な開発をしておりますので、ウォータフォールですが・・・

が、先日ある本を読み、今までやってきたものが全然、アジャイルではないと実感しました(汗)。

自分の認識だと、

ウォーターフォール

要件定義〜設計〜実装〜テストなどのプロセスをしっかりへて、プロダクトを作っていく。

アジャイル

ドキュメントなどがあまり存在しておらず、スピード重視で、モックのプロダクト作成→フィードバックを繰り返して完成形に近づけている

のような認識でいました。

読んだ本は、「いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法 という本なのですが、すごく良くまとまっていていており、感銘を受けました。

以下にポイントを書かせていただきます。

  • システム開発において、机上論だけで完成品を求めるのは難しい(機能の6割は使われない)
  • アジャイル形式は上記のようなソフトウェア開発における不確かさを吸収し、変更を歓迎する手法である。プロダクトを成長させて、改善させていく思想。
  • プロダクトの着地点を見失しなってしまうというリスクもある(永久に作り直しをするなんてことが・・・)
  • 開発単位は「価値を提供できる最小限のプロダクト」を「小さく(インクリメンタル)すばやく(イテレーティブ)作ること」(要件定義〜設計〜実装〜テスト)フローを細かく回転させる。アジャイルの開発期間をスプリントといい、1〜4週間程度が一般的。
  • そのために大事なのがチーム作り、タスクの見える化(やること、やっていること、やったこと)を行う、タスクを細かく最大でも1日単位にする。
  • 細かい改善をしていく上でプロダクトの品質を担保していくのが、テスト自動化。細かく、頻繁なリリースを行うので、テスト自動化しておく必要がある。
  • チーム内のフィードバックが最重要。日にち単位で会議を行う(細かいフィードバックする)必要があるが、会議などが形骸化し、「問題ありません」などの発言が出てくるようになったら危険。
  • スプリントごとにKPTを設定する。Keepは良かったので継続すること、Problemは悪かったことで問題だと思ったこと、Tryは次に実行することをフィードバックし、チームを改善、成長させていく必要がある。
  • モブプログラミング(複数の人の視点を受けながら、コードを書くこと。ペアプログラミングの多人数版)などもフィードバックを受ける手法の1つ。
  • ドキュメントの不在などが言われることがあるが、あくまで手段なのでドキュメントがないわけではない。
  • プロダクトを成長させるという思想から準委任契約(時間)の方が親和性がある。

振り返ってアジャイルの思想を全く理解してなかったなあ・・・と思いました。

アジャイルというか正直いうと低予算だったので要件定義〜設計の時間を端折った「低予算開発」というのが実態でしたね・・・

それはそれで楽しかったのですが・・・今後アジャイル開発をする場合は上記のような設計の思想をしっかりとり入れて行いたいと思います。

-ドキュメント作成, プロジェクト管理
-,

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

設計業務での改善点など

比較的大規模なプロジェクトの設計段階で思ったことなど。会議など頻繁に開かれると思いますが、聞いているだけだったり、各人が色々なことを喋って内容がまとまっていなかったり・・結局何をやりたいかわからなくな …

no image

使える設計書作成に関して

私自身、この仕事を7〜8年やっておりますが、設計書作成については常に悩まされておりました。 設計書のメリット・デメリットとしては以下のようなものですかね。 メリット メンバー間での仕様の認識を統一でき …

no image

APIのエラーコードに関して

APIのよく使われるHTTPステータスコードに関して。 基礎の基礎で当たり前に使ってましたが、基本的なことに関してまとめ。 主に4XXエラーのタイプ分けに関して。 Contents1 2002 201 …

no image

テスト対策(単体テスト、結合テスト、総合テスト)

単体テスト、結合テストで発生した障害の分析(どんな障害が起こって、原因はなんで、再発防止に関してどうすべきか)なんかをやってます。 個人的に各フェーズで留意する点などを。 Contents1 共通2 …

no image

テーブル設計に関するメリデメ

昨日も書いた記事なんですが、基本的に実装にしても設計にしてもこれが最強っていう手法はなくて(あったとしたら全員がそれを使うのでそもそも選択肢という概念がなくなる・・)メリットデメリットをしっかりと考慮 …

アーカイブ