「 スクラム 」 一覧

スクラムを初めて3ヶ月たったので振り返る スクラムについて スクラム (ソフトウェア開発) – wikipedia スクラム（英: Scrum）は、ソフトウェア開発における反復的で漸進的なアジャイルソフトウェア開発手法の1つである。この方法論は「柔軟かつ全人的なプロダクト開発ストラテジーであり、共通のゴールに到達するため、開発チームが一体となって働くこと 一定の周期で計画会議→開発（スプリント）、スプリントレビュー、クロージング（振り返り、リリース）を繰り返すことが大事 スクラムを始めたきっかけ 前まで マネージャーの管理コストが高い 開発メンバーが今なにやってるかを把握するのが大変 リリースサイクルが決まっていない為開発、営業、運用の連携が困難 開発したものが放置されやすい 突発的な開発対応に追われる 開発者は言われたものだけをひたすら開発するというサイクルになりがち スクラム体制後 マネージャーの管理コストが下がる 開発チームがなにやってるかを把握できる リリースサイクルが決まる為営業、運用、開発の連携がしやすい 品質が上がる 振り返りによりチーム力が上がる 開発が考えるシナリオを推進することができる 開発チーム個々が自発的に行動できる デメリット 運用などの担当者が必要で担当者がかたよる スクラム体制について 1スプリント2週間、クロージング1週間とする プロダクトオーナー スクラムマスター（自分） 開発チーム4人 ミドルエンジニア 若手ベトナムエンジニア 新卒ベトナムエンジニア 新卒エンジニア スプリント振り返り 1月中旬から始めて3スプリントを実施した。 スプリント1（1/16〜1/27） 機能概要 データ解析+グラフ化 Good/Keep 設計レビューにより実装前の軌道修正ができる 開発チーム+スクラムマスターのレビューにより各自の実装の認識をあわせる プロダクトオーナーレビューにより更に違った目線からの指摘があり最終的な実装の認識をあわせる 設計段階で認識を合わせることにより品質があがる為トータルコストがよい 画面を伴う機能は特に設計レビューによる効果が大きい 設計レビューでアウトプットの認識があうのでビジネスへのアプローチがしやすくなる テスト環境すら整ってない新卒エンジニアがモックテストまでできるようになった 局所的なハンズオンやペアプロは効果が高い スクラムは各自のスキルアップに効果的 Problem プロダクトオーナーとスクラムマスター以外がスクラムの取り組みにおいて受動的 ドキュメント・テストケースの書き方の各自の認識が違う Trelloの更新がうまくできなかった JavaScript処理が複雑 Try GitFlowに切り替えるにあたりバージョニングを検討した セマンティックバージョニングにしたかったがメンバー全員に周知し徹底することが難しいと判断し文字列でタグ付けすることとした チームメンバ全員がモックを使ったPHPUnitが書けるようになったので全員UTを書く開発体制にした ドキュメントの書き方の認識をあわせた JavaScriptの構成やフレームワーク変更を検討する スプリント2（2/6〜2/17） 機能概要 画面レイアウト変更 レポート系 Good/Keep クロスブラウザ・端末テストなどマンパワーを要するテストをみんなで分担してできる為テストが楽で早く終えられる チームメンバー全員がモックテストがかけて開発コードのほとんど（不要な部分は除く）のカバレッジをカバーできている 設計レビューの恩恵 要件定義時に認識があっていたと思っても設計すると認識がずれていたりするがレビューの中で最適な解を見つけることができる 実装前のレビューで懸念点をつぶしてながら設計できるのが気持ちいい 実装前にの実装イメージが具体的に湧く為テストが書きやすい 設計後実装の分担をするとテストを先に書けるケースが出てくる 開発チームが各自自発的に行動するようになった Problem ドキュメント作成に時間がかかる コーディングスタイルの指摘が多い 最初に作成したスプリントバックログの作業量をオーバーした タスクの粒が大きいと初日のスプリントバックログ作成の時間だけでは正確な見積もりができないことがわかった Try 計画会議とプロダクトバックログ作成を1日で実施した 翌日以降の個人の動きが明確になり個々人が個別に自主的に動ける デイリースクラムにスクラムマスターが参加しないようにした コードフォーマットチェック(php-cs-fixer)をgitのpre-commitに導入した php-cs-fixer導入参考ブログ WIPを導入した 次回以降はもっとIF・クラス設計に重点を置いて開発する方針にした スプリント3（2/27〜3/10） 機能概要 機能の外部埋込プラグイン Good/Keep 失敗覚悟でギリギリのベロシティのタスクを設定したところ色々新しい課題がみえた 開発メンバ各自の実機テスト環境を改善した 既存バグの修正ができた 課題 タスクの難易度があがるとコミュニケーションコストがかなり高くなる 受け入れ条件の範囲を超えた作業をした為余計に時間を費やした 2週間という期間にしばられて品質を落とす形になった コミュニケーションコストを見積もりに入れてなかった …

スクラムを初めて約3ヶ月がたったので取り組み内容を簡単にまとめてみました。 参考にした文献 SCRUM BOOT CAMP THE BOOK Amazonより スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus) Amazonより ジョイ・インク 役職も部署もない全員主役のマネジメント Speakerdeck：スクラムの取り組み 参考書籍 SCRUM BOOT CAMP THE BOOK Amazonより スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus) Amazonより ジョイ・インク 役職も部署もない全員主役のマネジメント