Official Blog

  • ディレクター

    スクラム開発取り入れて行こうぜ!

    投稿者アイコン

    GEEKstaff

    投稿サムネイル
    この記事はGEEK Inc. Advent Calendar 2017の14日目の記事となります。
    みなさんこんにちは。
    ディレクターの佐々木です。
    最近原因不明の貧血が起こるので、体調にはより気を配っている28さいです。
     
    背景
     
    今回のテーマは「スクラム開発取り入れて行こうぜ!」です。
    夏にフェーズ1をクロージングしたプロジェクトの反省を兼ねてアジャイル開発の手法について色々と調べてみました。
    中でも「スクラム開発」についてとても感銘を受けたのでご紹介したいとおもいます。
     
    参考著書:
    『SCRUM BOOT CAMP THE BOOK』
     
     
    アジャイル(スクラム)開発とは?
     
    従来の開発:
    あらかじめ全ての要求を抽出し、それらを全てを作るにはどのくらいの期間がかかり、どのくらいの人数が必要で、どのくらいのコストがかかるかを見積ってから開発を進めるスタイル。
     
    アジャイル開発:
    「事前に全てを正確に予測し、計画することはできない」という前提で、おおよその全体像を明らかにし、開発期間と開発人数を決める。また、その範囲内で重要なもの、リスクの高いものを先に作る。重要度の低いものは後回しにすることで設計に必要以上の時間をかけないように開発を進スタイル。(考えかたとしてはMVPプロセスに近い)
     
    ルール
    – 要求を常に順番に並べてその順にプロダクトを作ることで成果を最大化する
    – 固定の短い時間に区切って作業を進める(タイムボックス)
    – 現在の状況や問題点を常に明らかにする(透明性)
    – 定期的に進捗状況や作っているプロダクトが正しいのか確認する(検査)
    – やり方に問題があったり、もっとうまくできる方法があれば、やり方そのものを変える(適応)
     
     
    プロダクトバックログ
    1番目に欲しい機能
    2番目に欲しい機能




    常にメンテナンスして最新に保つこと。
     
    プロダクトオーナー
    [主な役割]
    – プロダクトオーナーとはプロダクトの責任者のこと。(チームに1人)
    – ビジョンの共有
    – 予算管理
    – リリース計画
    – プロダクトバックログ管理
     
     
    開発チーム
     
    機能横断的なチームが理想。
    例えば、チームには要求の分析、設計、コーディング、サーバー構築、テスト、ドキュメント作成といった能力が必要だったとする。これらをそれぞれ特定のことしか行わない専門のサブチームは作らない。
    メンバーごとに能力の差はあったりするが、作業を進めていく過程でなるべく個々が複数のことをできるようになることが望ましい。
    また、開発の進め方は開発チームのメンバーの合意のもとで進められる。外部(プロダクトオーナー)から仕事の進め方を指示されることがあってはならない。あくまで開発チーム全体で責任を持って進める。これを自己組織化されたチームと呼ぶ。
    開発チームで主体的に作業を進めることによって、開発チームの能力を継続的に向上させていく。
     
     
    スプリント
     
    短く区切って繰り返す。
    スプリントの期間は固定する(期間が変動してはいけない)
    開発チームはこの期間で計画、設計、開発、テストなどプロダクトリリースの判断に必要な全てのことを行う。
    このように固定の期間に区切って開発を繰り返すことで開発チームにリズムができて集中しやすくなる。
    原則、スプリント最終日に作業が残っていてもスプリントは終了し、期間は延長しない。(え!?ほんとに!?)
    プロダクトオーナーの判断によってのみ途中で終了することができる。(なるほど)
     
    例えば、1スプリントが5週間の場合…
     
    1週間目:仕様詰め、プロトタイプ
     
    2週間目:デザイン
     
    3週間目:実装(フロント、バック)
     
    4-5週間目:テスト、デバッグ
     
    最終日:受け入れ
     
    のようなスケジュールになる。
     
     
    スプリント計画
     
    「1番目に欲しい機能」をさらに細分化し、具体的なタスクに分割する。その際に優先度をつけておくことによって間に合わない場合プロダクトオーナーと相談し、タスクを外したり実装方法を検討したりする。
     
    作業する人自身がタスクの選択をする。
    注意しなければならないのは、開発チームは全ての作業に全力を尽くす必要はあるが、必ず全て完了させることを約束しているわけではない。見積もりが外れたり、難易度が高かったり、不測の事態が発生した場合、開発チームが長時間残業したり必要な作業を省いてしまうという悪循環になってしまうため。
     
     
    完了の定義
     
    「完了」の定義は「品質基準」とも言い換えることができる。
    何を持って「完了」とするかは全員で共通認識を持っておくことが大事。
    メンバーはプロダクトオーナーにチェックを投げるのではなく、実際に一緒に動かして機能の説明をする。
     
     
    毎日状況を確認
     
    開発チームは毎日、同じ場所、同じ時間に状況を確認する15分ほどのショートMTGを開く。(デイリースクラム)
    ここでは以下のことを共有する
    – 前回のデイリースクラムからやったこと
    – 次回のデイリースクラムまでにやること
    – 困っていること
    開発チームによっては進捗状況を可視化することもある。
     
     
    まとめ
    – スピード感ある開発で効率的な進め方だと思う。ただ、複数プロジェクト並行している場合は難しそう。
    – チーム力が問われる。(社内だけでなく、クライアントを含めた全員)
    – クライアントワークよりは自社開発の方がコントロールしやすそう。
    – もう少し他の事例なども読んでみる。
    – チーム全員が手法を理解しても実践し、効果を発揮するまでにはコストはかなりかかりそう。(それでもやってみたい!)
     
    以上です。
    次はマークアップエンジニアの大山さんにバトンタッチします!

    最新の技術と手法を用いて、
    IT分野で変化と進化を続ける
    Webインテグレーター

    神田北信ビルエントランス

    株式会社GEEK 〒101-0033
    東京都千代田区神田岩本町4-4 神田北辰ビル3F

    CATEGORIES

          上矢印マークアイコン Go To Top