うまとま君の技術めも

2015年新卒入社した社畜の勉強内容などなど

アジャイルプラクティス

アジャイルラクティス

効果的なプラクティス無しにプロジェクトを進めてしまうと、問題が多発し品質の悪いソフトウェアを作り続ける羽目になってしまうことだろう。

そのような苦い経験をすると、同じ過ちを繰り返さないよう過去の経験を元に成功したプロセスを採用してしまいがちである。気づいたときにはプロセスが大きくなりすぎて身動きが取れなくなってしまう。そのような状況でさえチームはプロセスが足りないのが良くないのだと思いこんでしまい悪循環に陥ってしまう。

この状況を改善しようと業界のエキスパートが集まり、開発チームが迅速に作業し変化に対応できるよう「価値と原則」をまとめたのである。

アジャイルソフトウェア開発宣言 - 価値

  • プロセスやツールよりも、人と人同士の交流を重視する
  • 包括的なドキュメントよりも、動作するソフトウェアを重視する
  • 契約上の交渉よりも、顧客との強調を重視する
  • 計画に従うことよりも、変化に対応することを重視する

プロセスやツールよりも、人と人同士の交流を重視する

良いプロセスを使っていても、優秀な人材がいなければプロジェクトはうまくいかない。また、優秀な人材が揃っていたとしても、協調して仕事を行うことができなければ失敗する。協調性のないスーパースター集団よりも、うまくコミュニケーションを取れる平均的な人材を集めたほうがうまくいきやすい。

仕事を進める上で適切なツールを使うことはとても大切である。しかし、ツールに頼りすぎたり、大きくて複雑なツールを過度に導入することは状況を悪化させる。まずはホワイトボードや紙などのシンプルな道具を使ってみて、どうしてもうまくいかないのであれば他のツールを導入してみよう。

大切なのは、開発環境を整えるよりも開発チームを形成することのほうが重要だということである。

包括的なドキュメントよりも、動作するソフトウェアを重視する

ドキュメントを用意することは人間に情報を伝える手段としては適切であり、重要なものである。しかし、ドキュメントがたくさん作られてしまうことは不足するよりもタチが悪い。必要なのは、シンプルで重要な事柄のみを記載したドキュメントである。

新メンバーへ仕事の内容を教えるときに重要となるドキュメントは「コード」と「チーム」である。コードの処理内容に嘘はなく確実な情報源である。また、常に変化するロードマップなどは「チーム」の頭の中にある。これらを伝える最も良い方法は、人間同士で直接伝えることである。

契約上の交渉よりも、顧客との強調を重視する

ソフトウェアを開発する上で前もってプロジェクトの納期や条件を契約書で定めること自体が、そもそも無茶である。契約書で定めた内容の大半は途中で意味をなさなくなってしまう。

プロジェクトを成功させるためには、顧客からのフィードバックが欠かせない。顧客は契約書にすべてを任せず、開発チームに対して頻繁にフィードバックを行い密接にプロジェクトに関わるべきである。

計画に従うことよりも、変化に対応することを重視する

ソフトウェア開発において、遠い未来の予定を立ててもあまり意味がない。理由としては以下の3つであり、変化に対応する能力があるか否かが、プロジェクトの成否を分けるのである。 - ビジネスの状況が変わりやすい - 顧客は動いているシステムを見ると、要求を変更してくる - 開発時間を正確に見積もることは難しい

詳細な予定を2週間程度、おおまかな予定を3ヶ月程度作り、その先に関しては大雑把にしておくのが上手な計画の建て方である。こうすれば、綿密な計画を練っている時間は小さくなり、変化に対応しやすくなる。

アジャイルソフトウェアの12の原則 - 原則

  • 再優先事項は顧客を満足させることであり、価値あるソフトウェアを早い段階から継続的に届けることでこれを実現する
  • 要求変更を歓迎し、たとえ開発過程の後半であってもそれを受け入れる。アジャイルプロセスは、変化に対応することで顧客の競争上の優位性を確保する。
  • 実動可能なソフトウェアの納品を頻繁に行う。できるだけ短い期間で納品することを旨とし、数週間から数ヶ月間隔で納品する。
  • 顧客と開発者はプロジェクト全般を通じて日々ともに働かなければならない。
  • やる気のある開発者をプロジェクトの中心に据え、彼らが必要とする環境とサポートを与え、信頼して仕事の完遂を任せる。
  • 開発チームで情報を伝達する最も効果的な方法は、直接話し合うことである。
  • 実動するソフトウェアこそが進歩状況の尺度である。
  • 持続できるペースで開発する。そうすれば、スポンサーも開発者もユーザーもずっと一定のペースを確保できる。
  • 高度な技術と優れた設計への配慮は、アジャイル性を高める。
  • シンプルさが肝心 - やらなくていいことはしない。
  • 最高のアーキテクチャ、仕様要求、設計は自己管理能力のあるチームから生まれる。
  • チームは定期的にプロジェクトを見直し、より効果的な方法を考え、対応方法の変更や調整を行う。

再優先事項は顧客を満足させることであり、価値あるソフトウェアを早い段階から継続的に届けることでこれを実現する

ソフトウェア開発プラクティスに関する調査により、以下の調査結果が出ている。 - 最初に納品される機能が少なくて乏しいほど、最後の納品での品質はより高いものになる。 - 頻繁に納品すればするほど、最終的な品質はより高いものになる。

要求変更を歓迎し、たとえ開発過程の後半であってもそれを受け入れる。アジャイルプロセスは、変化に対応することで顧客の競争上の優位性を確保する。

開発チームは変化を恐れない。変化によって市場が求めているものをより深く学ぶのである。そして、変化に柔軟に対応できるようソフトウェア構造を柔軟に保つ努力を怠らない。

実動可能なソフトウェアの納品を頻繁に行う。できるだけ短い期間で納品することを旨とし、数週間から数ヶ月間隔で納品する。

最初の段階から実動可能なソフトウェアを頻繁に納品する。ドキュメントやプランを提示するだけでは不十分であり、実質的に意味はない。

顧客と開発者はプロジェクト全般を通じて日々ともに働かなければならない。

アジャイルな状態を保つために、顧客と開発チームやステークホルダーは密接かつ頻繁にやり取りを行うべきである。

やる気のある開発者をプロジェクトの中心に据え、彼らが必要とする環境とサポートを与え、信頼して仕事の完遂を任せる。

プロジェクトで重要なのは「人」である。プロセス、環境、管理などは二次的なものであり、それらが「人」に悪影響を及ぼすのであれば変更を必要とする。

開発チームで情報を伝達する最も効果的な方法は、直接話し合うことである。

プロジェクトの主要なコミュニケーションは「会話」である。仕様、計画、設計をドキュメントにすることを求めない。ドキュメントを作るのは重要かつ緊急な場合である。

実動するソフトウェアこそが進歩状況の尺度である。

進捗状況は実働可能なソフトウェアの量で判断する。ロードマップ上でのフェーズやドキュメントの枚数などで判断はしない。

持続できるペースで開発する。そうすれば、スポンサーも開発者もユーザーもずっと一定のペースを確保できる。

ペースを上げすぎると途中で燃え尽きたり手を抜いて大失敗することになる。明日できることは無理して今日中にやらない、常に最高の品質が保てるペースで仕事を進める。

高度な技術と優れた設計への配慮は、アジャイル性を高める。

プロジェクトの進行を早くさせたければ、ソフトウェアを常に健全な状態に保っておく必要がある。そのために、乱雑なコードを書いてしまったら、後回しにはせずその日のうちに書き直すのである。

シンプルさが肝心 - やらなくていいことはしない。

いきなりシステム全体を作ろうとせず、目的を達成するために必要なシンプルな方法を段階的に導入していく。予め必要となりそうなことを予想してもあまり意味はない。必要な作業だけシンプルに行えば、問題が発生しても柔軟に対処できるのである。

最高のアーキテクチャ、仕様要求、設計は自己管理能力のあるチームから生まれる。

チームは自己管理能力があり、一丸となって課題に取り組む。各個人がアーキテクチャ、仕様要求、設計に意見することはあるが、各個人が責任を負うことはない。責任はチーム全体にあるのである。

チームは定期的にプロジェクトを見直し、より効果的な方法を考え、対応方法の変更や調整を行う。

チームは、ルールや習慣などを常に見直す。環境は常に変化しそれに合わせて自分たちも変化しないとアジャイル性を保てないからである。

参考文献