اسمي فيكتور ، أنا محلل أنظمة في Sportmaster. واليوم أود أن أتحدث عن تفكيك المهام ونقلها إلى التطوير. يتكون أي كائن من أجزاء ، سواء كانت سيارة أو منتج برنامج. وسوف يستغرق الأمر وقتًا لتجميع أي من هذه الكائنات في وحدة واحدة من الأجزاء المكونة لها. في بعض الأحيان يستغرق وقتا طويلا جدا. خاصة إذا لم تفكك الجزء الرئيسي قبل ذلك فحسب ، بل قررت الوصول إلى الجزء السفلي منه على المستوى الذري.
أين الخط الفاصل بين الإعداد المناسب للمهام والفوضى الكاملة؟ سوف أشارك مثالاً عن كيفية تلقينا في Sportmaster بشكل دوري مهام التطوير من الأعمال.
كما ترى من الأمثلة المذكورة أعلاه ، فإن وصف كل مهمة يعتمد بشكل كبير على خيال العميل وحسّه السليم. في مكان ما يكون أكثر ، في مكان ما يكون أقل ، لكن المحللين بحاجة إلى العمل معه بطريقة ما. في بعض الأحيان يشيرون أيضًا إلى حدود الوظيفة ، وأحيانًا يرسلون موضوعًا فقط. إذا نقلنا مثل هذه المهمة مباشرة إلى التطوير ، فسنحصل على شيء غير مفهوم في المخرجات. ماذا يجب عليك أن تفعل؟
امش إلى العميل بقدميك واسأل عن جميع المتطلبات ، ووضح بالضبط ما يجب أن يكون عند المخرج. صحيح ، لا يزال هناك عملاء ذهب ، معظمهم في الواقع - يكتبون جميع المتطلبات في نقطة التقاءهم ، لذا يمكنك الذهاب وقراءتها في أي وقت وطرح الأسئلة. وعندما يكون كل شيء واضحًا بالفعل مع إطار عمل الميزة ، يمكنك البدء في قطع المهمة.
لماذا تتحلل
الهدف الرئيسي من التحلل هو أن يتمكن النشاط التجاري من تنفيذ جميع رغباته بسرعة ، بحيث يأخذ المستخدم أقل وقت ممكن من الفكرة نفسها إلى ظهور الوظيفة. للقيام بذلك ، يمكنك القيام بمهام أصغر ، والتي من خلالها ، وإن كانت صغيرة ، إلا أن وظيفة العمل ستصل إلى المستخدم.
بالإضافة إلى تحقيق الهدف العالمي المتمثل في تلبية احتياجات المستخدم والعمل ، يتيح لك تحليل المهام الحصول على ملاحظات أسرع من العميل ، سواء أكان التطوير يحفر في الاتجاه الصحيح ، أم أنه لم يتخيل على الإطلاق ما تخيله العميل.
إذا كانت المهمة كبيرة في البداية وقمنا بها بالكامل مرة واحدة ، فسنقضي الكثير من الوقت عليها وبعد تعليقات العميل ، سيتعين علينا التخلص من كل شيء. حسنًا ، إذا كانت المهمة صغيرة ، يوم أو يومين على الأكثر ، فلا بأس. سيستغرق إعادة العمل نفس المبلغ تقريبًا. الطريقة الثانية أرخص أيضًا. ناهيك عن الأعصاب المحفوظة على كلا الجانبين.
إذا تم تقسيم وظيفة واحدة إلى عدة أجزاء ، فيمكن للمطورين العمل عليها بشكل متوازٍ. وبالتالي ، سنقوم بموازنة التدفق وتسريع إخراج الوظيفة في المنتج. الشيء المهم هو أن المهام يجب أن تعتمد على بعضها البعض بأقل قدر ممكن.
بالإضافة إلى الاختبار السريع وإصلاح الأخطاء. مرة أخرى ، يعد اختبار الوظائف الصغيرة أسهل وأسرع بكثير من اختبار العملاق الوحشي. وإذا حدث خطأ ما ، فسينفق المطور القليل جدًا على "الإصلاح" وسيعمل كل شيء بشكل أسرع.
في مرحلة تقسيم المهام ، جنبًا إلى جنب مع العميل ، يمكنك على الفور فهم الوظائف المهمة هنا والآن ، من أجل البدء في جني الأرباح ، وما يمكن تركه لاحقًا ، وما قد لا يكون في حد ذاته غير ضروري.
من المهم للأعمال أن تعرف مدى سرعة ظهور وظائف العمل. وعندما يتم تقسيم المهام إلى مهام ، يمكننا التنبؤ بالوقت الذي سيستغرقه إكمالها وتقديره بدقة أكبر مما يحدث عندما يكون لديك واجهة عمل واحدة كبيرة. ولكن إلى جانب حقيقة أن المهام الصغيرة أسهل في التقييم من حيث الوقت اللازم لإنجازها ، فمن الأسهل أيضًا على المطور تقييم المخاطر التي قد تنشأ في عملية العمل.
على سبيل المثال ، تم تحديث الأطر ، وتم إخراج بعض الطرق من الخدمة ، ومشاكل في الكود ، وما إلى ذلك. من خلال أخذ المهام الصغيرة في العمل ، نقوم بتقليل كل هذه المخاطر ، وحتى إذا كانت مثل هذه المهمة تعيق شيئًا ما في الخيط ، فلن تكون حرجة كما لو كانت قطعة ضخمة (مما قد يمنع كل شيء على الإطلاق) إذا لزم الأمر ، سيكون من الممكن التوصل إلى حل عملي ووضع دين تقني في المتأخرات ، والتي يمكن التعامل معها بعد قليل ، عندما يتم حل المشاكل.
المناهج الأساسية وقواعد التحلل
هناك طريقتان رئيسيتان لتحلل المهام - أفقي ورأسي. مع الوضع الأفقي ، يتم تقسيم المهام حسب نوع العمل أو المستوى أو المكون. على سبيل المثال ، لدينا كل مهمة تمر بعدة مراحل: الواجهة الأمامية ، النهاية الخلفية ، قواعد البيانات. وبنهج أفقي ، تذهب مهمة واحدة إلى الخلف ، والثانية إلى الأمام ، والثالثة تؤدي إلى تغييرات في قاعدة البيانات.
لماذا هذا النهج سيء؟ لا نحصل على وظائف العمل بعد الانتهاء من كل مهمة على حدة. فقط من خلال جمع النتائج من ثلاثة مصادر ، يمكننا الحصول على نوع من النتائج والتعليقات عليها. لهذا السبب ، غالبًا ما لا يتم استخدام التحلل الأفقي.
أكثر ملاءمة هو النهج الرأسي ، حيث يمكن عمل وظيفة بصرية في كل مهمة - تمر المهمة بجميع المراحل وتحتوي المخرجات على نتيجة يمكن تحليلها واختبارها وعرضها على العميل وتصحيحها ، إذا لزم الأمر. وبدء التشغيل والاستخدام بسرعة.
إذا تحدثنا عن القواعد ، فقد حددت هنا ثلاثة فقط. أولاً ، يجب أن تكون المهمة كاملة منطقيًا ، أي مستقلة بحد ذاتها. لا ينبغي أن يكسر المنطق حول نفسه ويجب بالضرورة أن يحمل على الأقل بعض الشعور التجاري الذي سيحصل عليه المستخدم نتيجة لذلك. في الوقت نفسه ، يجب ألا تقسم تلك المهام التي لا تحمل معنى تجاريًا إلى أجزاء (من الناحية المثالية ، يجب ألا تكون موجودة على الإطلاق).
ثانيًا ، يجب أن تؤدي نتيجة إكمال مهمة صغيرة واحدة إلى تغييرات صغيرة. كلما كانت التغييرات أصغر ، زادت سرعة دخولها إلى الكود العام ، وبالتالي لا يصبح الرمز قديمًا. بالإضافة إلى ذلك ، تساعد المهام الصغيرة على تجنب التعارض بين المطورين عند الدمج.
ثالثًا ، لا يجب تقسيم المهمة إلى أجزاء مجهرية جدًا. إذا تم تقسيمه بشكل صغير جدًا ، فسوف يستغرق الأمر وقتًا طويلاً لإدارة هذه المهام. في كل مرحلة ، قد تضطر إلى إعادة ترتيب أولوياتهم ، وإعادة إنشاء روابط التبعية ، وهذا كل شيء. وبالتالي ، فإن سرعة التطوير لن تزداد ، بل على العكس ، ستنخفض بشكل حاد. لذلك ، تحتاج إلى البحث عن حل وسط.
طرق التحلل
اعتمادًا على المصدر ، يختلف عدد طرق التحلل اختلافًا كبيرًا: في مكان ما يشار إليها ثمانية فقط ، في مكان ما عشرة ، في مكان ما عشرين. أود التركيز على الطرق التي يجب أن أستخدمها كل يوم في العمل.
احتياجات متعددة
هذه الطريقة هي الأكثر ملاءمة للاستخدام عندما يكون هناك حروف العطف "و" ، أو "في القصة. على سبيل المثال ، يريد المستهلك تقديم طلب والدفع ببطاقة أو مكافآت. يمكن تقسيم هذه المهمة إلى ثلاثة: الأولى ، حيث يقوم المستخدم بوضع أمر ، والثانية ، حيث يدفع ببطاقته ، والثالثة ، حيث يتم استخدام المكافآت.
سيناريوهات الاستخدام
طريقة أخرى شائعة وهي تقسيم المهام حسب حالة الاستخدام. في هذه الحالة ، تعتبر القصة الواحدة مسارًا رئيسيًا والعديد من المسارات البديلة. لنفترض أن المستخدم يريد شراء عنصر ، وسيكون هذا هو السيناريو الرئيسي. ولكن لا تزال هناك طرق بديلة - يمكنه على الفور وضع المنتج في السلة والدفع ، أو قد يرغب في مقارنة هذا المنتج بالآخرين قبل الشراء. ثم نجعل مقارنة المنتج مهمة منفصلة.
ربما لا يرغب في الشراء الآن ، لكنه يؤجله في مكان ما ، ويضيف إلى المفضلة ، حتى يتمكن من العودة إليها لاحقًا. او اعجب المستخدم بالمنتج وهو مستعد لشرائه ولكنه نفذ من المخزون. لذا ، عليك إخباره بموعد ظهور البضائع. وبهذه الطريقة نحصل على أربعة سيناريوهات.
من البسيط إلى المعقد
تتكون الصفحة الرئيسية لموقع "Sportmaster" من لافتات. وأبسط شيء يمكننا القيام به هو التقاط صورة واحدة وعرضها على المستخدم. هذه هي الطريقة الأسهل والأسرع لنقل المعلومات الصحيحة. ثم يمكننا زيادة الوظائف وإضافة صورة واحدة فقط ، بل ثلاث أو أربع صور مدمجة في شبكة. هذه مهمة منفصلة.
مع هذا النهج ، مع كل مهمة لاحقة ، يجب أن تنمو الوظيفة. على سبيل المثال ، يمكننا إنشاء دائرة من الشبكة ، ثم إضافة بعض الروابط والنصوص والأزرار والباقي. بشكل عام ، ننفذ أولاً أبسط وأسرع إصدار ، ثم ننتقل إلى إصدار أكثر تعقيدًا.
في الآونة الأخيرة فقط كنت منخرطًا في مهمة مماثلة لتنفيذ لافتة. كان من المفترض أن يتم تعليق اللافتة على اللافتة الرئيسية ويتم التحكم فيها من خلال نظام إدارة المحتوى. إذا سألت العميل عما يود إدارته بالضبط ، فسوف يسعد بالإجابة دون أن يرمش - الجميع. لذلك ، كان من المهم هنا الغوص في الموضوع قليلاً وإبراز ما يجب إدارته في الوقت الحالي ، وما هو موجود في كثير من الأحيان ، وما لم يتم استخدامه على الإطلاق تقريبًا. وبالتالي ، ترتيب أولويات التنفيذ وتقسيم المهام إلى مهام.
العمليات (CRUD)
ربما تكون هذه هي الطريقة الأكثر شيوعًا للتحلل. هنا ، يتم تقسيم المهام إلى عمليات إنشاء وقراءة وتحديث وحذف. إنه مناسب للمهام التي تحتاج فيها إلى إدارة شيء ما أو تكوين شيء ما. على سبيل المثال ، تنقسم مهمة تقديم الطلب إلى أربعة مهام أصغر: إنشاء طلب وعرضه وتحريره وحذفه.
خيارات الواجهة
تُستخدم عند الحاجة إلى دعم خيارات واجهة متعددة. على سبيل المثال ، يجب أن يدعم الموقع لغات متعددة. أولاً ، نصنع النسخة الروسية. ثم ، عند الإطلاق في بلدان أخرى ، نضيف اللغة الإنجليزية. إذا كانت الدولة تستخدم لغة أخرى غير الإنجليزية ، فيمكننا إضافة ذلك أيضًا. في هذه الحالة ، من الأسهل القيام بكل شيء أولاً بلغة واحدة ، ثم إضافة الترجمات تدريجياً.
في الآونة الأخيرة ، أكملنا مشروعًا لحساب شخصي للكيانات القانونية ، والتي كانت بحاجة إلى دعم متعدد اللغات. كانت المواعيد النهائية ضيقة ، لذلك قاموا في البداية بكل شيء بلغة واحدة ، لكنهم وضعوا الأساس لمزيد من الترجمة. الآن ، تتطلب إضافة دعم للغة جديدة مهمة صغيرة واحدة فقط. إذا كنت بحاجة إلى إضافة عدة لغات في وقت واحد ، فسيتم إنشاء مهمة منفصلة لكل منها.
الفصل حسب الدور
مناسب للمواقف التي تتطلب فيها الوظيفة تشغيل العديد من الأدوار ومجموعات المستخدمين. في موقع Sportmaster ، يمكن أن يكون للمستخدم أدوار مختلفة. على سبيل المثال ، يتم تقسيم المستخدمين حسب الأدوار إلى مستخدم مصرح له ، ومستخدم مجهول ، ومستخدم مركز اتصال على سبيل المثال. يمكن أيضًا تقسيم الدور الأخير إلى قسمين - يمكن أن يكون إما مستخدمًا عاديًا أو مسؤولاً.
لكل دور ، يمكننا القيام بمهمة منفصلة. ابدأ بالعرض لمستخدم مجهول ، ثم أضف بعض الوظائف المتقدمة كجزء من مهمة لمستخدم مخول. ولا تنس الأدوار الفنية لمشغلي مركز الاتصال والوظائف الخاصة بهم.
معالجة الخطأ
إذا كانت المواعيد النهائية ضيقة ، وكانت هناك حاجة إلى الحد الأدنى من الوظائف في أسرع وقت ممكن ، يمكنك أخذ معالجة الأخطاء في مهمة منفصلة. نحن هنا لا نتحدث عن كتابة الاختبارات ، بل عن معالجة أخطاء المستخدمين والأنظمة التي يتكامل معها الموقع. تخيل أننا نعالج صفحة كتالوج تحتوي على لوحة منتج. تحتوي كل بطاقة على وصف وصورة ومعلومات إضافية.
لقد حدث أن بعض المعلومات لا تأتي من قواعد البيانات.
ربما ، إذا كنا نتحدث عن علامة تجارية أو مادة ، فيمكن إهمال ذلك وعدم عرض المعلومات ببساطة. ولكن إذا لم يظهر السعر أو الاسم ، فهل يستحق إظهار هذه البطاقة؟
ماذا تفعل في مثل هذه الحالة؟ يمكن إخراج هذا السؤال في مهمة منفصلة ثم معالجة كل حقل منفصل. أي ، إذا لم يأت السعر ، فإننا نقوم بإجراء واحد ، يتم فقد وصف المنتج - آخر. إنه نفس الشيء مع أخطاء المستخدم. إذا أدخل شيئًا بشكل غير صحيح وتم عرض خطأ ، على سبيل المثال ، "لم يتم العثور على الصفحة" أو الخطأ 500 ، يجب أن نظهر له معلومات محددة حول ما حدث ونقدم له سيناريو ما يمكنه فعله بعد ذلك.
هذه الطريقة مناسبة أيضًا للمواقف التي تحتاج فيها إلى الحصول بسرعة على تعليقات على الوظائف من أجل تحديد ما إذا كنت تريد الاحتفاظ بها أم لا.
ثابت ثم ديناميكي
هذه واحدة من طرقي المفضلة. مناسبة في الحالات التي يكون فيها من الممكن تنفيذ وظائف "على بذرة" ، أي أن الأنظمة الخارجية ليست جاهزة لدعم الوظيفة. على سبيل المثال ، لا يمكن التحكم في بعض الكتل الموجودة على الصفحة الرئيسية من خلال نظام إدارة المحتوى. أو قائمة ، عندما ننشئها في الكود الخاص بنا ونعرضها على المستخدم ، ولكن في نفس الوقت لا يمكن أن تتحكم الشركة فيها. ومن أجل إجراء تغييرات ، يجب أن يتجه العمل باستمرار إلى التطوير ويطلب القيام بذلك.
هنا ، نعطي الأولوية لاحتياجات المستخدم والأرباح. يحصل المستخدم على الوظيفة الجاهزة على الفور ، على الرغم من أننا قد نواجه بعض الإزعاج في الداخل. لذلك ، نقسم المهمة إلى عدة ، ونجعل الكتلة الجديدة متاحة للمستخدم أولاً ، لكن الشركة لا تستطيع إدارتها بشكل مباشر بعد. ولكن بعد ذلك يمكننا التكامل مع بعض الأنظمة أو قواعد البيانات ، حيث ستكون الشركة نفسها قادرة على مبادلة العناصر وإضافة عناصر جديدة بمفردها ، وسنقوم برسمها دون مشاركة في التطوير.
غالبًا ما نستخدم هذه الطريقة: أولاً ، نقوم بإنشاء وظائف على بياناتنا الخاصة ، والتي لا يمكن التحكم فيها من الخارج ، ثم نضيف ديناميكيات ونبدأ في تلقي البيانات من أنظمة الجهات الخارجية.
أداء
إذا كانت المهمة ككل معقدة وضخمة ، فليس من الواضح من أي طرف يجب معالجتها ، عندئذ يمكن إهمال الأداء. تتمثل المهمة الأولى في إبراز الوظيفة الجاهزة ، والتي نجحت بطريقة ما ، وإن كانت بطيئة. والمهمة التالية هي تسريع العمل. على سبيل المثال ، يمكن أن يكون البحث عن البضائع بطيئًا ، وتطبيق المرشحات ، والحصول على أي
معلومات.في بعض الأحيان يتم استثمار معظم الجهد في إنشاء وظيفة بسرعة - التنفيذ الأولي ليس بهذه الصعوبة. ولكن يمكنك أن تتعلم الكثير من التنفيذ البطيء ، بالإضافة إلى أن لها بعض القيمة للمستخدم الذي لولا ذلك لن يكون قادرًا على أداء بعض الإجراءات المهمة. في جميع هذه الحالات ، يتم تقسيم المهام إلى "اجعلها تعمل" و "اجعلها سريعة".
الصعوبات المحتملة
إذا قررت استخدام تحليل المهام في مشاريعك ، فمن المرجح أن تكون الصعوبة الأولى التي ستواجهها هي اعتماد المهام على بعضها البعض. في تجربتي ، هذه هي مشكلة حظر الخيط الأكثر شيوعًا. لتجنب ذلك ، يجب التعامل مع التحلل بمسؤولية وإعطاء الوقت الكافي.
هناك صعوبة أخرى وهي تحديد مدى الدقة التي تحتاجها لتحليل المهمة. وهنا فقط الحس السليم يعمل كحدود. على سبيل المثال ، نأخذ مكون اختيار المدينة. يحتوي على أزرار ، بعض النص ، حقل إدخال. ما مدى صغر هذه المهمة؟
لقد استنتجنا قاعدة لأنفسنا بأن المهمة يجب أن تتم على طول التدفق بالكامل في مدة لا تزيد عن أسبوع واحد (حوالي 40 ساعة). نحن نتحدث عن جميع المراحل: مرحلة التحليلات ، التطوير ، الاختبار. بالإضافة إلى ذلك ، يتم أخذ مرحلتين من تطوير الواجهة الخلفية والواجهة الأمامية في الاعتبار ، بما في ذلك المراجعة والاختبار في كل منهما.
كانت لدينا أيضًا مشكلة في حقيقة أن حدود الملحمة ليست واضحة دائمًا. لقد تم تكليفنا مؤخرًا بمهمة تقديم طلب. أين حدودها؟ ماذا يجب أن يكون الناتج؟ لم يكن واضحًا لنا ما إذا كنا بحاجة إلى القيام بكل الوظائف حتى النهاية ، أو اختيار جزء ما. هل تتضمن هذه الملحمة الدفع أم أنها ملحمة منفصلة بالفعل.
هناك مهام يصعب فهمها وكيفية التحلل ومتى. نحن نحلل معظم المهام في مرحلة تلقي الملحمة ، ولكن هناك مواقف يلزم فيها ذلك ، على سبيل المثال ، في مرحلة التحليلات. نحن نأخذ المهمة للعمل ونعتقد أن جميع البيانات الضرورية موجودة بالفعل في أنظمة التكامل لدينا ، ولكن أثناء التحليل تبين أننا إما غير راضين عن تنسيق البيانات ، أو أن المشكلة تكمن في جودة البيانات نفسها ، أو التحسين مطلوب من الأنظمة الأخرى التي ونحن على اتصال. ثم يتعين علينا القيام بالمهمة "on stubs" وإضافة عنصر آخر إلى backlog ، والذي سنبدأ بعد أن نحل المشاكل الرئيسية.
هذا ، على ما يبدو ، كل شيء. سيكون رائعًا إذا قمت بمشاركة القصص في التعليقات حول أي نهج لتحليل المهام تستخدمه ولماذا.
شكرا للقراءة!