سكرم (تطوير البرمجيات)
سْكْرَمْ (بالإنجليزية: Scrum) هو أحد إطارات العمل وفقاً لمقاييس منهجية تطوير البرمجيات أجايل لإدارة تطوير المنتجات. يتميز بأنه ذو نمط تكراري وتزايدي (اضطرادي). إستراتيجية تطوير المنتجات هذه تمتاز بكونها طريقه مرنة وشمولية (بالإنجليزية: holistic), حيث يعمل فريق المطورين جميعاً كوحدة واحدة من أجل تحقيق هدف محدد مسبقاً. هذه الطريقة تختلف اختلافاً كلياً عن الطريقة التقليدية التي تعتمد على التسلسل في عملية تطوير أي منتج معين بل وتتحداها.
من أهم ميزات هذه الطريقة أنها تعطي إمكانيات كبيرة للفريق لإدارة نفسه بنفسه، وتشجع على تواجد الفريق بشكل جماعي في نفس المكان أو عن طريق التواصل الحثيث عن طريق الاتصال عن بعد (الأنترنت، الهاتف). فهناك تركيز واضح على التواصل بين أعضاء الفريق الواحد من خلال اللقاءات اليومية وجها لوجه ومن خلال المحافظة على الانضباط في جميع جوانب المشروع. طريقة السْكْرَمْ تم تطويرها من رحم تطوير تقنيات البرمجيات لكنها منفصلة تماماً عنها. يتم حالياً استعمال هذه الطريقة في مجالات عديدة.
وهناك مبدأ أساسي لإستراتيجية سْكْرَمْ هو اعترافها أنه خلال مشروع فإن العملاء يستطيعون تغيير رغباتهم ومتطلباتهم (غالباً ما تسمى «متطلبات ملحة»)، وأن التحديات غير المتوقعة لا يمكن معالجتها بسهولة بطريقة تنبؤية أو تخطيطية تقليدية.
على هذا النحو، فإن سْكْرَمْ تتبنى مبدأ التجريبية وقبول أن المشكلة لا يمكن أن تفهم بشكل كامل أو تحدد تماماً، مع التركيز بدلاً من ذلك على تكثيف قدرة الفريق على تسليم مراحل تطور المنتج بسرعة والاستجابة للمتطلبات الناشئة.
نشأت التسمية سْكْرَمْ من لعبة كرة قدم الرغبي، حيث أن سْكْرَمْ هو الطريقة التشكيل التي يبدأ بها لعب الفريقين بعد حدوث توقف نتيجة مخالفة بسيطة، وتكون كالآتي: يصطف اللاعبون الأماميون من الفريق مع تشابك أذرعهم منكبين ورؤوسهم إلى الأسفل، في مقابل مجموعة مماثلة من الفريق الآخر مكونين تكتل زحامي يدفع كل منهما الآخر. ثم يتم طرح الكرة في الزحام حيث يحاول كل من الفريقين كسبها الي جانبه بواسطة الركل ذهابا وايابا بحيث يتحرك الفريق كله ككتلة واحدة.
نبذة تاريخية
في عام 1986 تم تعريف سْكْرَمْ لأول مرة من قبل هيروتاكا تاكوتشي وإكوجيرو نوناكا (بالإنجليزية: Ikujiro Nonaka) في مقالة نشرت في مجلة هارفارد بزنس ريفيو بعنوان "لعبة جديدة جديدة لتطوير المنتجات"[1]، بأنه "إستراتيجية شمولية مرنة لتطوير المنتجات حيث يعمل فريق تطوير كوحدة للوصول إلى هدف مشترك" في مقابل "النهج المتسلسل التقليدي". ذكر تاكوتشي ونوناكا في وقت لاحق في "The Knowledge Creating Company" أنه هو شكل من أشكال "خلق المعرفة التنظيمي" وهي مفيدة خصوصا في إحداث الابتكار باستمرار، تدريجيا وبشكل حلزوني". ووصف الكتاب إستراتيجية جديدة لتطوير المنتجات التجارية والتي من شأنها أن تزيد من السرعة والمرونة، استناداً إلى دراسات في شركات تصنيع السيارات، وآلات تصوير المستندات والطابعات. و
التسمية:
سُمِّيت سْكْرَمْ نسبة إلى طريقة لإعادة بدأ لعبة الرغبي بعد مخالفة بسيطة، فيتم تنفيذ العملية برمتها من قبل فريق واحد متعدد الوظائف عبر مراحل متداخلة متعددة، حيث يحاول الفريق «قطع المسافة كوحدة واحدة، وتمرير الكرة ذهابا وايابا».
في 1990s في وقت مبكر، استخدم كين شوابر (بالإنجليزية: Ken Schwaber) ما يمكن اعتباره أسلوب سكرم في شركته Advanced Development Methods. كما أن كل من جيف ساذرلاند (بالإنجليزية: Jeff Sutherland) وجون سكمنيوتالس وجيف ماكينا وضعوا نهجا مماثلا في مؤسسة ايزل Easle Corporation، وكانوا أول من أشار إليها باستخدام واحدة كلمة سكرم.
وفي عام 1995، قدم ساذرلاند شفابر بالاشتراك ورقة تصف منهجية سكرم في ورشة عمل حول تصميم وتنفيذ المنتجات التجارية Business Object Design and Implementation Workshop والتي عقدت كجزء من دورة اوبسلا للبرمجة الغرضية التوجه والنظم واللغات والتطبيقات Object-Oriented Programming, Systems, Languages & Applications '95 (OOPSLA '95) في أوستن، تكساس، وكان هذا أول عرض علني لها.
ثم تعاون كل من شفابر وساذرلاند خلال السنوات التالية لدمج الكتابات المذكورة أعلاه، ودمج تجاربهم، وأفضل الممارسات الصناعية إلى ما يعرف الآن باسم سكرم.
في عام 2001 عمل شفابر Schwaber مع مايك بيدل Mike Beedle لوصف الأسلوب في كتاب الاجايل تطوير البرمجيات مع سكرم Agile Software Development with Scrum.
ونص نهجه في التخطيط وإدارة المشاريع علي دمج صناع القرار والسلطة في مستوى الخصائص العملية واليقين.
على الرغم من أن كلمة SCRUM ليست اختصاراً، إلا أنه من المعروف أن بعض الشركات تكتبها بحروف كبيرة SCRUM. قد يكون هذا عائداً لأحد هذه الأوراق التي كتبها كين شفابر Schwaber في وقت مبكر وذكرها كذلك في العنوان.
وفي وقت لاحق، قام كين شفابر Schwaber بانشاء تحالف Scrum Alliance وعمل برنامج Certified Scrum Master programs ومشتقاته.
في خريف عام 2009، غادر كين شفابر تحالف سكرم وأسس Scrum.org لزيادة تحسين نوعية وفعالية سكرم.
الأدوار في سكرم
هناك ثلاثة أدوار أساسية ومجموعة من الأدوار الثانوية. الأدوار الأساسية يشار إليه سابقا بالبقر والأدوار الثانوية بالدجاج (كما في قصة الدجاج والبقر: ففي عجة البيض بالبسطرمة تحتاج التضحية بالبقر فدورها فيها أساسي ولكن الدجاج دوره ثانوي وان كان كل منهما مهما).
الأدوار الأساسية هي تلك التي تدخل في تعريف سكرم في عملية إنتاج المنتج (الهدف من المشروع). وهم يمثلون فريق سكرم. وعلى الرغم من ان أدوار أخرى يمكن أن تدخل في بعض المشاريع الحقيقية، الا ان سكرم لا يقوم بتعريف أي أدوار الفريق غير تلك الموضحة أدناه:
مالك المنتج
مالك المنتج يمثل أصحاب المصلحة وهو صوت العميل. هو مسؤول عن ضمان أن الفريق يسلم قيمة لرجال الأعمال. مالك المنتج يكتب (أو لديه فريق الكتابة) البنود التي تركز على العملاء (عادة قصص المستخدم)، ويرتبها ويضع والأولوية لهم، ويضيفها إلى قائمة متطلبات المنتج Product backlog . وينبغي أن يكون فرق سكرم مالك منتج واحد فقط، وبينما قد يكون أيضا عضوا في فريق التطوير، ولكن لا يمكن الجمع بين هذا الدور مع أن من سكرم ماستر.
دور المالك المنتج في تعريف والتواصل المنتج متطلبات:
التواصل هو الوظيفة الرئيسية لصاحب المنتج. القدرة على نقل الأولويات والتعاطف مع أعضاء الفريق وأصحاب المصلحة أمر حيوي لتوجيه المشروع في الاتجاه الصحيح. سد فجوة التواصل بين الفريق وأصحاب المصلحة. وهو بمثابة وكيل لأصحاب المصلحة فريق التطوير وكممثل فريق المشروع للمجتمع أصحاب المصلحة بشكل عام.
كما يوجه الفريق لأصحاب المصلحة، وفيما يلي بعض المهام الاتصالات من صاحب المنتج إلى أصحاب المصلحة:
- يوصل الحلول لأصحاب المصلحة الرئيسيين الذين لم يكونوا موجودين في العرض التكرار العادي
- يعلن الاصدارات من المنتج
- يوصل وضع أو حالة الفريق
- تنظم علامات المراجعة
- يثقف أصحاب المصلحة في عملية التطوير
- يتفاوض الأولويات، ونطاق، والتمويل، والجدول الزمني
- يضمن أن قائمة متطلبات المنتج Product backlog مرئية وشفافة واضحة
التعاطف هو السمة الرئيسية لصاحب المنتج لديهم - القدرة على وضع الذات في موقف الآخر.
ويقوم مالك المنتج بالتحدث مع مختلف أصحاب المصلحة في المشروع - مختلف الناس، مع مجموعة متنوعة من الخلفيات والأدوار المهمة، والأهداف.
و يجب أن يكون صاحب المنتج قادرا على رؤية وجهات النظر المختلفة لكي يكون فعالا.
وأيضا من الحكمة بالنسبة لمالك المنتج معرفة مستوى التفاصيل التي يطلبها الآخر منه، ففريق التطوير تحتاج إلى ردود ومواصفات دقيقة حتى يتمكنوا بناء المنتج حسب التوقعات، في حين أن الراعي التنفيذي قد تحتاج ملخصات فقط، وتزويدأصحاب المصلحة بمعلومات أكثر من اللازم قد يفقدهم الاهتمام ويتسبب بإضاعة الوقت.
وهناك أيضا أدلة كبيرة أن التواصل وجها لوجه حول لوحة أو رسم مشترك هو أنجح وسيلة لتوصيل المعلومات بدلا من الوثائق. وسيلة اتصال مباشرة هو ما يفضله معظم أصحاب المنتجات اجايل المحنكين.
ومما يعزز قدرة مالك المنتج على التواصل بشكل فعال أيضا كونه ماهرا في التقنيات التي تحدد احتياجات أصحاب المصلحة، والتفاوض علي الأولويات بين مصالح أصحاب المصلحة، والتعاون مع المطورين لضمان التنفيذ الفعال للمتطلبات.
فريق التطوير
فريق التطوير مسؤول عن تقديم زيادات (إصدارات) محتملة ممكن تسليمها من المنتج Potentially Shippable Increments (PSIS) في نهاية كل سبرنت (هدف السبرنت)، ويتطلب من 3-9 أفراد ذوي مهارات متعددة الوظائف للقيام بهذا العمل الفعلي (تحليل وتصميم وتطوير واختبار، والاتصالات التقنية، توثيق، وما إلى ذلك). فريق التطوير في سكرم هو ذاتي التنظيم، على الرغم من أنه قد يكون هناك مستوى معين من التفاعل مع مكاتب إدارة المشاريع (PMOS).
سكرم ماستر
السكرم ماستر أو مدير السكرم أو منسق السكرم ويكون مسؤولا عن تسهيل أعمال السكرم، فيكون مسؤولا عن إزالة العوائق التي تَحُول دون قدرة الفريق على تقديم أهداف المنتج وإنجازها، والسكرم ماستر ليس قائدا للفريق (بالإنجليزية: team leader) أو مدير مشروع (بالإنجليزية: project manager)، ولكن يعمل بصفته منطقة عازلة بين الفريق وأي تأثيرات تشتيتية. والسكرم ماستر يضمن أن يتم استخدام عملية سكرم على النحو المنشود. والسكرم ماستر هو المنفذ لقواعد نظام السكرم، وغالبا ما يترأس الاجتماعات الرئيسة، ويتحدى ويشجع الفريق ليتحسن. كما يمكن اعتبار الدور على أنه الزعيم الخادم لتعزيز وجهات النظر المزدوجة. والسكرم ماستر يختلف عن مدير المشروع في أن هذا الأخير يقوم بإدارة الأفراد وعليه مسؤوليات لا علاقة لها بدور سكرم ماستر. يستبعد دور ماستر سكرم أي من هذه المسؤوليات الإضافية. في الواقع، ليس هناك دور مدير المشروع في سكرم، وممارسة سكرم مع وجود مدير مشروع قد يسبب صعوبات. [ 13 ]
الأحداث
سبرنت
السبرنت (بالإنجليزية: sprint) وتعني حرفياً «فترة زمنية شهرية» هي الوحدة الأساسية للتطوير في السكرم. وهي جهد محدد المدة مسبقاً (بالإنجليزية: timeboxed) أي يقتصر على مدة محددة. وعادة ما تكون بين أسبوع واحد وشهر واحد، على الرغم من ان أسبوعين هي النموذجية.
يتم تحديد أهداف كل سباق في اجتماع التخطيط، حيث يتم تحديدالمهام وتقدير الالتزامات كهدف من السبرنت، وتنتهي باجتماع مراجعة واجتماع تقييم للسبرنت، حيث يتم مراجعة التقدم والدروس المستفادة للسباق المقبل والتي تم تحديدها. سكرم يبرز في نهاية سبرنت العمل الذي «تم انجازه» (done.) في حالة من البرمجيات، يعني هذا نظام متكامل، تم اختباره بشكل كامل، وتوثيقه للمستخدم النهائي، وقابل للشحن أو التسليم.
الاجتماعات
اجتماع التخطيط سبرنت (Planning)
يقام في بداية دورة السباق (كل 7-30 أيام)، «اجتماع التخطيط سبرنت»:
- يحدد العمل الذي يجب القيام به
- إعداد قائمة المهام مع تفصيل الوقت الذي يستغرقه القيام بالعمل، مع الفريق بأكمله
- تحديد كم العمل المرجح أن يتم ذلك خلال سباق الحالي
- المدة 8 ساعات
(الأربعة ساعات الأولي) فريق سكرم بأكمله: حوار لتحديد أولويات قائمة المهام للمنتج (Product backlog). (الأربعة ساعات التالية) فريق التنمية: وضع خطة لسبرنت، مما ينتج عنه قائمة المهام للمنتج (Product backlog).
اجتماع سكرم اليومي
كل يوم خلال السباق، يحدث لقاء التواصل فريق المشروع. وهذا ما يسمى سكرم اليومي (الاجتماع) (أو «موقف متابعة اجتماع stand-up meeting») وله مبادئ توجيهية محددة:
- جميع أعضاء فريق التطوير أن يأتي مستعدا مع التحديثات للاجتماع.
- يبدأ الاجتماع على وجه التحديد في الوقت المحدد حتى لو كان بعض أعضاء فريق التطوير غائبين.
- يجب أن يحدث الاجتماع في نفس المكان ونفس الوقت كل يوم.
- يتم تعيين طول الاجتماع (timeboxed) إلى 15 دقيقة.
- الجميع مرحب به، ولكن عادة أصحاب الأدوار الأساسية هم من يتحدث.
وخلال الاجتماع، كل عضو في الفريق يجيب عن ثلاثة أسئلة:
- ماذا فعلت امس ان ساعد فريق تطوير تلبية هدف السباق؟
- ماذا سأفعل اليوم لمساعدة فريق التطوير تلبية هدف السباق؟
- هل أرى أي عائق يمنعني أو يمنع فريق التطوير من تلبية هدف السباق؟
يتم توثيق أي عائق / حجر عثرة المحددة في هذا الاجتماع من قبل السكرم ماستر ويعمل على حلها خارج هذا الاجتماع. لا يجوز لأي مناقشات مفصلة في هذا الاجتماع.
اجتماعات نهاية سبرنت (اجتماع مراجعة سبرنت واجتماع تقييم سبرنت)
في نهاية دورة سباق يعقد اجتماعين: «اجتماع المراجعة (Review)» و «اجتماع تقييم سبرنت (Retrospective)».
في الاجتماع سبرنت المراجعة (Review):
- مراجعة العمل الذي اكتمل والعمل المخطط له أن لم تكتمل
- عرض الأعمال المنجزة إلى الجهات المعنية (ويعرف أيضا باسم «لعرض»)
- لا يمكن أظهرت عمل غير مكتمل
- مدته 4 ساعات
في اجتماع تقييم سبرنت (Retrospective):
- يقوم جميع أعضاء فريق سكرم بتحليل السباق الماضي
- عمل تحسينات مستمرة للعملية
- ويطلب من كل منهم اجابة سؤالين رئيسيين في اجتماع تقييم سبرنت:
- ما الذي تم على ما يرام خلال سباق؟
- ما الذي يمكن تحسينه في سباق المقبل؟
- مدته 3 ساعات
- هذا الاجتماع يتم بإشراف السكرم ماستر
ملحقات
صقل قائمة مهام المنتج (Product backlog)
تراكم الصقل هو عملية مستمرة لمراجعة بنود تراكم المنتجات والتأكد من انهم الأولوية بشكل مناسب وأعدت بطريقة يجعلها واضحة وقابل للتنفيذ لفرق بمجرد دخولهم سباقات السرعة عن طريق النشاط التخطيط العدو. ويمكن تقسيم العناصر تراكم المنتجات إلى عدة أصغر حجما، ويمكن توضيح معايير القبول، أو الأعمال التحضيرية جديد مثل توضيحات بشأن احتياجات العميل أو طفرات تقنية يمكن تحديد.
تراكم الصقل ليس سكرم الممارسة الأساسية ولكن اعتمد كوسيلة لإدارة نوعية المواد المتراكمة الدخول في سباق.
اجتماع سكرم السكرمّات
اجتماع سكرم السكرمات (بالإنجليزية: Scrum of Scrums) هو تقنية لتوسيع نطاق السكرم لتصل إلى مجموعات التنمية الكبيرة (أكثر من اثني عشر شخصا)، والذي يسمح مجموعات من فرق لمناقشة عملهم، مع التركيز بشكل خاص على مجالات التداخل والتكامل. كل سكرم اليومي ضمن فريق الفرعي ينتهي من خلال تعيين عضو واحد ك «سفير (ambassador)» للمشاركة في لقاء يومي مع سفراء من الفرق الأخرى. اعتمادا على السياق، قد يكون سفراء مساهمين فنيين، أو سكرم ماسترز.
وجدول الأعمال يكون مثل سكرم يومي، مع الأسئلة الأربعة التالية:
- ما قام به فريقك منذ التقينا آخر مرة؟
- ماذا سيفعل فريقك قبل أن نجتمع مرة أخرى؟
- وأي شيء يتباطأ الفريق الخاص بك إلى أسفل أو الحصول في طريقهم؟
- هل أنت على وشك وضع شيء في طريقة فريق آخر؟
ومن المتوقع قرار معوقات التركيز على تحديات التنسيق بين الفرق، وربما يترتب عليه يوافقون على واجهات بين الفرق، والتفاوض على حدود المسؤولية، وما إلى ذلك سكرم من Scrums سوف تتبع هذه البنود عمل من خلال تراكم من تلقاء نفسها، حيث كل عنصر يساهم في تحسين التنسيق بين فريق.
يقول جيف ساذرلاند:
وبما أنني في الأصل الذي قمت بتعريف scrum of scrums(وكان كين شفابر يعمل معي في IDX)،
فإنه يمكنني أن أقول بشكل قاطع انه ليس معلومات عن سكرم "not a meta scrum ". ولكنه كما استخدمته مسؤول عن تقديم العمل في نهاية السبرنت من جميع الفرق إلى ما قد تم تعريفه على انه «تم انجازه done»، أو كاأصدارات في اثناء السبرنت.
- PatientKeeper تقوم بعمل تسليم الإنتاج أربع مرات في سباق.
- Ancestry.com تقوم بعمل تسليم الإنتاج 220 مرات في من سباق من أسبوعين.
- Hubspot يسلم البرامج الحية 100-300 مرات في اليوم.
يقام سكرم لعدد من السكرم ماستر للمساءلة لجعل هذا العمل يتم.
لذلك سكرم السكرم هي آلية تسليم التشغيلية.
تعريفات Artifacts
قائمة مهام المنتج Product backlog
قائمة مهام المنتج (Product backlog) هو قائمة مرتبة من المتطلبات المحفوظة لمنتج .
وهو يتألف من الخصائص، الإصلاحات، متطلبات غير وظيفية، وما إلى ذلك كل ما يجب القيام به من أجل تقديم منتج قابل للحياة بنجاح.
بنود قائمة مهام المنتج Product backlog Items (PBIs) هي مرتبة من قبل مالك المنتج (Product Owner) بناء على اعتبارات مثل المخاطرة، القيمة التجارية، الاعتماديات، التاريخ المطلوب، الخ
عادة العناصر المضافة إلى القائمة تكون في شكل قصص المستخدم.
قائمة مهام المنتج هو ما سوف يتم تسليمه، بالتسلسل أو الترتيب الذي يجب تسليمه به.
القائمة مفتوحة وقابلة للتحرير من قبل أي شخص، ولكن مالك المنتج هو المسؤول في النهاية عن ترتيب البنود المدرجة على القائمة لفريق التطوير للاختيار.
تحتوي قائمة مهام المنتج على تقييم مالك المنتج من قيمة الأعمال وتقييم فريق تطوير من جهود التنمية، والتي هي في كثير من الأحيان، ولكن ليس دائما، تذكر علي هيئة نقاط باستخدام تقييم أرقام متسلسلة فيبوناتشي .
هذه التقديرات تساعد مالك المنتج لقياس خط زمني وقد تؤثر على ترتيب البنود المتراكمة.
على سبيل المثال، إذا كانتا «إضافة التدقيق الإملائي» و «إضافة دعم الجدول» مهمتين لهما القيمة التجارية نفسها للعميل، فان مالك المنتج قد يقدم المهمة ذات المجهود الأقل في التطوير (لأن العائد على الاستثمار (ROI) سيكون أعلى) أو يقدم تلك ذات المجهود الاعلي (لأنها أكثر تعقيدا أو أكثر مخاطرة، هو يريد أن يتخلص من هذه المخاطرة مبكرا).
قائمة مهام المنتج والقيمة التجارية لكل بند فيها هو من مسؤولية مالك المنتج.
حجم كل بند من بنود قائمة مهام المنتج (أي التعقيد أو جهد أي قدر) يحدده فريق التنمية، والذي يساهم في تحجيم البنود، سواء على حسب الصعوبة أو عدد ساعات العمل المقدرة في تطويرها.
هناك سوء فهم شائع بأن قصص المستخدم الوحيدة التي يسمح بها في قائمة مهام المنتج . على النقيض من ذلك، سكرم محايدة في أي تقنيات تقوم باضافة البنود. وينص سكرم على:
البنود في قائمة مهام المنتج تكتب بأي شكل من الأشكال مدامت واضحة ومحفوظة.
خلافا لسوء الفهم الشائع، فانها لا تحتوي على «قصص المستخدم» ولكن تحتوي ببساطة على البنود. ويمكن التعبير عن هذه البنود كقصص مستخدم user stories، حالات الاستخدام use cases، أو أي اسلوب لذكر متطلبات أخرى يراه الفريق مفيد.
ولكن أيا كان الاسلوب، ينبغي أن تركز معظم البنود على تقديم أو إضافة قيمة تجارية للعملاء
سكرم ينص على أن يتم تحديد دور مالك المنتج : مالك المنتج هو المسؤول عن تعظيم قيمة المنتج وعمل فريق التطوير. مالك المنتج يجمع المدخلات، ويأخذ ردود الفعل من قبل كثير من الناس، ولكنه يبني في نهاية المطاف القرار فيما يتم بناؤه. كما أنه وحده المسؤول عن إدارة قائمة مهام المنتج .
يتم استخدام قائمة مهام المنتج في:
- تحديد طلبات تعديل المنتج: هذا يمكن أن يشمل إضافة ميزات جديدة، لتحل محل الميزات القديمة، وإزالة الميزات وإصلاح المشاكل
- ضمان ان فريق التطوير يقوم بتسليم منتج ذى قيمة تجارية تزيد من استفادة صاحب العمل
عادة، صاحب المنتج وفريق التطوير معا يقومان بكتابة كل ما يحتاج إليه العمل ووضع الأولويات ويصبح هذا هو المحتوى للسبرنت الأول، هو كتلة العمل باطار زمني مركز على العناصر المحددة التي يمكن استيعابها ضمن هذا الإطار الزمني. هذا ويسمح لقائمة مهام المنتج أن تتطور وفقا لتطرق معلومات جديدة حول المنتج وعملائه، والعمل الجديد يدرج في السباقات المقبلة (next sprints).
تشمل قائمة مهام المنتج العناصر التالية عادة: الخصائص (features)، والمشاكل (bugs)، والعمل الفني (Technical work)، واكتساب المعرفة (knowledge acquisition).
في مجال تطوير الويب، وهناك التباس بين الخصائص والمشاكل، من الناحية الفنية الميزة الخصائص «مطلوبات»، في حين أن المشاكل هو سمة من سمات هذا هو «غير مقصودة» أو «غير مرغوب فيه» (ولكن قد لا يكون بالضرورة شيء معيب).
ومثال على العمل الفني : «تشغيل اختبار الفيروسات على كافة محطات العمل للمطورين».
ومثال على اكتساب المعرفة يمكن أن يكون بند من بنود سكرم في قائمة المنتج حول البحث مكتبات وورد برس Wordpress ثم عمل اختيار.
إدارة قائمة مهام المنتج بين مالك المنتج وفريق التطوير
قائمة مهام المنتج في أبسط أشكالها، هي مجرد قائمة البنود التي يجب العمل عليها. وجود قواعد راسخة حول كيفية إضافة، إزالة وترتيب البنود يساعد الفريق بأكمله على اتخاذ قرارات أفضل حول كيفية تغيير المنتج.
صاحب المنتج يعطي الأولوية لبنود المنتج الأكثر الحاحا. ثم يختار الفريق البنود التي يمكن اكمالها في السبرنت التالي. على لوحة سكرم، يحرك الفريق البنود من قائمة مهام المنتج إلى قائمة مهام السبرنت وهي قائمة من البنود التي سوف يتم بناؤها. من الناحية النظرية، فإنه مثالي للفريق تحديد فقط ما يعتقدون أنهم يمكنهم إنجازه من أعلى القائمة، ولكن ليس من الغريب أن نرى ممارسات حيث يختار الفريق بنودا اقل الأولوية من القائمة جنبا إلى جنب مع تلك التي على القمة . هذا يحدث عادة بسبب وجود وقت متبقي ضمن السبرنت لاستيعاب المزيد من العمل.
البنود في الجزء العلوي من قائمة المهام هي العناصر التي هي على وشك أن تنفذ أولا، وهذه ينبغي تقسيمها إلى نقاط أو قصص اصغر ملائمة لفريق التسليم للعمل عليها. كلما اتجهنا أسفل كلما قلت الأولوية والتفاصيل. و كما صاغاها شفابر وبيدل «كلما كان أقل في الأولوية، كان أقل في التفاصيل، حتى انك تكاد ان تلقيه خارج القائمة».
بينما يعمل الفريق خلال القائمة، فإنه يحتاج إلى افتراض أن «التغييرات في العالم يمكن أن يحدث» يمكن للفريق معرفة الفرص الجديدة في الأسواق للاستفادة من التهديدات التي قد تنشأ عن المنافسين ، اوالتغذية الممكنة من العملاء التي يمكن أن تغير الطريقة كان من مفترضة لعمل المنتج . كل هذه الأفكار الجديدة تميل إلى تحريك الفريق للتكييف القائمة لدمج المعرفة الجديدة. وهذا جزء من العقلية الأساسية لفريق اجايل. العالم يتغير، والقائمة لا تنتهي أبدا .
قائمة مهام سبرنت Sprint backlog
قائمة مهام سبرنت هي بنود العمل التي يجب على فريق التطوير معالجتها خلال السبرنت التالي.
تشتق القائمة من خلال اختيار العناصر من أعلى قائمة مهام المنتج حتى يشعر فريق التطوير ان لديه ما يكفي من العمل لملء السبرنت . يتم ذلك من قبل فريق تطوير يسأل «هل يمكننا أيضا القيام بذلك؟» ويقوم بإضافة بنود قائمة مهام المنتج إلى السبرنت. فريق التطوير لابد ان يأخذ في الاعتبار الأداء في الماضي وتقييم قدرته على سبرنت جديد، واستخدام هذا كخط دليل عن مقدار ال «جهد» الذي يمكنهم عمله.
ثم يتم تكسير هذه البنود إلى واجبات من قبل فريق التطوير. لا يتم اسناد المهام على قائمة مهام سبرنت أبدا. بدلا من ذلك، يتم توقيع المهام من جانب أعضاء الفريق حسب الحاجة وفقا للأولوية ومهارات أعضاء فريق التطوير. وهذا يعزز التنظيم الذاتي لفريق التطوير.
قائمة مهام سبرنت هي ملك لفريق التطوير، ويتم توفير جميع التقديرات الواردة من قبل فريق التطوير. وكثيرا ما يستخدم لوحة مهمة مصاحبة لرؤية وتغيير حالة مهام السبرنت الحالي، مثل : «مدرج للقيام به»، «جاري العمل به» و «تم انجازه».
متى تم الانتهاء من اختيار قائمة مهام سبرنت، فانه لا يمكن إضافة أي وظيفة إضافية إلى قائمة مهام سبرنت إلا من قبل فريق التطوير.
متى تم تسليم مهام سبرنت ، فانه يتم تحليل قائمة مهام المنتج وتحديد الأولويات إذا لزم الأمر، ثم يتم اختيار المجموعة التالية من الوظائف للسبرنت المقبل
نمو المنتج Product Increment
النمو (أو الإضافة القابلة للتسليم، potentially shippable increment PSI) هي مجموع جميع التطويرات أو البنود بقائمة المنتج التي أنجزت خلال سبرنت معين وجميع سباقات السبرنت السابقين. في نهاية السبرنت، يجب أن يتم النمو وفقا لمعايير فريق سكرم التي تضع تعريفا لانجاز البنود Definition of Done (DoD).
يجب أن تكون الزيادة في حالة صالحة للاستعمال بغض النظر عن ما إذا كان مالك المنتج يقرر التسليم فعلا.
رسم بياني للإنجاز Burndown chart
رسم سبرنت البياني ينشر علنا ويوضح العمل المتبقي في السبرنت
و يتم تحديثه كل يوم، وأنه يعطي لمحة بسيطة عن تقدم السبرنت. كما يقدم تصوير سريع للمراجع.
وهناك أيضا أنواع أخرى من الرسم البياني (burndown)، على سبيل المثال الرسم البياني للاصدارات (burndown release) التي تظهر حجم العمل المتبقي لاستكمال الالتزام كهدف لإطلاق المنتج (تمتد عادة من خلال دورات متعددة).
وهناك الرسم البياني للاصدارات البديلة (alternative release burndown chart) "'، [2]
الذي يقوم في الأساس نفسه، ولكن من الواضح يبين التغييرات مجالا لإطلاق سراح المحتوى، عن طريق إعادة خط الأساس.
لا ينبغي الخلط بينه ومع الرسم البياني للقيمة المكتسبة.
مصطلحات
وغالبا ما تستخدم المصطلحات التالية في عملية سكرم.
- فريق سكرم Scrum Team
يتكون من مالك المنتج Product Owner ، سكرم ماستر Scrum Master فريق التطوير Development Team
- مالك المنتج Product Owner
الشخص المسؤول عن الحفاظ على قائمة مهام المنتج والذي يمثل مصالح أصحاب العمل، وضمان قيمة العمل الشخص فريق تطوير
- سكرم ماستر Scrum Master
مسؤول عن عملية سكرم، والتأكد من أنها استخدمت بشكل صحيح، والعمل أقصى استفادة منها
- فريق التطوير Development Team
هي مجموعة من الناس مسؤولة عن تقديم اضافات ممكنة التسليم من المنتج في نهاية كل Sprint
- Sprint burn down chart
مستوى التقدم على مدار السبرنت
- Release burn down chart
مستوى التقدم في البنود المنجزة من قائمة المنتج
- Product backlog (PBL)
قائمة مهام المنتج (PBL) قائمة المتطلبات المجملة مرتبة حسب أولوياتها
- Sprint backlog (SBL)
قائمة الأولويات من المهام التي ينبغي الانتهاء منها خلال سبرنت
- Sprint
فترة زمنية (عادة 1-4 أسابيع) و الذي تحدث التنمية فيه على مجموعة من بنود قائمة مهام المنتج التي التزم بها الفريق
كما يشار إليها عادة بوصفها دورة زمنية Time-box or iteration
- Spike
هو فترة محددة الوقت تستخدم لبحث مفهوم و / أو لإنشاء نموذج بسيط prototype.
يمكن أن يتم الاتفاق على عقده بين دورات سبرنت أو لفرق الأكبر، يكون مقبولا اعتبارها واحدة من أهداف تسليم السبرنت.
وغالبا ما يقدم سبايك قبل تسليم بنود معقدة من قائمة مهام المنتج من أجل تأمين الميزانية، توسيع المعرفة، و / أو إنتاج دليلا على المفهوم proof of concept.
يتم الاتفاق على مدة والهدف (السبايك) مقدما بين مالك والمنتج وفريق التطوير قبل بداية.
وخلافا للالتزامات سبرنت فان سبايك قد لا يسلم تطويرات ملموسة ممكنة التسليم، أو وظائف ذات قيمة.
على سبيل المثال، فإن الهدف من سبايك قد يكون الوصول بنجاح إلى قرار بشأن مسار العمل.
ينتهي سبايك عندما يحين الوقت، وليس بالضرورة عندما يتم تسليم هذا الهدف.[بحاجة لمصدر]
- Tracer Bullet
اطلاقة التتبع هي سبايك بالتخطيط الحالي، والتكنولوجيا الحالية، والمجموعة الحالية من أفضل الممارسات التي تؤدي إلى جودة الإنتاج. قد يكون مجرد تنفيذا على نطاق ضيق جدا لبعض الوظائف ولكن ليس عملا مؤقتا يرمى بعد ذلك . ومن جودة الإنتاج وبقية الدورات يمكن متابعة بناء هذا العمل.
الاسم لديه أصول عسكرية من تتبع مسار رصاصة ، مما يسمح للتصحيحات.
غالبا ما تكون هذه التطبيقات هي «لقطة سريعة» من خلال جميع طبقات البرنامج، مثل ربط حقل إدخال form's input field إلى back-end ، لإثبات ان الطبقات ستربط كما هو متوقع.
- Tasks
المهمات Tasks تضاف إلى قائمة مهام السبرنت في البداية ومقسمة إلى ساعات.
لا ينبغي أن تتجاوز كل مهمة 12 ساعة (يوم أو يومين)،
ولكن من الشائع للفرق الإصرار على أن المهمة لا تاخذ أكثر من يوم لانجازها.
- تعريف منجز Definition of Done (DoD)
تعريف منجز هو معايير لتحديد ما إذا كان بند القائمة المنتجقد تم انجازه كاملا.
في كثير من الحالات يتطلب DoD أن جميع الاختبارات تكون ناجحة. تعريف «منجز» قد تختلف من فريق سكرم إلى آخر، ولكن يجب أن تكون متسقة ضمن الفريق الواحد.
- اللزوجة Velocity
هي قدر الجهد الكلي الذي يكون الفريق قادرا على انجازه في سبرنت. الرقم يحسب من تقييم العمل (عادة في قصة المستخدم كنقاط) المنجز من قائمة مهام سبرنت الماضية.
تجميع بيانات عن قيمة اللزوجة للفريق هو دليل توجيهي لمساعدة الفريق في فهم مقدار العمل الذي يمكن القيام به في المستقبل
- العوائق Impediment
ما يمنع أحد أعضاء الفريق من أداء العمل بأكبر قدر من الكفاءة.
- ساشيمي Sashimi
مصطلح يستخدم لوصف واحد أو أكثر من قصص المستخدم، موضحين انها شرائح رقيقة من خصائص المنتج حيث تُشبه قصص المستخدم بالساشيمي وهو طبق ياباني مكون من شرائح رقيقة من المآكولات البحرية.
- إنهاء غير طبيعي Abnormal Termination
المنتج المالك يمكنه إلغاء سبرنت إذا لزم الأمر.
مالك المنتج قد يفعل ذلك مع معطيات من الفريق، سكرم ماستر أو الإدارة.
على سبيل المثال، قد ترغب الإدارة لإلغاء سبرنت إذا كانت الظروف الخارجية تناقض القيمة المكتسبة من هدف السبرنت.
إذا تم إنهاء السبرنت بشكل غير طبيعي، فإن الخطوة التالية هي عقد اجتماع تخطيط سبرنت الجديد، حيث يناقش سبب الإنهاء
- استثناء سكرم ScrumBut
هو استثناء من منهجية سكرم ال«نقية»، حيث يغير الفريق منهجيتة لتكيفه معها
- سكرم حقيبة ScrumBag
يشير إلى أي شخص أو مجموعة، أو أي عوائق أخرى يمكن أن تكون عقبة.
سكرم بان Scrum-ban
سكرم بان -هو نموذج برمجي للإنتاج مبني على سكرم وكانبان (Kanban).
وهو مناسب خاصة بالنسبة للمشاريع الصيانة أو الأنظمة مع عناصر العمل أو اخطاء البرمجة المتكررة وغير متوقعة.
وفي مثل هذه الحالات فان دورات سبرنت محددة المدة بنظام سكرم تكون غير ذات جدوى ملموس، ولكن اجتماعات سكرم اليومية والممارسات الأخرى يمكن تطبيقها، اعتمادا على الفريق والإمكانية.
التصوير الايضاحي لمراحل العمل وقيود العمل المتزامن غير المكتمل والعيوب هو مألوف من نموذج كانبان.
باستخدام هذه الأساليب، يتم توجيه سير العمل الفريق بطريقة تسمح الحد الأدنى من الوقت لإنجاز كل عنصر العمل، ومن ناحية أخرى يضمن ان عضو في الفريق يعمل باستمرار.
لتوضيح كل مرحلة من مراحل العمل، فان الفرق التي تعمل في نفس المساحة غالبا ما تستخدم post-it notes ملاحظات تنبيهية علي لوحة بيضاء كبيرة.
وفي حالة الفرق اللامركزية، تستخدم البرمجيات الايضاحية للمراحل مثل: Assembla, TargetProcess, Eylean Board, JIRA or Agilo for Scrum.
وفي أبسط الصور، يتم تصنيف المهام في مراحل العمل:
- غير مبدوء
- مستمر
- مكتمل
وحسب الرغبة، رغم ذلك، يمكن إضافة الفريق مزيدا من مراحل العمل (مثل «محدد»، «مصمم»، «مختبر» أو «مسلم»).
ويمكن لهذه المراحل الإضافية ان تكون مساعدة إذا أصبح جزء معين من العمل كعنق الزجاجة ولا يمكن رفع القيم التي تحد من العمل غير المكتمل.
و تقسيم العمل بطريقة أكثر تحديدا هكذا يعطي الفرصة للموظفين للتخصص في مرحلة معينة من العمل.
لا توجد مجموعة من قيم الحد من العمل غير مكتمل.
ولكن كل فريق يحدد ذلك بشكل فردي عن طريق التجربة والخطأ.
القيم الصغيرة جدا قد يتنتج عنها سكون في العمل، في حين أن القيم العالية جدا قد تؤدي إلى تراكم كميات كبيرة من العمل غير المكتمل، وهذا بدوره يعيق الأوقات الانتهاء.
وبحكم التجربة يجدر الأخذ في الاعتبار أنه لا ينبغي لأي من أعضاء الفريق أن يسند اليه أكثر من مهمتين في وقت واحد، وعلاوة على ذلك، لا ينبغي أن يكون جميع أعضاء الفريق لديهم مهمتين في وقت واحد.
ومن الاختلافات الرئيسية بين سكرم وكانبان حقيقة أنه في سكرم، وينقسم العمل في سباقات (سبرنت) تستمر لفترة محددة من الزمن، في حين أنه في كانبان سير العمل مستمر.
وهذا يظهر واضحا في جداول مراحل العمل، والتي في سكرم يتم تفريغها بعد كل سباق. في حين انه في نظام كانبان توضع جميع المهام على جدول واحد.
يركز سكرم على أن الفرق متعددة الأوجه المعرفية، في حين كانبان يسمح بالتخصص الفني للفرق.
حيث أن سكرم بان هو نموذج تطويري جديد، فليس هناك الكثير من المواد المرجعية. في حين ان كانبان، من ناحية أخرى، تم تطبيقه من قبل مايكروسوفت وكوربيس.
الأدوات
مثل أساليب آجايل الأخرى، فإن سكرم يمكن تنفيذها من خلال مجموعة واسعة من الأدوات.
العديد من الشركات تستخدم الأدوات العالمية، مثل جداول البيانات (spreadsheets) لبناء وصيانة الأساسيات مثل r. وهنقائمة مهام سبرنت كم يوجد أيضا عديد من البرمجيات ذات المصدر المفتوح مخصصة لإدارة المنتجات في إطار عملية سكرم.
شركات أخرى تنفذ سكرم دون استخدام أي أدوات البرمجيات، وتنفيذ الأساسيات في أشكال ورقية مثل الورق والسبورات والملاحظات اللاصقة.
القيود
من الشائع عمل تهجين في نموذج سكرم ، حيث أن سكرم لا يغطي دورة حياة كامل لتطوير المنتجات .
لذا، تجد المنظمات في حاجة إلى إضافة عمليات إضافية لخلق تنفيذ أكثر شمولا.
على سبيل المثال، في بداية المشروع، تضيف المنظمات عادة توجيه لعملية جمع المتطلبات وتحديدالأولويات، والتصميم الأولي على المستوى العام، والميزانية وجدول التنبؤالزمني .
ورغم ذلك، فإن إطار سكرم لا يسمح صراحة بإضافة نقاط من هذا النوع؛ وبالتالي، فإن تحقيقا أكثر شمولا لدورة حياة البرمجيات يتطلب توسيع الإطار بدلا من تمثيله
انظر أيضا
مراجع
- ^ "New Product Development Game". Harvard Business Review 86116:137–146, 1986. 1 يناير 1986. مؤرشف من الأصل في 2014-11-11. اطلع عليه بتاريخ 2013-03-12.
- ^ قالب:يستشهد على شبكة الإنترنت
وصلات خارجية
روابط خارجية
 |
في كومنز صور وملفات عن: سكرم |
