とあるSEの適当日記(仮)

その時のプロジェクトで必要になって調べた技術や読んだ書籍についてメモしていく場です。誰かの役にたったらいいなくらいのものです。最近の関心事は、「スクラム」「アジャイル」です。

「アジャイルソフトウェア開発の12の原則」を知っておこう

アジャイル開発関連の初心者向けの研修とかに参加すると必ずといっていいほど、割と最初の方で、↓の「アジャイル宣言の背後にある原則」が紹介されるのではないだろうか、、

  

アジャイル宣言の背後にある原則

f:id:jun_higuchi:20190629233958p:plain

 

スクラムのことがある程度理解できて来た今、改めて読み直してみると、これは超大事ね!!今までちゃんと読み直すことなかったので、今回改めて読み直してみようと思ったわけです。

 

①「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。」

早く継続的に、価値のあるもの(小さな単位でOK)を提供することにより、顧客からの信頼を得ることを狙いとしてるのでしょうね。さらに、フィードバックを得ることもでき、お客様側の要求に向き合えることが期待できます。

 

②「要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。」

 スコープ(開発する範囲、機能要求)を柔軟にしておくことが大事。ただ、お客側からのユーザストーリー(要求)を追加するのではなく、それを追加した上で、優先順位を決めて直してもらうことが重要でしょう。そして、予め、優先順位を下にしたものについては、(開発費用と期間の追加など検討しない限りは、)最悪、入らないという事も伝えておき、コミットしておいて貰わなければならないでしょう。

 

③「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。」

動くソフトウェアを素早く作り、短い感覚で定期的に見てもらいフィードバックを得ることで、例え方向性がずれていたとしても、すぐに軌道修正することができます。

 

④「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。」

ビジネス側と開発側の人が一緒に同じ場所で働くことで、「問題があってもすぐ直せる」「意思疎通にあたっての摩擦も減る」「信頼関係も築きやすい」などの理由から、チームの生産性が確実に上がると言われてます。

 

⑤「意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。」

意欲的な人でチームを構成すべき、そして、 意見を尊重し、信頼してあげることが大事ということですね。

 

⑥「情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。」

従来だと、中間ドキュメントを作成し、次工程に繋いでたのでしょうが、これだと、「そのドキュメント作成にコストが掛かる」「伝達スピードが遅い」など欠点も多く、非効率ということです。向かい合って話しして、解決させてしまうことこそが効率的であると言っているのでしょう。

 

⑦「動くソフトウェアこそが進捗の最も重要な尺度です。」

『いざ動かそうと繋いで見た時に、全く動かないとか、想定した動きをしない。』などそういった経験はないだろうか?そして、原因を調べて見ると、『認識合わせを行っていなかったIFが発覚した』などといった経験はないだろうか?そういった場合、当然、設計からやり直しになるわけですよね。

つまり、何を持って「完了」とするかというと、動くソフトウェアまで作って、それを完了そすることが最も進捗の尺度としての信頼性があるという事ですしょうね。

 

⑧「アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。」

ある期間だけ、爆発的に可動を上げるとかではなく、一定のペースを継続し続け、短期間かつ定期的にリリースして、毎週(または2、3週など)、どの程度終わらせたかを記録しておくことで、先の見通しも立てやすくなります。

 

⑨「技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。」

技術力を磨く時間や、多少時間を取ってでも分かりやすいコードや設計を保つとか、リファクタリングする時間を惜しまない事が、後に高い機敏さにつながる。といっているのでしょう。なので、こういった時間は、ぜひどんどん取っていきたいですね。

 

⑩「シンプルさ(ムダなく作れる量を最大限にすること)が本質です。」

これ、意味わからなかったので、原文見てみると、「Simplicity–the art of maximizing the amount of work not done–is essential」となっていました。

和訳すると、「シンプルさ(ムダな仕事を最大化すること)が本質です。」という事ではないでしょうか、、つまり、ムダな事はしないという事。ここでいう「ムダなこと」とは、リリースしても使われない機能や、作業の引き渡しにのみ使われるような資料とかで、そういったものを作らないように最大限努力しようということかと思います。

 

⑪「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。」

現場主義でやっていくということですね。ただ、実際、自己組織的なチームを作るためには、Howについて決める権限を確実に委譲し、成果に対する責任を果たそうという動きにしていかなければならない。

 

⑫「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。」

 定期的に、例えば、毎週○曜日にとかでしょうね。その単位で、チームがもっと効率を高めることができる工夫は出来ないかを、チームメンバーに出してもらい、それに基づいて、やり方を変えて行こうということですね。

 

---

っと、ここまでは私自身が読んで思ったこと書いただけなのですが、

↓のIPAが作成した資料を見つけまして、とてもわかり易かったので是非読んでみてほしいです。

https://www.ipa.go.jp/files/000065601.pdf

 

 

 

 

 

プライバシーポリシー お問い合わせ