「プロダクト間共通の React コンポーネントライブラリ」がどうなったか、という話 - SmartHR Tech Blog
こんにちは！ フロントエンドエンジニアの @diescake です！ 1 年程前に @nabeliwo よりこんな記事を公開しています。 tech.smarthr.jp 一言で要約してしまうと、SmartHR の各種プロダクトで一貫したユーザー体験を提供するために、SmartHR UI という React コンポーネントライブラリを実装し始めたよ！ しかも OSS として公開してるよ！ という話でございました。 github.com 本記事では、それから 1 年弱たった今 SmartHR UI がどうなっているか、という話をしつつ、現在の SmartHR UI の運用・開発体制について話をしてみようと思います。 SmartHR UI は成長しているよ！ 2019/08/01 2020/05/21 バージョン v3.9.2 v8.2.0 コンポーネント数1 30 66 ソースコード規模2 3
プロダクトオーナー
LeSSでのプロダクトオーナーは、基本的に 1team Scrumと同じです。しかし、規模拡大により視点が少し変わり、 常に全体像を意識しながら投資対効果(ROI)を最大化することが求められます。 LeSSのプロダクトオーナー 大規模開発では、様々な人が集められ、様々な分野に送り込まれてサブグループを作るため、部分最適に走ってしまうことがよくあります。LeSSでは、1人のプロダクトオーナーが1つのバックログをメンテナンスすることで、プロダクト全体思考を補助します。 大規模なプロダクトを扱う従来型のグループでは、外部に目を向けるグループ（たいていはプロダクトマネージャ）と内部に目を向けるグループ（たいていは開発者）の2つに別れます — そして両者は協調しません。 LeSSにおいては、1人のプロダクトオーナーは外の事象（顧客と彼らの持つ優先順位）に集中するのに十分な時間が有るので、チームの中の
Web系企業/事業会社への最高の反面教師: "Spotify's Failed #SquadGoals"を読んで - アジャイルコーチの備忘録
はじめに 以前Scrum@Scaleについて@tyantya41717651さん、@zakky_devさんとディスカッションしましたが、先日お二人と、大規模アジャイルフレームワークであるSpotifyモデルと先日公開された失敗記事(「Spotifyは "Spotifyモデル "を使っていない(Spotify's Failed #SquadGoals)」)についてディスカッションしたのでブログにまとめました。*1 はじめに Spotifyモデルと取り上げた理由 モデルの失敗ではなく、ヒトの失敗 扱える以上の自由や権限を与えた悲劇 1. チームへの過剰な権限付与による、サイロ化の加速 2. 分隊のプロセスの自由さや能力不足による、分隊間協力の困難化 3. 全員での意思決定を追求したことによる、意思決定コストの増大 まとめ Spotifyモデルと取り上げた理由 今回Spotifyモデルの詳しい解
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Spotifyは "Spotifyモデル "を使っていない
