スクラムお疲れ様です!まっちゃんです。みなさま、ハロウィンはいかがでしたでしょうか?お菓子もらえました?弊社ではクッキーと飴がカフェエリアにて配布されました。その他には部署の会議で配布されたお菓子をひたすら食べてました(体重が戻ってしまう......)本日は開発内容を小さくし、レビューサイクルを素早く回すブランチ戦略に取り組んだ話について書いていきます。現在自分が所属しているチームのエンジニア構成は下記の通りです。初級者(ジュニアエンジニア)中級者(シニアエンジニア)については下記記事に書いています。通して、いろいろ学んでほしいと自分は思っているのですができていない状況が続いていました。下記は、個人でも思ったこと、チームでのふりかえりで上がった問題点です。問題のポイントは「量が多いこと」「問題発覚が遅いこと」だと仮説を立てました。「量を少なくする」ことで「問題発覚を早くする」に繋がるのでないかと考えました。アクションを起こさねばと思い、チームに「開発内容を小さくしてレビューしよう」と言いいました。「featureブランチを細かく切り、都度マージリクエストを作成することで小さくできる」と思ったのでこれをベースに考えてみます。下記の記事で書いた時にやってみました。blog.engineer.adways.net実際にやってみる元々のブランチ戦略は「masterからfeatureを切り、masterへのマージリクエストを作成する」というものです。masterのマージリクエストをコードレビューとして見ます。「featureブランチを細かく切り、都度マージリクエストを作成することで小さくできる」を表したブランチ戦略が下記です。一言で言うと「子(孫)featureブランチを作成する」これだけです。赤い線がコードレビューコードレビューが増えていますが、その分量は少ないため、細かくレビューができています。レビューの回数も増えるので問題発覚のサイクルが早くなりました。マージする時にsquashでまとめるレビュー依頼が増え、チャットが乱立レビュー漏れはSlackのスタンプを付けて管理をしているまとめ細かいサイクルでレビューが可能になり、問題発覚も早くなりました。他の開発案件でも行っていますが、現状のチームだとこの取り組みは合っていると思います。最後に、ポイントはチームの状態だと思ってます。チームが成熟していたり、レベルが高ければこのような施策は取らなくても品質は担保できると思っています。16:00開発内容を小さくレビューサイクルを早め、結果開発スピードを早めるブランチ戦略を考えて取り組んでみたTweet関連記事2019-09-13チーム目標「共創」を実現するために、社外向けレポート刷新に取り組んだ話お疲れさまです。CIの実行速度を上げるこんにちは、弓場と申します。前まではKubernetesのyamlフ...2019-06-28使われるモノを作るためにARRRAを採用したお話こんばんは。(1)ABOUT株式会社アドウェイズのエンジニアによるブログです!このブログでは、アドウェイズのエンジニアがざっくばらんに技術のことや日常生活について書いていきますので、みなさんよろしくお願いいたします。アドウェイズ中途採用情報スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。