「それでは、アジャイルスクラムについてお話したいと思います。」

「21世紀初頭、人々のプログラミングに対する考え方は一変しました。」

「誰もが長期計画はうまくいかないと確信していたので、それを完全に放棄することに決めました。」

「彼らはどうやってそんなことをしたのですか?」

「その方法は次のとおりです。」

「彼らは可能な限り最も柔軟なプロジェクト管理アプローチを発明しました。」

アジャイル開発の背後にある主なアイデアは次のとおりです。」

  • 人とコミュニケーションはプロセスやツールよりも重要です。
  • 実用的な製品は、完全なドキュメントよりも重要です。
  • 顧客と協力することは、契約条件を満たすことよりも重要です。
  • 最初の計画に固執するよりも、変化する意欲の方が重要です。

迅速な開発の原則は次のとおりです。

  • 価値あるソフトウェアを早期かつ継続的に提供することで顧客を満足させる。
  • 開発の終了時であっても要件の変更を歓迎します (これにより、最終製品の競争力が向上する可能性があります)。
  • 動作するソフトウェアを頻繁に (毎月、毎週、またはそれ以上の頻度で) 配信します。
  • プロジェクト全体を通じて、顧客と開発者の間で毎日緊密なコミュニケーションを図ります。
  • プロジェクトは、必要な労働条件、サポート、信頼を与えられた、やる気のある個人によって取り組んでいます。
  • 情報を伝達するための好ましい方法は、個人的な (対面での) 会話です。
  • 動作するソフトウェアは進歩を測る最良の尺度です。
  • スポンサー、開発者、ユーザーは、無期限に一定のペースを維持できる必要があります。
  • 優れた技術とユーザーフレンドリーなデザインの向上に常に焦点を当てます。
  • シンプルとは、余分な仕事をしない芸術です。
  • 最高の技術要件、設計、アーキテクチャは自己組織化されたチームから生まれます。
  • 変化する状況への絶え間ない適応。

「ソフトウェア開発の主な問題は、どの段階においても、何をすべきかについての完全な情報を参加者が誰も持っていなかったことです。」

「顧客はプログラムについてどのように思い描いているかを伝えることができますが、何かを省略したり、何かを当然のことと考えたりするでしょう。」

「マネージャーは通常、要件をプログラミング専門用語から顧客の言語に翻訳し、またその言語に翻訳し直す​​必要があります。」

「不確実性が多すぎる。」

「多くの場合、顧客の要件は次のようなものです。何らかの方法で実行してから見せてください。気に入らない場合はやり直してください。」

「うーん…それはひどいですね。」

「新しいパラダイムによれば、プログラマーはもはや製品やプログラムを開発するのではなく、顧客が必要とする機能を実装することになります。」

「違いは何ですか?」

「そうですね、以前はプログラムの開発に 1 年かかったとします。そして、検討すべきものがなくなるまでに 6 か月かかりました。それは大きな家を建てるようなものです。最初に基礎用の穴を掘り、次に基礎を流し込みます。壁、屋根、トリムなどを構築します。」

「しかし今、プログラマーは必要な機能をできるだけ早くリリースしようとしています。これは、最初に小屋を建て、次にトレーラーハウスを建て、次に小さな家を建て、最後に大きな家を分割払いで建てるようなものです。」

顧客は自分が何を望んでいるのか正確にはわかっていない可能性が高いことを考慮すると、これは非常に合理的なアプローチです。」

「顧客が大きな狩猟小屋を望んでいるとします。」

「開発者たちは彼に小さな家を建てます。彼はそこで冬の間暮らします。そして彼は木造の家は好きではないと決心しました。レンガで家を作りましょう。」

「彼は夏の間湖の近くに住んでいますが、生きたまま蚊に食べられてしまいます。彼は湖は涼しいとどこかで聞いていたので、湖が欲しいと思っていました。でも今は湖が欲しいとは思っていません。そして、湖を作るのは簡単です。」この方法で家を建てます。湖がないということは洪水の危険がないことを意味し、高床式の代わりに地面に家を建てることができるので、25% 早く建てることができます。」

「興味深い例えですね。本当に顧客は要件をそんなに頻繁に変えるのでしょうか?」

「はい、でも問題は顧客ではありません。」

「まず、物事が将来どうなるかを想像するのは非常に難しいです。マネージャー、テスター、プログラマーも同様に同じことをします。彼らも物事の展開に応じて考えを変えます。」

「第二に、最も重要なのは顧客の要件ではないでしょうか? 結局のところこの仕事すべての要点は、顧客が最初に作成すると言ったものではなく、顧客が必要とするものを作成することです。」

「確かに、以前は次のように機能していました。ビジネス アナリストはすべての要件のリストを作成します。彼らはこのリストを契約書に含め、署名し、リストに従ってのみ作業を行いました。」

「顧客が本当に必要としているのに忘れていたものがリストに欠けていたとしても、誰もそれについて何もしません。」

「なるほど、計画を立てたほうが楽だけど、すべてが計画通りにできるわけではないんですね!」

"その通り。"

それがアジャイル開発手法が発明された理由です。

「そして今日は、その中でも最も人気のあるスクラムについてお話します。

「スクラムの主な特徴は、プロジェクト開発を小さなイテレーション (通常は 2 ~ 4 週間) に分割することです。各イテレーションはスプリントと呼ばれます。」

「スプリントの開始時に、スプリント計画会議が開催されます。会議は 3 ~ 4 時間続きます。」

「最後に、完全に完了したすべてのタスクのデモンストレーションが行われます。」

「通常、すべてがどのように機能するかは次のとおりです。」

「最初のスプリントの前に、顧客 (または顧客の代表者) は要件のリスト、つまりプログラムが実行できるべき一連のことを作成します。これらの要件は通常、 ユーザー ストーリー と呼ばれ、顧客は通常プロダクトオーナーに電話しました。」

「彼はプロダクトオーナーと呼ばれています。なぜなら、製品は彼のために書かれているからです。彼だけが、何を、いつ、どのような順序で要件のリストを定義します。」

「さらに、通常、プロダクト オーナーはタスクの優先順位を割り当てます。優先順位が最も高いタスクが最初に実装されます。要件のリスト全体は、プロダクトバックログとも呼ばれます。」

「スプリントが始まると、全員が会議に集まります。通常、チームのメンバーであるスクラム マスターが会議を主導します。会議の目標は、現在のスプリント (開発の反復) のタスク (ユーザー ストーリー) を選択することです。」 」

「まず、チームは各タスクに、ストーリー ポイントとも呼ばれる抽象工数での大まかな見積もりを割り当てます。 次に、チームは、スプリント中に完了する時間があるタスクの数を決定します。」

「繰り返しになりますが、スプリント中にどれだけのタスクを完了する時間が与えられるかを決定するのはチーム自体です。」

プロダクト オーナーはチームが最初の 7 つのタスクを選択することを期待していましたが、チームが 5 つだけを選択したとします。その後、タスク 6 と 7 は次のスプリントに延期されます。それがプロダクト オーナーに合わなければ、タスクの優先順位を上げることができます」 6 と 7 を選択して確実に選択しますが、そうすると他のタスクの一部がスプリントから外れてしまいます。」

スクラム マスターは、プロダクト オーナーをできるだけ満足させるために、いくつかのタスクを小さなタスクに分割し、それらに異なる優先順位を設定することを提案することもできます。」

「それが会議のポイン​​トです。タスクは変更したり分割したり、優先順位を変更したりできます。これは最初は目に見えなかった作業ですが、多くの価値をもたらします。」

「わかりました。車の運転のようなものです。最初はまっすぐ行けばいいと思っていても、現実には常に道路の穴を避け、右左にハンドルを切り、他の人を追い抜いたり、追い越したりする必要があります。」

「そうですね、そういうことですね。」

「スプリント用に選択されたタスクのリストは、スプリント バックログと呼ばれます。」

「プログラマは誰が何をするかを決定し、それから初めて仕事に取り掛かります。」 効率を向上させるために、スクラムでは、毎日 5 ~ 15 分間の会議を開催し、全員が昨日何をしたか、自分が何であるかを互いに話し合うことを提案しています。今日やります。」

「チームワーク。尊敬できる!」

「物事を視覚化しやすくするために、通常は現在のスプリント ステータスを特別なボードに表示することをお勧めします。」

アジャイル、スクラム、ウォーターフォール - 2

「左側の 3 つの列に注目してください。」

「タスクの短縮名が付箋に書かれます。そして、付箋はタスクのステータス (計画、進行中、完了) に応じて異なる列に配置されます。」

「右側に、バーンダウン チャートが表示されます。このチャートには、日ごとに、未完了のままのタスクがリストされます。理想的には、スプリント中に未完了のタスクの数がゼロになります。」

「スプリントが終了すると、スクラムマスターは完全に完了したすべてのリストを示すデモを行います。」

「その後、彼はスプリントの振り返りミーティングを開催します。これも数時間続きます。このミーティング中、参加者は通常、何がうまくいったのか、何が (そしてどのように) より良くできたのかを考えようとします。」

「通常、2、3 回のスプリントの後、チームの効率的な作業を妨げている主な問題を特定して取り除くことができます。これにより、チームの作業負荷を増やすことなく生産性が向上します。これはアジャイル手法の時代以前には不可能でした 

「スプリント中にグルーミング ミーティングが開催されることもあります。その目的は、次のスプリントを計画することです。参加者は通常、このミーティングでタスクの優先順位を明確にします。一部のタスクを部分に分割したり、製品バックログに新しいタスクを追加したりすることもできます

「そうですね、私が持っているのは基本的にこれだけです。これは単なる概要です。ほんの数語ですべてを説明するのは不可能ですが、このテーマに関する優れた記事をここで読むことができます。」

https://en.wikipedia.org/wiki/Scrum_(ソフトウェア開発)