منهجية أجايل على مستوى شركة Spotify أو (Scaling Agile)

هذا النموذج طوّره هينريك نايبرج وأنديرس إيفارسون أكتوبر 2012، وترجمته الى العربية لما فيه من فائدة كبيرة في تحسين وتنظيم سير العمل داخل الشركات في الوطن العربي.

يشكل التعامل مع عدد من الفرق في تنظيم تطوير المنتج تحديًا على الدوام. واحدة من أكثر الأمثلة إثارةً للإعجاب هي تجربة سبوتيفاي، التي حافظت على عقلية منهجية أجايل على الرغم من توسعها لأكثر من 30 فريق حول 3 مدن مختلفة.

سبوتيفاي شركة رائدة في مجال الصوتيات، فعلى الرغم من عمر الشركة الذي يبلغ 6 سنوات إلا أنها نجحت بالحصول على 15 مليون مستخدم نشط، 4 مليون منهم يدفعون ثمن الاشتراك، ويمكن اختصار وصف منتج الشركة إلى "تطبيق صوتيات مميز يمكّنك من العثور على أي مقطع صوتي حول العالم وتشغيله".

زار أليستاير كوكبورن (واحد من مؤسسي منهجية أجايل في تطوير البرمجيات) مقر سبوتيفاي وقال "عظيم! لقد كنت أبحث عمّن يطبق هذا النظام منذ 1992، هذا أمر سار للغاية".

كيف يُدار هذا النظام؟

عرضنا كيفية عملنا في سبوتيفاي في المؤتمرات وحظينا بالعديد من النقاشات الغنيّة بهذا الخصوص وبكيفية تعامل سبوتيفاي بمنهجية أجايل مع مئات المطوّرين، ونال هذا الأمر إعجاب الكثير، لذا قررنا كتابة مقال بهذا الخصوص.

توضيح: لم نبتكر هذا النموذج، فسبوتيفاي تتطور بسرعة (حالها حال أي شركة أخرى تتبنى منهجية أجايل)، وهذه المقالة تعكس طريقتنا الحالية في العمل، فالنموذج هو في طور التحسين وليس مثاليًا، وبحلول الوقت الذي تقرأ هذه المقالة سنكون قد غيرنا الكثير من الأشياء.

الفرق Squads

الفريق هو أصغر وحدة تطوير في سبوتيفاي.

الفريق مشابه لفريق السكرام (Scrum team) وهو مصمم بحيث يبدو وكأنه شركة ناشئة صغيرة، إذ يجلس أعضاء الفريق ويعملون سويًا ولديهم كل الأدوات والمهارات اللازمة لتصميم وتطوير واختبار المنتج وإطلاقه. فهم فريق ذاتي التنظيم ويقررون طريقتهم المناسبة للعمل، فبعضهم يستخدم سبرينت سكرام (Scrum sprints) والبعض الآخر يستخدمون كانبان (Kanban) والآخر يستخدمون مزيجًا من الطريقتين.

لكل فريق مهمة طويلة الأمد مثل بناء وتحسين تطبيق الآندرويد، أو العمل على تجربة الراديو ضمن سبوتيفاي أو توسعة نظم الواجهة الخلفية (backend systems) أو بناء حلول للدفع، توضح الصورة في الأسفل كيف يمكن لفرق مختلفة أن يكون لها مسؤوليات متنوعة أو أن تعمل على أجزاء مختلفة من تجربة المستخدم.

تُشجَّع الفرق على تطبيق مبادئ الشركات الناشئة المرنة مثل "النموذج الأولي" (Minimum Viable Product) أو اختصارًا MVP والتعلّم المتحقق منه (validated learning). المقصود بمصطلح MVP هو إطلاق المنتج مبكرًا وبشكل متكرر، بينما يُقصد بالتعلم الموكد استخدام المعايير واختبار A/B لكشف ما الذي يصلح فعله وما الذي لا يصلح فعله، وهذا يمكن اختصاره بالشعار "فكر به، قم ببناءه، أطلقه، عدّل عليه".

ولأن كل فريق يلتزم بمهمة واحدة وجزء واحد من المنتج لمدة طويلة، فهذا يعني أن أفراده يصبحون خبراء في هذا المجال؛ على سبيل المثال كيفية بناء التجربة الأمثل للاستماع للراديو.

لمعظم الفرق مساحة عمل رائعة تتضمن منطقة مكاتب ومنطقة استراحة وغرفة شخصية للانعزال، وجميع الحوائط تقريبًا يمكن الكتابة عليها كالسبورة. لم نرَ مساحة عمل مشتركة أفضل من ذلك!

لتحفيز التعلم والابتكار يتم تشجيع كل فريق بتمضية 10 بالمائة من وقته على أيام الابتكار (hack days)، وهي أيام يُسمح لهم بفعل ما يريدونه، عادةً لتجربة أفكار جديدة ومشاركتها مع زملائهم. بعض الفرق تستضيف يوم واحد للابتكار كل أسبوعين بينما البعض الآخر يحتفظ بها ليستطيع استضافة أسبوع كامل. أيام الابتكار ليست للتسلية فحسب بل هي طريقة ممتازة للمواكبة مع آخر الأدوات والتقنيات وفي بعض الأحيان تؤدي للكشف عن منتجات مبتكرة!

لا يوجد قائد للفريق بشكل رسمي إلا أنه هناك مالك للمنتج (Product Owner) - اختصارًا PO. مالك المنتج مسؤول عن وضع أولوية العمل الذي يجب أن يقوم به الفريق، لكنه ليس مسؤولًا عن كيفية إنجازهم لذلك العمل. يتعاون مُلّاك المنتجات لفرق مختلفة مع بعضهم البعض لبناء خارطة طريق عامة توضح إلى اتجاه سبوتيفاي ككُل، وكل مالك منتج مسؤول عن موافقة هذه الخارطة بمهام فريقه.

لكل فريق أيضًا مدرب منهجية أجايل يساعدهم بالتطور وتحسين طريقة عملهم، يعقد المدربون اجتماعات دورية لمراجعة ما مضى (retrospectives) واجتماعات لتنظيم السبرينت (sprint planning) ومكالمات فردية مع أعضاء الفريق.

في سيناريو مثالي، يكون كل فريق ذاتي القيادة والتنظيم مع تواصل مباشر مع أصحاب المصلحة (stakeholders) دون تشكيل أي عوائق للفرق الأخرى، أي شركة ناشئة صغيرة بمعنى آخر، وبوجود 30 فريق هذا الأمر بمثابة تحدّي! لقد قطعنا شوطًا كبيرًا بالفعل لكن هناك الكثير من التحسينات التي يمكن إدخالها.

نعقد استبيانات كل ربع سنة مع كل فريق لمساعدتنا في تحديد التحسينات، فهذا يساعدنا في تركيز جهود التحسين على الجانب الذي يحتاجه واكتشاف أي دعم تنظيمي لازم. إليك مخططًا لمثال على هذه الاستبيانات يتضمن 5 فرق ضمن قبيلة:

توضح الدوائر الحالة الحالية بينما توضح الأسهم الاتجاه، على سبيل المثال يمكننا رؤية نمط حيث تعلمنا ثلاث فرق بمشاكل متعلقة بالإصدار ولا يبدو أن الأمر في تحسن، لذا هذه النقطة بحاجة لتركيز عاجل! كما نرى أن 4 فرق لا يجدون دعم مدرب منهجية أجايل جيدًا للغاية ولكن هذا الأمر في تحسّن.

• مالك المنتج (Product owner) - يكون للفريق مالك منتج مخصص يحدد أولوية العمل مع أخذ كل من مبادئ الشركة والجانب التقني بعين الاعتبار
• مدرب منهجية أجايل (Agile coach) - للفريق مدرب منهجية أجايل يساعدهم في التعرف على المعوقات ويمكّنهم من التغلب عليها للتحسين بشكل مستمر
• التأثير على العمل (Influencing work) - يمكن لكل عضو في الفريق أن يؤثر على عمله بأن يصبح عضوًا فعالًا في التخطيط وأن يختار المهام التي يريد العمل عليها، ويمكن لكل عضو أن يمضي 10% من وقته على أيام الابتكار
• سهولة الإطلاق (Easy to release) - يمكن للفريق أن يطلق إصدارًا جديدًا بأقل قدر من المشاكل والتنسيق بين الأطراف الأخرى
• طريقة ملائمة الفريق (Process that fits the team) - يشعر الفريق بالقدرة على التحكم بالطريقة التي تناسبهم والتحسين المستمر عليها
• المهمة (Mission) - لكل فريق مهمة يعرفها كل الأعضاء ويهتم بخصوصها وجميع قصص المستخدم (Stories) في السجل (Backlog) متعلقة بها
• الدعم التنظيمي (Organizational support) - يعلم الفريق إلى أين يلجأ من أجل الدعم في حل المشاكل سواءً أكانت مشاكل تقنية أو مشاكل تعتمد على المهارات "الناعمة"

القبائل Tribes

القبيلة هي مجموعة من الفرق التي تعمل في مجالات مترابطة مثل مشغل الصوتيات أو بنية الواجهة الخلفية (backend infrastructure).

يمكن النظر للقبيلة بكونها حاضنة للشركات الناشئة الصغيرة التي تشكلها الفرق، ولها درجة كبيرة من الحرية والتصرف الذاتي. يوجد لكل قبيلة قائد لها مسؤول عن توفير البيئة الأمثل للفرق ضمن هذه القبيلة، يكون أعضاء الفرق موجودون في المكتب ذاته عادةً بجانب بعضهم البعض، ومساحات الاستراحة القريبة تشجّع الفرق على التعاون فيما بينها.

يكون حجم القبائل مبنيًا على مفهوم "رقم دنبار (Dunbar's number)" الذي ينص على أن معظم الأشخاص لا يستطيعون الحفاظ على علاقات اجتماعية مع أكثر من 100 شخص (الرقم في الحقيقة أكبر للفرق التي تعيش ضغطًا كبيرًا، وصدّق أو لا تصدّق هذه ليست الحالة في سبوتيفاي). نبدأ برؤية أشياء كثيرة تحدّ من الإنتاجية عندما تكبر المجموعات مثل البيروقراطية والقوانين التقييدية والسياسات وطبقات متعددة من الإدارة.

لذا فالقبائل مصممة بحيث تكون أصغر من 100 شخص.

تعقد القبائل اجتماعات دورية، وهي لقاءات غير رسمية يستعرضون بها الأشياء التي يعملون عليها أمام باقي من هم في القبيلة (أو أي شخص آخر موجود) بالإضافة إلى ما أنجزوه وما الشيء الذي يمكن للآخرون تعلمه من تجربتهم في تنفيذ ما أنجزوه، إذ يتضمن ذلك استعراضًا حيًا للبرنامج بالإضافة لأدوات وتقنيات جديدة ومشاريع تم إنجازها في أيام الابتكار، إلخ.

اعتماديات الفريق

لا بدّ من الاعتماديات (dependencies) مع وجود عدّة فرق، والاعتماديات ليست سيئة بالضرورة فالفرق في بعض الأحيان بحاجة للعمل مع بعضها البعض لبناء منتجات عظيمة، لكن بغض النظر، هدفنا هنا هو فرق ذاتية القيادة قدر الإمكان وهذا يعني تقليل الاعتماديات التي تُبطئ أو توقف من عمل الفريق قدر الإمكان.

لتحقيق ذلك فعادةً ما تُسأل الفرق عن الفرق التي تشكّل اعتماديات لها بشكل متكرر وكم تُبطئ من عملها. إليك مثالًا:

من ثم نناقش الطرق الممكنة للتخلص من الاعتماديات المسببة للمشاكل، بالأخص الاعتماديات التي توقف سير العمل أو التي تكون بين أكثر من فريق، عادةً ما يؤدي هذا الأمر إلى إعادة ترتيب أهمية المهام وتنظيمها وهيكلتها أو حتى اللجوء لحلول تقنية.

يساعدنا الاستطلاع أيضًا على رؤية أنماط اعتماد الفرق على بعضها البعض، على سبيل المثال يتّضح لنا أن الكثير من الفرق يُبطئها فريق العمليات. نستخدم مخططًا بسيطًا لتتبع إن كانت أنواع الاعتماديات المتنوعة تزداد أو تنخفض مع الوقت.

لدى سكرام طريقة متبعة تدعى "سكرام السكرامز (Scurm of scrums)" وهو اجتماع يلتقي فيه شخص من كل فريق ليناقش الاعتماديات، لا نعقد اجتماع سكرام السكرامز عادةً في سبوتيفاي وذلك بسبب أن معظم الفرق معتمدة على نفسها بشكل كبير وليست بحاجة لاجتماعات للتنسيق فيما بينها.

بل تُعقد هذه الاجتماعات حسب الحاجة، على سبيل المثال نفّذنا مؤخرًا مشروعًا كبيرًا يتطلب تنسيقًا بين عدّة فرق على مدة أشهر.

لضمان تنفيذ العمل بنجاح عقدت الفرق اجتماعًا يحددون فيه الاعتماديات ويحلونها بين الفرق واستخدمنا سبورة تحتوي على ملاحظات لاصقة لمتابعة الاعتماديات التي لم تُحلّ بعد.

التعاون بين فريق التطوير وفريق العمليات هو منبع شائع لمشاكل الاعتماديات في العديد من الشركات، وكان للكثير من الشركات التي عملنا معها طريقة لتسليم العمل من المطوّر إلى مسؤول العمليات مترافقًا معها العديد من المشاكل والتأخير.

هناك فريق عمليات منفصل في سبوتيفاي لكن واجبه ليس في تحديد موعد الإطلاق للفرق بل لتقديم الدعم للفرق لكي يطلق الفرق التطبيق بأنفسهم، ويكمن هذا الدعم بالبنية التحتية والسكربتات والأمور الروتينية الأخرى، فهم بشكل ما يمهّدون الطريق لإطلاق التطبيق.

هو تعاون غير رسمي لكنه فعّال، مبني على التواصل وجهًا لوجه بدلًا من توثيق العملية بشكل مفصّل.

الجماعات Chapters والنقابات Guilds

هناك سلبيات لكل طريقة، والسلبية المحتملة للقيادة الذاتية الكاملة هي خسارة الموارد على نطاق ضيّق. على سبيل المثال، بفرض أن مختبر ما يواجه مشكلة قد حلّها مختبر آخر في فرقة مختلفة الأسبوع الفائت. لو استطعنا إيجاد طريقة للمختبرين الموجودين في الفرق والقبائل ليجتمعوا في مكان واحد ويشاركون المعرفة والأدوات للجميع سنتخلص من هذه المشكلة.

إذا كان لكل فريق قيادته الذاتية ولم يكن لديه أي تواصل خارجي مع الفرق الأخرى فما الهدف من تأسيس شركة؟ لنجزّئ سبوتيفاي إلى 30 شركة صغيرة!

وهذا السبب في وجود الجماعات والنقابات، فهي الصمغ الذي يبقي الشركة متماسكة وتمنحنا مشاركة للموارد الموجودة دون التضحية بالقيادة الذاتية لكل فريق.

الجماعة هي بمثابة مجموعة صغيرة من الأشخاص يمتلكون مهارات مماثلة ويعملون في مجال كفاءة متقارب ضمن القبيلة ذاتها.

لكل جماعة اجتماع دوري يتقابلون فيه ويناقشون خبراتهم والتحديات التي واجهوها، على سبيل المثال جماعة للمختبرين وجماعة أخرى لمطوري الويب وجماعة لمطوري الواجهات الخلفية وهكذا.

قائد الجماعة هو المدير المباشر لجميع أعضاء جماعته، وله مسؤولياته التقليدية مثل العمل على تطوير مهارات الأشخاص وتحديد الرواتب وإلى ما ذلك. إلا أن قائد الجماعة يشكّل جزءًا من الفرقة ولديه مسؤوليات عمل يومية مثله مثل أي عضو آخر، مما يساعده بمراقبة ومعرفة ما يجري.

الواقع أكثر فوضوية على الدوام من الصورة التي نرسمها في مخيلتنا (كالصورة أعلاه). على سبيل المثال، أعضاء الجماعة غير موزعين بشكل متساوي على الفرق، فبعض الفرق لديها مطور ويب واحد وبعضها لا يوجد ضمنها أي مطوّر. لكن الصور التي نستعرضها يجب أن تمنحك تصورًا جيدًا.

النقابة هي مجموعة أكثر توسعًا وانتشارًا بحسب اهتمام مجتمعها، فهي مجموعة من الناس الذين يرغبون بمشاركة المعرفة والأدوات والشيفرة البرمجية والممارسات التي يتبعونها. تتواجد الجماعات بداخل القبيلة على الدوام، لكن النقابة تمتد خارج حدود القبيلة عبر المنظمة كاملةً. على سبيل المثال: نقابة تقنيات الويب ونقابة المختبرين ونقابة مدرّبي منهجية آجايل وغيرها.

تحتوي النقابة غالبًا على جميع الجماعات التي تعمل في مجالها مع أعضائها، مثلًا تحتوي نقابة المختبرين على جميع المختبرين ضمن الجماعات المختلفة ولكن يستطيع أي مهتمّ بهذا المجال أن ينضم إلى النقابة وهي ليست حكرًا على المختبرين.

لكل نقابة منسّق يقوم بالتنسيق :)

كمثال على عمل النقابات، أقمنا مؤخرًا مؤتمرًا سميناه "مؤتمر نقابة الويب" وهو حدث مفتوح حيث اجتمع كل المطورين في سبوتيفاي في ستوكهولم وناقشوا التحديات في مجالهم وكيف استطاعوا حلّها.

مثال آخر هو نقابة مدرّبي منهجية آجايل، حيث أن المدربين يعملون حول المنظمة لكنهم يشاركون المعرفة بشكل مستمر ويلتقون دوريًا للتعاون على تحسين الهيكلة ضمن المنظمة وهذا الأمر نتّبعه على لوح ندعوه لوح التحسين.

انتظر قليلًا، أليس هذه منظمة مؤلفة من أقسام بنهاية المطاف؟

نعم، يمكنك قول ذلك، إلا أنها نوع مختلف من الأقسام التي اعتدنا رؤيتها.

ففي العديد من المنظمات التي تحتوي على أقسام يتم تجميع الناس الذين يمتلكون مهارات مشابهة سويًا في قسم واحد وتُسند إليهم مشاريع وينقلون نتائجها إلى مديرهم.

نادرًا ما تلجأ سبوتيفاي إلى هذه الطريقة، فأقسامنا موزعة بهدف إطلاق المنتجات.

أي أننا نجمع الأشخاص إلى فرق مستقلة مستقرة تحتوي على مهارات مختلفة وتستطيع أعضائها التعاون فيما بينها وتنظيم أنفسهم للخروج بمنتج رائع. هذا هو البعد العمودي للقسم وهو البعد الأساسي بالنظر إلى كيفية تجميع الأشخاص وكيفية تمضية وقتهم سويًا.

البعد الأفقي هو لمشاركة المعرفة والأدوات والشيفرة البرمجية، وتسهيل هذه العملية هي واجب قائد الجماعة.

إذا أردت أن تفكر بالموضوع بلغة المؤسسات، فيمكنك النظر إلى البعد العمودي بكونه الـ "ماذا" والبعد الأفقي بكونه الـ "كيف". هيكل المؤسسة يضمن أنه يمكن لأعضاء الفريق أن يحصلون على اتجاه لما سيبنونه بالإضافة لكيفية بناءه.

يطابق هذا النموذج نموذج "البروفسور ورائد الأعمال" المقترح من ماري وتوم بوبيندك، فمالك المنتج هو رائد الأعمال أو بطل المنتج الذي يركز على الحصول على منتج رائع بينما قائد الجماعة هو البروفسور أو قائد الكفاءة الذي يركز على تحسين الكفاءة التقنية والمهارات.

هناك صدام صحي بين هذه الأدوار، فرائد الأعمال يسعى لتسريع العملية واختصار الوقت قدر الإمكان بينما يسعى البروفسور إلى التأني وبناء الأشياء بطريقة صحيحة. كلا الجانبين مطلوب، وهذا السبب بكون الصدام هذا صحي.

ماذا عن المعمارية؟

يتركز عمل سبوتيفاي بكونها خدمة، إذ لدينا 100 نظام فريد وكل منها يمكن إدارته والعمل على إطلاقاته بشكل منفصل. يتضمن ذلك الخدمات التي تحدث بالخلفية مثل إدارة قوائم التشغيل أو البحث أو الدفع والتطبيقات مثل المشغّل الخاص بآيباد والأجزاء الأخرى مثل الراديو أو قسم "ما الجديد" في مشغل الصوتيات.

في الحقيقة، يمكن لأي شخص أن يعدّل على أي نظام، بالنظر إلى أن الفرق تعمل على ميزة تلو الأخرى فهذا يتطلب تحديث عدّة أنظمة لكي تعمل الميزة الجديدة عند الإطلاق.

الخطورة في هذا النموذج تكمن بأن معمارية النظام ستصبح فوضوية في حال لم يتم التركيز على سلامة النظام بكامله، وللتخفيف من هذه الخطورة لدينا منصب يدعى بمالك النظام (System Owner). لكل نظام مالك خاص به أو عدّة ملّاك (نشجع وجود مالكَين)، من أجل النظم شديدة الحساسية هناك مالكين للنظام، مالك من وجهة نظر تقنية ومالك من وجهة نظر عملية.

مالك النظام هو المرجع لأي مشاكل تقنية أو معمارية، فهو المنظّم ويوجه المبرمجين في ذلك النظام للتأكد من عدم حدوث تضاربات بين الفرق، إذ يركز على أشياء مثل الجودة والتوثيق والدين التقني (Technical debt) والثبات وقابلية التوسعة وعملية الإطلاق.

مالك النظام لا يشكل عنق زجاجة (نقطة ازدحام لموافقات العمل) ولا يمثل مطوّر يأمر الناس، إذ أنه لا يتخذ جميع القرارات بنفسه أو يكتب كل الكود أو يشرف على جميع الإطلاقات، بل هو عادةً عضو ضمن فريق أو قائد جماعة لديه مسؤولياته اليومية كسائر الفريق بالإضافة لملكيته للنظام. إلا أنه يأخذ يومًا مخصصًا نسميه يوم مالك النظام بين كل حين وآخر للعمل على أشياء متعلقة بذلك النظام مثل تنظيمه وما إلى ذلك. نحاول عادةً أن تشكّل هذه المسؤولية أقل من عُشر وقت الشخص لكن الأمر بالطبع يختلف بحسب النظام.

لدينا أيضًا منصب رئيس معمارية النظام (Chief Architect Role) وهو شخص ينظّم العمل على مشاكل معمارية النظام عالية المستوى التي تنضوي تحتها عدّة أنظمة، ويراجع تطوير النظم الجديدة للتأكد من تفادي الأخطاء الشائعة وأنهم متوافقين مع رؤية النظام المعمارية. عادةً ما تكون الملاحظات عبارة عن اقتراحات وقرار اعتماد تصميم النظام النهائي يقع على عاتق الفريق الذين يعملون على بناءه.

ما هي نتيجة هذا النموذج؟

نمَت سبوتيفاي بسرعة كبيرة فبغضون 3 سنوات كبرنا من 30 إلى 250 موظف في القسم التقني، لذا لدينا الكثير من الدروس بهذا الخصوص! نموذج النمو هذا باستخدام الفرق والقبائل والجماعات والنقابات هو شيء طوّرناه تدريجيًا في السنوات الفائتة وما زال الناس بحاجة لفترة ليعتادوا عليه. لكن إلى اللحظة هذه وبناءً على الاستبيانات والاجتماعات فإن النموذج هذا مناسب للجميع تقريبًا. مما يمنحنا شيئًا لننمو بواسطته، فقد ازداد أيضًا رضى الموظفين مع النمو المتسارع إذ كان 4.4 من 5 في أبريل 2012.

إلا أن حلول اليوم تتسبب بمشاكل الغد كما هو الحال في معظم المنظمات التي تنمو بسرعة، لذا ابقَ على اطّلاع فقصّتنا لم تنتهي بعد!

هينريك وأندريس
henrik.kniberg@spotify.com
https://crisp.se/henrik.kniberg
anders.ivarsson@spotify.com