スクラム開発の資料はネットにも挙がっています(*`･ω･´)ゞ
アジャイルソフトウェア開発宣言
画像は、当時のプロジェクトに携わっていた私が、業務外での自習の際に作成したものです(´∀｀; )
ウォーターフォール開発では、以下に価値を置いています。
- プロセスやツール
- 包括的なドキュメント
- 契約交渉
- 計画に従うこと
アジャイル開発では、以下に価値を置いています。
- 個人と対話
- 動くソフトウェア
- 顧客との協調
- 変化への対応
ただし、アジャイル開発もウォーターフォール開発も、異なる価値を下だと考えているわけではありません。アジャイル開発でもプロセスやツール、包括的なドキュメント……に価値があることを認めています。
ここで少しだけ補足です。
ネットでは時としてウォーターフォール開発とアジャイル開発のどちらが上か下か討論が始まることがありますが、実際は上も下もありません。
ウォーターフォールにせよアジャイルにせよ、プロジェクトに向いた開発手法があるというだけですね。
アジャイル宣言の背後にある原則
アジャイル宣言の背後にある原則については、該当文を引用して説明しますね！(*`･ω･´)ゞ
顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
アジャイル開発は継続的にリリースします。短い時間感覚でリリースするため、変化に対応できなければなりません。
ただし急激な変化は良くないです。チームの様子を伺いながら変化を促していきましょう。
タックマンモデルのステージ3「統一期」のように案件がうまくいくようになったときにも、チーム全体変化し続ける必要があります。
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
アジャイル開発及びスクラム開発では、個人の成果ではなくチームの成果を重視します。スクラムチームが複数あるなら、チーム外の成果を上げるための手助けも必要です。
スクラムチームのメンバーは、PO、SM、開発メンバーの、どのロールだろうと平等です。
POがチケット(案件)を持ってきて、開発メンバーがチケット(案件)を対応するため、特にウォーターフォール開発に慣れた開発メンバーにとってはPOを上の立場だと思ってしまいがちですが、POも開発メンバーも立場は平等です。(SMがいるのは、POと開発メンバーに力差が生まれないようにするためでもあります)
プロジェクト中、様々な課題と遭遇しますが、チームで協力し合って乗り越えます。以下に問題例と対策を2つ挙げてみます。
開発メンバーのAさんが今Sprintで対応できないサブチケットを持っている。
【対策】
手が空いた他の開発メンバーが自主的にAさんの代わりにサブチケットを対応する。
※Sprint＝一定量の開発作業の目的・目標を完了させるまでの、短く区切られた期間。
POが優先度の高い差し込みチケットを持ってきたが、今差し込まれると既存チケットの対応が難しい。
【対策】
SMがPOから開発チームを守りつつ、優先度が高いチケットを対応するため、優先度の低い既存チケットを次回以降のSprintに回す相談をする。
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル開発はコミュニケーションを重視しています。
報告・連絡・相談はもちろんのこと、口頭コミュニケーションやテキストコミュニケーションも積極的に取ります。
スクラムチーム内の声かけは開発メンバー同士で行なえるのが理想ですが、チームが育つまではSMがフォローに回ることもありです。ただしゆくゆくはSMがいなくても開発メンバーで自主的に動けるようにするため、SMが口を出さず静観したり助言だけを投げることも必要です。
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
アジャイル開発では常に変化していくことを意識します。
どのロールだろうと変化を意識し進化し続け、自己組織的なチームを目指します。
優秀なスクラムチームだと、SMは不要です。
最初こそSMが開発メンバーの代わりに何かを対応することも多いですが、開発メンバーがSMの代わりにやっていいことはたくさんあるので、気兼ねなく質問してみましょう。
開発メンバーとSMの関係性は重要です。
SMはサーヴァントリーダーシップを意識してスクラムチームのチームビルディングに貢献しましょう。