エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
BackendチームとFrontendチームとアジャイル|qsona
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
BackendチームとFrontendチームとアジャイル|qsona
話があんまりまとまってないけどとりあえず出す。 職能型組織とその弊害ある程度大きい Web プロダクト... 話があんまりまとまってないけどとりあえず出す。 職能型組織とその弊害ある程度大きい Web プロダクト開発の現場 (例: エンジニアが全部で20人) において、その内部が Backend チーム / Web Frontend チーム / iOS チーム / Android チームみたいにサブチームとして分かれていることは実際よくあることだと思う。 アジャイル開発の文脈だと、基本的にこういう分け方はあまりよろしくないとされる。この分け方だと、それぞれのチームに閉じてユーザーストーリーを満たす開発ができない。そうすると、本番環境に機能を出してユーザーに使ってもらうには、複数のチームにまたがってタスクの優先度を合わせたり、複数のチームの成果物をつなぎこんだりする必要がある。そうするとチームをまたいだ調整が必要になり、チームの自律性が下がる。 そうではなくて、例えばフィーチャーごとにチームを作り、