【システムアーキテクト】平成30年度 午前Ⅱ 問13 スプリントレトロスペクティブ
お疲れさまです。egatti (エガッティ)です。IT 女子のブログです。
egatti ハンコを彫りましたが、ほっぺたの「ぽっ」の部分が一個欠けました。ホント残念です。ハイ。
本文と全く関係なくてごめんなさい。
今日は、社内勉強会のために調べた内容が、資格試験で役に立った話。
ま、不合格でしたけどね。
10月初めに、社内の勉強会でアジャイル開発っていうのを取り上げました。
ソフトウェアの開発には、いくつかの手法があります。
設計や、製造、試験などを含む、プロジェクトの進め方のお決まりパターン。
開発手段の知識は、システム開発する人やマネジメントする人たちだけではなく、営業する人や、システム化を考えている会社の方、つまりシステム屋さんにとってのお客様にも、役に立つものです。
今日は、そのソフトウェア開発手法を紹介しつつ、平成30年度 システムアーキテクト試験 午前Ⅱの 問13 の答え合わせをします。
ソフトウェア開発手法
王道「ウォーターフォール」
水(ウォーター)が、落ちる(フォール)ように、後戻りすることなく、上から下へ順序良く進めていく手法。顧客の要件を最初に決めて、設計、製造、試験を、一個ずつ確実に終わらせてから、次へ進みます。
お試し版「プロトタイプ」
試作品を作って、早めに顧客に見てもらう手法。ウォーターフォールでは、長い年月かけてできたシステムが「思ってたんと違う!」っていう悲劇が起きやすいので、その予防策。
繰り返す「スパイラル」
プロトタイプの進化版。設計、製造、試験、評価を1セットとして、一つのシステムに対して開発を繰り返す手法。プロトタイプを活用して、顧客の要求をより早く、より多く引き出そうという目的があります。
俊敏合理主義「アジャイル」
システム化がどんどん進んで、今やビジネスはスピードだ!という時代に合わせて、システム開発も、すばやくスマートにやろうよ!とうことで登場したのが「アジャイル」です。イテレーション(反復)と呼ばれる短い開発期間を繰り返していきます。イテレーションの中で、設計、製造、試験、評価を一通り行うところは、「スパイラル」と同じです。違いは、1回のイテレーションで、リリースまで行うこと。つまり、1つの機能の完成品を作ります。次のサイクルでは、また別の機能を作ります。
アジャイルの特徴
「アジャイル」開発の特徴は、こんな感じ。
- 顧客とエンジニアで(小さな)共同開発チームを作る。
- 開発全体を小さく分割して 優先度の高いものから作る。
- 1回のイテレーションは 2週間~1ヶ月程度。
- 1回のイテレーションで 設計、実装、試験、リリースを行う。
アジャイルのメリット
得られるメリットは、こんな感じ。
- 顧客を巻き込むので 要求の漏れや認識違いなどがない。
- 優先度の高いものから作るので 無駄な開発がない。
- 小さな単位で作っていくので 仕様変更や軌道修正しやすい。
- チーム内で 全工程を担当するので ドキュメントの削減が可能。
- チーム内で 全工程を担当するので メンバーのスキルアップが期待できる。
アジャイルの不安
不安、というか、アジャイル開発ができる条件のようなものかな。
- 全工程を担当できるエンジニアが必要
- 顧客(仕様決定できる人)がチームとして同席できる
- メンバーは アジャイルに理解があり スキルアップや課題を共有・解決することなどに対して前向きな人でないと厳しい
- 変更、つまり手戻りにくじけないココロが必要
成功事例
一番、わかりやすい例が「Facebook」ですかね。
アジャイル開発の海外事例:Facebook・Spotify・Paypal - CTO for good
「完了は完璧よりも素晴らしい」Facebookのマーク・ザッカーバーグCEOが口にした言葉と言われています。完璧を追求して完成が遅れるよりも、早い段階で完了の状態まで持っていき、市場の反応を確認した方が良いという、Facebookの文化です。これはまさにアジャイル開発の精神に合致していると言えるでしょう。
日々、機能が追加されたり、改良されたかと思えば、いつのまにかなくなってる機能もある。実際に使ったユーザの反応を見て、イマイチ機能は容赦なく切り捨てる。どんなに苦労して開発した機能でも、です。それが、刻々と変化する市場と同じスピードで開発しようという、ザ・アジャイルな開発ってことですね。
アジャイル開発宣言
アジャイルの基本。
プロセスやツール よりも 個人との対話 を、
包括的なドキュメント よりも 動くソフトウェア を、
契約交渉 よりも 顧客との協調 を、
計画に従うこと よりも 変化への対応 を、
価値とする。
すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
重要のなのは、最後の一文です。
左記のことがらが不要なわけではないのです。
プロジェクトマネージャのみなさん、「アジャイルって、設計書を書かなくていいんでしょ?」は間違いです。
エンジニアのみなさん、「アジャイルだからって、設計をせずに製造とかありえん!」は間違いです。
【アジャイル開発手法】スクラム
詳しくは省略しますが、ざっくりキーワードをご紹介。一番、よく聞くのは「スクラム」ですね。
- リリースプランニング(プロダクトバックログで管理する)
チーム全員で、どんなプロダクトをどんな優先順・期間で開発するか計画する - スプリントプランニング(スプリントバックログで管理する)
チーム全員で、ひとつのイテレーションでどの機能を実現するかを計画する - スプリント(イテレーション開発)
ひとつのイテレーション機関の開発フェーズのこと - デイリースクラム(朝会)
毎朝、短時間の朝会をやって、今日やることや課題を共有する - スプリントレビュー(デモ)
ひとつのイテレーション期間で完成したプロダクトを、ステークホルダ(顧客を含む関連する人みんな)を集めてデモを行う - ふりかえり
毎スプリント終了時に、良かったこと、問題点、今後トライしたいこと(KPT法が用いられることが多い)を話し合い、次へつなげる
駆け足で紹介を続けますよ。
詳しいことはググろう!
【アジャイル開発手法】XP(エクストリーム・プログラミング)
「変化に対応」するため、柔軟なプロジェクトの仕組みが必要です。まずは、XPで重要とされている「5つの価値」です。
5つの価値
- コミュニケーション
- シンプルさ
- フィードバック
- 勇気
- 尊重
19のプラクティス
XPで定義されているプラクティスを紹介します。取り組むべき活動、といったところでしょうか。ピックアップして補足を書いています。
共同のプラクティス
- 反復
- 共通の用語
- オープンな作業空間
- 回顧
開発のプラクティス
- テスト手動型の開発
→ 実装より先に、自動化されたユニットテストを作成。開発が進んだあとで変更があっても、自動化されているから、試験のやり直しが楽。 - ペア・プログラミング
→ 二人一組で実装。一人がコードを書いて、もう一人は横でチェックしながらナビゲートする。役割は交代しながら進める。密なレビューが可能で、スキルアップにもなる。 - リファクタリング
→ 完成済みでも、必要があれば、内部構造や内部処理を改善する。先を見越した共通化が必要がなくなる。再テストも自動化されているはずなので問題ない。 - 集団的な所有権
- 継続的インテグレーション
- YAGNI
管理者のプラクティス
- 責任の受入
- 援護
- 四半期ごとの見直し
- 持続可能なペース
顧客のプラクティス
- ストーリーの作成
- リリース計画
- 受入テスト
- 頻繁なリリース
アジャイルには、他にもいろいろなプラクティスやノウハウがあります。プロジェクトの規模やメンバーの特性、顧客の要望に合わせて、よりよい開発を行っていきたいものですね。
はい、ようやくここまできました。
それでは、どうぞ、問題です。
【システムアーキテクト】平成30年度 午前Ⅱ 問13
問題
スクラムを適用したアジャイル開発において、スクラムチームで何がうまくいき、何がうまくいかなかったのかを議論し、継続的なプロセス改善を促進するアクティビティはどれか。
ア スプリントプランニング
イ スプリントレトロスペクティブ
ウ スプリントレビュー
エ デイリースクラム
はい、きた!アジャイル、勉強したばっかりだよ!えーと、なになに? 議論し、プロセス改善を促進する・・・
んー?
「ア スプリントプランニング」は、計画だから論外で、「イ スプリントレトロスペクティブ」・・・なんじゃそら!聞いたことない!しかも、「レトロ」て。「ウ スプリントレビュー」は近いような気はするけど、レビューはあくまでプロダクトに対してだし、「エ デイリースクラム」は確かに課題を共有したりはするけど、なぜ?みたいな議論じゃなくて、短時間の朝会のことだし・・・。意味合いとしては「ふりかえり」のことだと思うけど(既述の「スクラム」を見てね!)選択肢にない!うーん、これは、消去法で「イ スプリントレトロスペクティブ」を選ぶしかない!
正解は?
「イ」!
よ、良かったぁ!
スプリントレトロスペクティブ とは
やはり「ふりかえり」のことでした!
もう疲れたので、リンク貼ります。笑
アジャイルなレトロスペクティブのすすめ – ゆうれい船長 – Medium
「レトロスペクティブ」は「回顧」という意味なんですね。スプリントのふりかえり、そのままですね。覚えやすいっちゃー覚えやすい。
ま、不合格でしたけどね。
(うわー、暗い。)
では、また。