Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationEventAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
32
Help us understand the problem. What are the problem?
Organization

チーム開発を倍速にする方法6選

開発速度が求められるスタートアップで培った、
リリースの間に合うように開発を上げる方法を共有します❗️

発注者との認識の差を埋める編

1. 機能単位で工数を出す

機能単位(1PR単位)で、
何時間かかるかを書き出します。
工数を出すとスケジュールを立てやすくなります。

例. 140h(開発に必要な工数) / 32h(かけられる工数/週) = 4~5週間

簡単な見積もり例↓
(感覚的に見積もっているので、実際に稼働した時間と比較して調整していきます)
image.png

2. リリーススケジュールは悲観的パターンと楽観的パターンを用意する

早く終わるパターンと時間がかかってしまうパターンの2つのリリース日を設けます。
時間のかかってしまうパターンでは1.2~1.5倍くらい多めに時間を確保します。
リリース日は進捗状況によって変化しますよと伝えることができます。

image.png

いつまでにリリースできるかを説明する必要があるので、
クライアントがいたり投資家にリリース日を伝えなければならない時は、リリーススケジュールを立てられると便利です。

image.png

開発速度を上げる編

3. Biz側が確認しやすいように、機能開発用(ex. feature-develop)のブランチを切る

コミュニケーションコスト、チェックしてもらうまでの待機時間を減らすために
チェックをまとめて行うようにします。

機能専用のブランチ(feature-develop)を作成し、PRをmergeし、
どこかのタイミングでbiz側にチェックしてもらいましょう。

image.png

4. 開発担当者にタスクを渡すときにはPR(下書き・インターフェース)を作成してから渡す

PR(コードの下書き・インターフェース)を作って渡すと、
担当開発者との仕様の認識のずれる対策ができるのと、開発者がすぐに実装を移ることができます。

これらの問題を解決するために、
PRを作って、期待するアウトプット、変更対象のファイルにマーキングしておくのがおすすめです。

5. 変更対象のファイルにマーキング

image.png

最終的なアウトプット

image.png

5. リリース後に実装でもいい機能を洗い出す

目的とずれている機能や設計途中でおまけで追加されたような機能は、
書き出してリリース後にまとめて着手します。

なるべく早くリリースすることを目指します。

6. コードレビューは行わない

コードレビューを行う時なるべくコードを提示するようにします。
それか、お互いの合意が取れていればレビュアーが修正してpushします。

pr上でコメントの往来があると、
とても時間がかかるので時には避けるのも一つの手です!

以上です!

  • その他にも色々情報発信しているのでぜひフォローお願いします! @sagae_kig
  • 開発をブーストするプラットフォームISSUEもよろしくお願いします!
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
32
Help us understand the problem. What are the problem?