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