هل تواجه مشكلة في تتبع المهام غير المكتملة بنهاية كل أسبوع تطوير؟ يقترح نظام جديد طريقة ذكية للحفاظ على حالة عملك الحقيقية ونقله بسلاسة إلى الدورة التالية دون إغلاقه بشكل خاطئ.
مرحبًا يا عشاق التقنية! هل سبق لكم أن وجدتم أنفسكم في نهاية أسبوع عمل، والكود البرمجي جاهز تمامًا، لكن اختبارات التحقق على الهواتف المحمولة لم تكتمل بعد؟ هذه معضلة شائعة، حيث قد يدفعنا ضغط إغلاق الدورة الأسبوعية إلى تأشير المهمة على أنها 'مكتملة'، بينما هي في الحقيقة ليست كذلك. هذا الأمر يمكن أن يخلق فوضى ويجعل العمل غير المكتمل يبدو كما لو كان منتهيًا.
الخبر السار هو أن هناك طريقة مقترحة للتعامل مع هذا الموقف بذكاء. بدلاً من إغلاق المهام قبل أوانها، يمكننا الحفاظ على الحالة الفعلية لمهمة العمل وتحديد ما يجب نقله إلى دورة العمل التالية. هذا يعني أن نهاية الأسبوع لا تعني بالضرورة أن كل شيء يجب أن يُختم كـ'مُنجز'؛ فاستعداد الميزة للتوزيع يختلف عن انتهاء الأسبوع.
لنأخذ مثالاً من الحياة الواقعية: ميزة 'المشاركين التجريبيين' في تطبيق SquadNote. هذه الميزة، التي تغطي أذونات المشاركين وتوافق عناوين URL للدعوة وغيرها، تتطلب سلوكًا متسقًا على منصات الويب وiOS وأندرويد. عندما كان التنفيذ جاهزًا، بقيت فحوصات التحقق على الجوال غير مكتملة. الوثائق أظهرت أن فحوصات الويب قد اكتملت، بينما بعض فحوصات الجوال تمت، لكن البند الأخير لتأكيد اكتمال التحقق على الجوال لم يتم بعد.
الفكرة هنا بسيطة: الدورة التالية لا تحتاج إلى إعادة العمل بالكامل. يجب أن نحافظ على النسخة التي تم التحقق منها والنتائج التي تم الحصول عليها، ثم نحدد بالضبط ما الذي لم يتم فحصه وعلى أي جهاز.
وفقًا لوثائق نظام 'Plane' (الذي يستخدم لإدارة العمل)، فإن مهام العمل غير المكتملة تحتفظ بحالتها عند انتهاء الدورة ويمكن نقلها إلى دورة أخرى. صحيح أن مهمة العمل لا يمكن أن تنتمي إلا لدورة واحدة في كل مرة، لكن المثير للاهتمام هو أنها يمكن أن تنتمي إلى 'وحدات' متعددة، مثل وحدة خاصة بالميزة ووحدة خاصة بالإصدار.
لذا، بدلاً من إنشاء مهام مكررة، الحل هو الاحتفاظ بمهمة عمل واحدة وربطها بالفترة الزمنية المناسبة والناتج النهائي المطلوب. هذا يضمن الشفافية والمساءلة، ويمنع أي سوء فهم حول حالة التقدم الحقيقي للمشروع. هذا النهج المقترح يُبنى على معايير قبول حقيقية وسجلات تحقق، ويساعد فرق التطوير على إدارة عملهم بشكل أكثر فعالية وصدق.
الخبر السار هو أن هناك طريقة مقترحة للتعامل مع هذا الموقف بذكاء. بدلاً من إغلاق المهام قبل أوانها، يمكننا الحفاظ على الحالة الفعلية لمهمة العمل وتحديد ما يجب نقله إلى دورة العمل التالية. هذا يعني أن نهاية الأسبوع لا تعني بالضرورة أن كل شيء يجب أن يُختم كـ'مُنجز'؛ فاستعداد الميزة للتوزيع يختلف عن انتهاء الأسبوع.
لنأخذ مثالاً من الحياة الواقعية: ميزة 'المشاركين التجريبيين' في تطبيق SquadNote. هذه الميزة، التي تغطي أذونات المشاركين وتوافق عناوين URL للدعوة وغيرها، تتطلب سلوكًا متسقًا على منصات الويب وiOS وأندرويد. عندما كان التنفيذ جاهزًا، بقيت فحوصات التحقق على الجوال غير مكتملة. الوثائق أظهرت أن فحوصات الويب قد اكتملت، بينما بعض فحوصات الجوال تمت، لكن البند الأخير لتأكيد اكتمال التحقق على الجوال لم يتم بعد.
الفكرة هنا بسيطة: الدورة التالية لا تحتاج إلى إعادة العمل بالكامل. يجب أن نحافظ على النسخة التي تم التحقق منها والنتائج التي تم الحصول عليها، ثم نحدد بالضبط ما الذي لم يتم فحصه وعلى أي جهاز.
وفقًا لوثائق نظام 'Plane' (الذي يستخدم لإدارة العمل)، فإن مهام العمل غير المكتملة تحتفظ بحالتها عند انتهاء الدورة ويمكن نقلها إلى دورة أخرى. صحيح أن مهمة العمل لا يمكن أن تنتمي إلا لدورة واحدة في كل مرة، لكن المثير للاهتمام هو أنها يمكن أن تنتمي إلى 'وحدات' متعددة، مثل وحدة خاصة بالميزة ووحدة خاصة بالإصدار.
لذا، بدلاً من إنشاء مهام مكررة، الحل هو الاحتفاظ بمهمة عمل واحدة وربطها بالفترة الزمنية المناسبة والناتج النهائي المطلوب. هذا يضمن الشفافية والمساءلة، ويمنع أي سوء فهم حول حالة التقدم الحقيقي للمشروع. هذا النهج المقترح يُبنى على معايير قبول حقيقية وسجلات تحقق، ويساعد فرق التطوير على إدارة عملهم بشكل أكثر فعالية وصدق.
