Mô hình spotifile

Mô Hình Điều Hành Của SPOTIFILE 2013

Copyright BillQuy.Com Page 1

Scaling Agile @ Spotify

Đối phó với các nhóm khác nhau trong một tổ chức phát triển sản phẩm luôn luôn là một

thách thức!

Một trong những ví dụ ấn tượng nhất chúng tôi đã nhìn thấy cho đến nay là Spotify, đã

giữ một tư duy nhanh nhẹn bất chấp đã mở rộng đến hơn 30 đội trên 3 thành phố.

Spotify là hấp dẫn công ty được chuyển đổi ngành công nghiệp âm nhạc. Công ty đã chỉ

tồn tại 6 năm và đã có hơn 15 triệu người sử dụng hoạt động và hơn 4 triệu trả tiền. Bản

thân sản phẩm có thể được giống như một máy nghe nhạc huyền diệu trong đó bạn ngay

lập tức có thể tìm và chơi tất cả các bài hát trên thế giới ".

Alistair Cockburn (một trong những cha đẻ của phát triển phần mềm nhanh nhẹn) đã đến

thăm Spotify và nói "Nice

- Tôi đã tìm kiếm một người nào đó để thực hiện định dạng ma trận từ năm 1992 :) vì vậy

nó được thực sự chào đón để xem ".

Vì vậy, làm thế nào quản lý?



Chúng tôi đã trình bày tại các hội nghị và bị bắt trong việc tham gia các cuộc thảo luận

xung quanh cách chúng tôi làm việc tại Spotify và công ty xử lý như thế nào nhanh nhẹn

với hàng trăm các nhà phát triển. Nhiều người bị mê hoặc bởi này, vì vậy chúng tôi quyết

định viết một bài viết về nó.

Disclaimer: Spotify (giống như bất kỳ công ty nhanh nhẹn tốt) phát triển nhanh chóng.

Bài viết này chỉ là một bản chụp của chúng tôi hiện tại cách làm việc - một cuộc hành

trình trong tiến trình, không phải là một cuộc hành trình hoàn thành. Bởi thời gian bạn

đọc này, mọi thứ đã thay đổi.

Đội

Đơn vị cơ bản của sự phát triển tại Spotify là Squad.

Squad là tương tự như một nhóm Scrum, và được thiết kế để cảm thấy giống như một

mini-khởi động. Họ ngồi lại với nhau, và họ có tất cả các kỹ năng và

công cụ cần thiết để thiết kế, phát triển, thử nghiệm và phát hành để

sản xuất. Họ được một selforganizing đội và quyết định cách riêng

của họ - một số sử dụng Scrum chạy nước rút, một số Kanban sử

dụng, một số sử dụng một kết hợp của các phương pháp tiếp cận này.

Mỗi đội có một nhiệm vụ dài hạn như xây dựng và cải thiện các

khách hàng Android, tạo ra các Spotify kinh nghiệm radio, nhân rộng

các hệ thống phụ trợ, hoặc cung cấp các giải pháp thanh toán. Hình

ảnh dưới đây minh họa cách các đội khác nhau chịu trách nhiệm cho

các bộ phận khác nhau của kinh nghiệm người dùng.

Đội được khuyến khích áp dụng các nguyên tắc trong Lean Startup như MVP (tối thiểu

khả thi sản phẩm) và xác nhận việc học tập. MVP

có nghĩa là phát hành sớm và thường xuyên, và

xác nhận học tập có nghĩa là bằng cách sử dụng

các số liệu và Thử nghiệm A / B để tìm hiểu

những gì thực sự làm việc và những gì không.

Điều này được tóm tắt trong khẩu hiệu "Hãy suy

nghĩ, xây dựng, tàu nó, tinh chỉnh nó ".

Bởi vì đội hình từng dính với một nhiệm vụ và



một phần của sản phẩm trong một thời gian dài, họ có thể thực sự trở thành chuyên gia

trong khu vực đó - ví dụ như những gì nó có nghĩa là để xây dựng một kinh nghiệm phát

thanh awesome.

Hầu hết các đội có một không gian

làm việc tuyệt vời, bao gồm một

khu vực bàn, khu vực phòng chờ,

và một "huddle" cá nhân phòng.

Hầu như tất cả các bức tường là

bảng trắng. Chúng tôi đã không bao

giờ nhìn thấy một không gian hợp

tác tốt hơn! có, đó là một con cá

mập bay xung quanh. hoàn toàn

bình thường.

Để thúc đẩy học tập và đổi mới,

mỗi đội được khuyến khích dành

khoảng 10% thời gian của họ "ngày

hack". Trong suốt thời gian cho

thuê làm bất cứ điều gì họ muốn,

thường cố gắng ra những ý tưởng

mới và chia sẻ với bạn bè của họ.

Một số nhóm làm 1 ngày cho thuê

mỗi tuần thứ hai, những người khác

tiết kiệm cho một tuần thuê "toàn bộ.

Ngày Hack không chỉ vui vẻ, họ cũng là một cách tuyệt vời để ở lại up-to-date với các

công cụ và kỹ thuật mới và đôi khi dẫn đến đổi mới sản phẩm quan trọng!

Một đội không có một nhà lãnh đạo đội hình chính thức bổ nhiệm, nhưng nó có một chủ

sở hữu sản phẩm.các sản phẩm chủ sở hữu chịu trách nhiệm ưu tiên các công việc được

thực hiện bởi nhóm nghiên cứu, nhưng không được tham gia với cách họ làm công việc

của họ. Các chủ sở hữu sản phẩm của đội khác nhau cộng tác với nhau để duy trì một

Corporate lộ trình tài liệu cho thấy nơi Spotify như một toàn thể là tiêu đề, và mỗi chủ sở

hữu sản phẩm chịu trách nhiệm cho việc duy trì một tồn đọng sản phẩm phù hợp cho đội

hình của họ.



Đội A cũng có quyền truy cập vào một huấn luyện viên nhanh nhẹn, giúp họ phát triển và

cải thiện cách làm việc của họ. các huấn luyện viên chạy retrospectives, chạy nước rút

cuộc họp lập kế hoạch, 1-on-1 huấn luyện, vv

Lý tưởng nhất là đội từng là hoàn toàn độc lập với tiếp xúc trực tiếp với các bên liên quan

của họ, và không ngăn chặn phụ thuộc đến các đội khác. Về cơ bản một mini-khởi động.

Với hơn 30 đội, đó là một thách thức! Chúng tôi có đi một chặng đường dài, nhưng vẫn

còn có rất nhiều cải tiến được thực hiện.

Để hỗ trợ cho điều này, chúng tôi chạy một cuộc khảo sát hàng quý với đội hình từng.

Điều này giúp tập trung nỗ lực cải tiến của chúng tôi và tìm thấy ra loại hỗ trợ tổ chức là

cần thiết. Dưới đây là một bản tóm tắt hình ảnh của cuộc khảo sát như vậy, hiển thị 5 đội

trong một bộ lạc:

Các vòng tròn hiển thị trạng thái hiện tại, các mũi tên thể hiện xu hướng. Ví dụ, chúng ta

có thể thấy một mô hình nơi ba đội báo cáo các vấn đề xung quanh phát hành và nó

không có vẻ để cải thiện khu vực này cần khẩn cấp tập trung! Chúng tôi cũng thấy đội

hình 4 không có một tình huống tuyệt vời với sự hỗ trợ huấn luyện viên nhanh nhẹn,

nhưng mà nó là đã được cải thiện.

● Sản phẩm chủ sở hữu - Các đội hình sẽ có một chủ sở hữu sản phẩm chuyên dụng ưu

tiên công việc và mất cả hai giá trị kinh doanh và các khía cạnh công nghệ cao vào xem

xét.

● Agile huấn luyện viên - Đội hình có một huấn luyện viên nhanh nhẹn giúp họ xác định

những trở ngại và các huấn luyện viên họ liên tục cải thiện quá trình của họ.

● Ảnh hưởng tới công việc - Mỗi thành viên trong đội có thể ảnh hưởng đến anh / công

việc của mình, là một phần hoạt động trong lập kế hoạch và chọn những nhiệm vụ để làm

việc trên. Mỗi thành viên đội hình có thể chi tiêu 10% / thời gian thuê ngày.

● Dễ dàng để phát hành - Các đội tuyển có thể (và không) có được các công cụ sống với

rắc rối tối thiểu và đồng bộ.

● Quy trình phù hợp với nhóm nghiên cứu - Các đội hình sẽ cảm thấy quyền sở hữu quá

trình của họ và liên tục cải thiện nó.

● Sứ mệnh - Các đội hình sẽ có một nhiệm vụ mà tất cả mọi người biết và quan tâm đến,

và những câu chuyện trên tồn đọng liên quan đến nhiệm vụ.



● Hỗ trợ tổ chức - Các đội hình sẽ biết nơi để chuyển đến hỗ trợ giải quyết vấn đề, vấn đề

kỹ thuật cũng như các vấn đề "mềm".

Tribes

Một bộ lạc là một tập hợp các đội làm việc trong lĩnh vực liên quan - chẳng hạn như máy

nghe nhạc, hoặc phụ trợ cơ sở hạ tầng.

Bộ lạc này có thể được xem như là "lồng ấp" cho đội hình mini-khởi động. , Và có một

mức độ hợp lý của tự do và tự chủ.

Bộ tộc từng có một lãnh đạo bộ tộc

người chịu trách nhiệm cho việc

cung cấp môi trường sống tốt nhất

có thể cho các đội trong bộ tộc.

Các đội tuyển trong một bộ lạc là

tất cả vật chất trong cùng một văn

phòng, thông thường ngay bên

cạnh nhau, và các khu vực phòng

chờ ở gần đó thúc đẩy sự hợp tác

giữa các đội tuyển.

Các bộ lạc có kích thước dựa trên

khái niệm "số Dunbar", mà nói

rằng hầu hết mọi người không

thể duy trì một mối quan hệ xã

hội với hơn 100 người hoặc hơn

(con số thực sự là lớn hơn cho

các nhóm dưới áp lực sống mãnh

liệt, mà không phải là thực sự là

trường hợp tại Spotify, tin tưởng

rằng nó hay không ...). khi nhóm

nhận được quá lớn, chúng tôi bắt đầu nhìn thấy những điều giống như quy định hạn chế,

quan liêu, chính trị, lớp bổ sung quản lý, và các chất thải khác.

Vì vậy, các bộ lạc đều được thiết kế để được nhỏ hơn 100 người, hay như vậy.



Squad phụ thuộc

Với đội nhiều sẽ luôn có phụ thuộc. Phụ thuộc là không nhất thiết phải xấu - đội đôi khi

cần làm việc cùng nhau để xây dựng một cái gì đó thật sự tuyệt vời. Tuy nhiên, mục tiêu

của chúng tôi là phải có đội tự trị càng tốt, đặc biệt là giảm thiểu phụ thuộc mà đang chặn

hoặc làm chậm đội hình xuống.

Để hỗ trợ cho điều này, chúng tôi thường xuyên yêu cầu tất cả các đội khác đội chúng

phụ thuộc vào, và đến mức độ nào những phụ thuộc được ngăn chặn hoặc làm chậm đội

hình xuống. Dưới đây là một ví dụ:

Sau đó chúng tôi thảo luận về cách để loại bỏ sự phụ thuộc có vấn đề, đặc biệt là ngăn

chặn và qua bộ tộc phụ thuộc. Điều này thường dẫn đến reprioritization, tổ chức lại, thay

đổi kiến trúc, kỹ thuật giải pháp.

Cuộc khảo sát cũng giúp chúng

ta thấy mô hình xung quanh

cách đội phụ thuộc lẫn nhau - ví

dụ hơn và đội nhiều hơn dường

như bị chậm lại bởi các hoạt

động. Chúng tôi sử dụng một

biểu đồ đơn giản để theo dõi

khác nhau như thế nào các loại

phụ thuộc tăng hoặc giảm theo

thời gian.



Scrum có một thực tế được gọi là "scrum scrums", một cuộc họp đồng bộ hóa một người

từ mỗi nhóm họp để thảo luận phụ thuộc. Chúng tôi không thường làm scrum của scrums

Spotify, chủ yếu do hầu hết các đội tuyển là khá độc lập và không cần một cuộc họp điều

phối.

Thay vào đó, scrum của scrums xảy ra "theo yêu cầu". Ví dụ chúng tôi vừa có một dự án

lớn mà yêu cầu công tác phối hợp

của đội nhiều trong một vài tháng.

Để làm công việc này, các đội

bóng đã có một cuộc họp đồng bộ

hàng ngày mà họ đã xác định và

giải quyết phụ thuộc giữa các đội

tuyển, và sử dụng một hội đồng với

các ghi chú dán để theo dõi phụ

thuộc chưa được giải quyết.

Một nguồn tin phổ biến các vấn đề phụ thuộc ở nhiều công ty điều hành các hoạt động

phát triển vs.Hầu hết các công ty chúng tôi đã làm việc với một số loại việc bàn giao từ

dev để ops, với ma sát liên quan và sự chậm trễ.

Tại Spotify là một nhóm hoạt động riêng biệt, nhưng công việc của họ không phải là để

làm cho các phiên bản cho các đội tuyển công việc của họ là cung cấp cho các đội tuyển



các hỗ trợ cần thiết để phát hành mã tự, hỗ trợ theo hình thức cơ sở hạ tầng, kịch bản, và

thói quen. Họ đang có, trong một cảm giác ", xây dựng đường vào sản xuất".

Đây là một sự hợp tác chính thức nhưng hiệu quả, dựa trên khuôn mặt-đối-mặt thông tin

liên lạc chứ không phải là chi tiết xử lý tài liệu.



Chương và phường hội

Có một nhược điểm để tất cả mọi thứ, và những nhược điểm tiềm năng tự chủ đầy đủ là

một sự mất mát của các nền kinh tế của quy mô. Các thử nghiệm trong đội hình có thể

được vật lộn với một vấn đề mà các thử nghiệm trong đội hình B giải quyết tuần trước.

Nếu tất cả các xét nghiệm có thể nhận được với nhau, giữa các đội và các bộ tộc, họ có

thể chia sẻ kiến thức và tạo ra các công cụ để lợi ích của tất cả các đội.

Nếu mỗi đội là hoàn toàn tự trị và không có thông tin liên lạc với các đội khác, sau đó

điểm là những gì có một công ty? Spotify cũng có thể được cắt thành 30 công ty nhỏ

khác nhau.

Đó là lý do tại sao chúng tôi có chương và Guild. Đây là chất keo giữ công ty với nhau,

nó cho chúng ta một số nền kinh tế của quy mô mà không bị mất quyền tự chủ quá nhiều.

Chương này là gia đình nhỏ của bạn những người có kỹ năng tương tự và làm việc trong

cùng một chung năng lực khu vực, trong cùng một bộ tộc.



Mỗi chương thường xuyên họp để thảo luận về chuyên môn của họ và những thách thức

cụ thể của họ - ví dụ chương thử nghiệm, các nhà phát triển web chương hay chương phụ

trợ.

Dẫn chương là dòng quản lý cho các thành viên chương của mình, với tất cả các trách

nhiệm truyền thống như người phát triển, thiết lập mức lương, vv Tuy nhiên, dẫn chương

cũng là một phần của đội tuyển và được tham gia vào công việc ngày-to-ngày, giúp anh

ta ở lại trong liên lạc với thực tế.

Bây giờ, thực tế luôn luôn là hỗn độn hơn so với các hình ảnh đẹp như trên. Ví dụ, các

thành viên chương không phân bố đều trên các đội tuyển, một số đội có rất nhiều các nhà

phát triển web, một số không có. Nhưng hình ảnh sẽ cho bạn ý tưởng chung.

Guild là hữu cơ và rộng rộng "cộng đồng quan tâm", một nhóm người muốn chia sẻ kiến

thức, công cụ, mã, và thực hành. Chương luôn luôn địa phương để một bộ lạc, trong khi

một guild thường cắt giảm trên toàn bộ tổ chức. Một số ví dụ là: công nghệ web guild,

guild thử nghiệm, nhanh nhẹn huấn luyện viên guild, vv

Guild A thường bao gồm tất cả các chương làm việc trong khu vực đó và các thành viên

của họ, ví dụ như các guild thử nghiệm bao gồm tất cả các xét nghiệm trong tất cả các

chương thử nghiệm, nhưng ai là người quan tâm có thể tham gia bất cứ Guild.



Guild Mỗi người có một "Guild điều phối viên" ai, tốt, không chỉ rằng: o)

Như một ví dụ của guild làm việc, chúng tôi vừa có một "Web Guild Unconference", một

sự kiện không gian mở, nơi tất cả các nhà phát triển web tại Spotify tập hợp trong



Stockholm để thảo luận về những thách thức và các giải pháp trong lĩnh vực của họ.

Một ví dụ khác là các guild huấn luyện viên nhanh nhẹn. Các huấn luyện viên được lan

truyền trên tất cả các tổ chức, nhưng chia sẻ kiến thức liên tục và thường xuyên gặp gỡ để

cộng tác vào việc cải thiện cấp độ tổ chức cao khu vực, mà chúng tôi theo dõi trên một

bảng cải tiến.

Chờ một giây, không phải là chỉ là một org ma trận?

Vâng. Vâng, sắp xếp. Đó là một loại khác nhau của ma trận hơn so với những gì hầu hết

chúng ta sử dụng để mặc dù.

Trong các tổ chức ma trận nhiều những người có kỹ năng tương tự được "gộp" lại với

nhau thành các phòng ban chức năng, và "phân công" cho các dự án, và "báo cáo" một

người quản lý chức năng.

Spotify hiếm khi làm bất cứ điều này. Ma trận của chúng tôi là trọng tới giao hàng.

Đó là, người dân được chia thành các nhóm ổn định đồng nằm đội, những người có kỹ

năng khác nhau thiết lập hợp tác và tự tổ chức để cung cấp một sản phẩm tuyệt vời. Đó là

chiều dọc trong ma trận, và nó là chính vì đó là cách mọi người có thể chất nhóm lại và

nơi mà họ dành hầu hết thời gian của họ.

Chiều ngang là chia sẻ kiến thức, công cụ, và mã. Công việc dẫn chương tạo điều kiện

thuận lợi và hỗ trợ này.

Về ma trận, suy nghĩ của chiều thẳng đứng như

"cái gì" và kích thước ngang như "làm thế nào".

ma trận cấu trúc đảm bảo rằng mỗi thành viên đội

tuyển có thể nhận được hướng dẫn về "gì để xây

dựng tiếp theo" cũng như "làm thế nào để xây

dựng nó ".

Điều này phù hợp với mô hình "giáo sư và nhà

doanh nghiệp" khuyến cáo của Mary và Tom

Poppendieck. Các PO là "doanh nhân" hay "nhà



vô địch sản phẩm", tập trung vào việc cung cấp một sản phẩm tuyệt vời, trong khi các

chương chì là "giáo sư" hay "năng lực lãnh đạo", tập trung vào kỹ thuật xuất sắc.

Có một sự căng thẳng lành mạnh giữa những vai trò này, doanh nghiệp có xu hướng

muốn tăng tốc độ và cắt góc, trong khi giáo sư có xu hướng muốn làm chậm và xây dựng

những điều đúng. Cả hai khía cạnh là cần thiết, đó là lý do tại sao nó là một sự căng thẳng

"khỏe mạnh".

Điều gì về kiến trúc?

Spotify công nghệ cao theo định hướng dịch vụ. Chúng tôi có hơn 100 hệ thống khác

nhau, và có thể là duy trì và triển khai một cách riêng biệt. Điều này bao gồm các dịch vụ

phụ trợ như quản lý danh sách hoặc tìm kiếm hoặc thanh toán, và các khách hàng như

máy nghe nhạc iPad, và các thành phần cụ thể như đài phát thanh, hoặc phần của máy

nghe nhạc "mới là những gì".

Về mặt kỹ thuật, bất cứ ai được phép chỉnh sửa bất kỳ hệ thống. Kể từ khi các đội tuyển

là có hiệu quả các nhóm tính năng, họ bình thường cần để cập nhật hệ thống nhiều để có

được một tính năng mới vào sản xuất.



Nguy cơ với mô hình này là kiến trúc của một hệ thống được điều sai lầm nếu không tập

trung vào các tính toàn vẹn của hệ thống như một toàn thể.

Để giảm thiểu nguy cơ này, chúng tôi có một vai trò được gọi là "Hệ thống chủ sở hữu".

Tất cả các hệ thống này có một chủ sở hữu hệ thống, hoặc một cặp chủ sở hữu hệ thống

(chúng tôi khuyến khích ghép nối). Đối với hệ thống hoạt động quan trọng, chủ sở hữu là

một hệ thống-Dev Ops cặp - có nghĩa là, một người có một quan điểm phát triển và một

người với một quan điểm hoạt động.

Chủ sở hữu hệ thống là "đi đến" người (s) cho bất kỳ vấn đề kỹ thuật hoặc kiến trúc liên

quan đến hệ thống đó.

Ông là điều phối và hướng dẫn người mã trong hệ thống đó để đảm bảo rằng họ không

vấp ngã trên mỗi khác. Ông tập trung vào những thứ như tài liệu, chất lượng, nợ kỹ thuật,

sự ổn định, khả năng mở rộng, và phát hành quá trình.

Chủ hệ thống không phải là một nút cổ chai hay kiến trúc sư tháp ngà. Ông không cá

nhân phải làm cho tất cả quyết định, hoặc viết tất cả các mã, hoặc làm tất cả các phiên

bản. Ông thường là một đội hình thành viên hoặc chương dẫn người có trách nhiệm day-

to-day khác ngoài quyền sở hữu hệ thống. Tuy nhiên, theo thời gian, ông sẽ có một "ngày

chủ sở hữu hệ thống" và làm công việc vệ sinh vào hệ thống đó. Thông thường, chúng tôi

cố gắng để giữ cho hệ thống này sở hữu ít hơn 1/10 thời gian của một người, nhưng nó

khác nhau rất nhiều giữa các hệ thống tất nhiên.

Chúng tôi cũng có một vai trò kiến trúc sư trưởng, một người phối hợp làm việc cấp cao

vấn đề kiến trúc mà cắt ngang qua nhiều hệ thống. Ông đánh giá phát triển của các hệ

thống mới để đảm bảo họ tránh chung sai lầm, và rằng họ phù hợp với tầm nhìn kiến trúc

của chúng tôi. Thông tin phản hồi là luôn luôn chỉ cần gợi ý và đầu vào quyết định cho

việc thiết kế cuối cùng của hệ thống vẫn còn nằm với đội tuyển xây dựng nó.

Làm thế nào là tất cả làm việc?

Spotify đã phát triển rất nhanh trong hơn 3 năm, chúng tôi đã phát triển từ 30 đến 250

người trong công nghệ - vì vậy chúng tôi có của chúng tôi chia sẻ đau tăng trưởng! Mô

hình này mở rộng quy mô - Đội, các bộ lạc, các Chương, và Guild - là cái gì đó đã được

giới thiệu dần dần trong năm qua, do đó, người ta vẫn còn nhận được sử dụng đến nó.

Nhưng cho đến nay, dựa trên khảo sát và retrospectives, nhân rộng các mô hình có vẻ làm

việc khá tốt! Và nó mang lại cho chúng ta một cái gì đó "phát triển thành". Mặc dù tốc độ



tăng trưởng nhanh, sự hài lòng của nhân viên đã liên tục tăng, trong tháng 4 năm 2012 là

4,4 trong 5.

Tuy nhiên, như với bất kỳ tổ chức phát triển, các giải pháp hiện nay cho sinh đến các vấn

đề của ngày mai. Vì vậy, ở điều chỉnh, câu chuyện là không quá: o)

Bill Quy chúc các bạn thành công

[email protected]

http://billquy.blgospot.com

mailto:[email protected]

http://billquy.blgospot.com/

Business

Mô hình spotifile