إدارة تقنية
استخدم منهجيات متسلسلة
تم تطوير مشروع تكنولوجيا المعلومات بشكل مشترك من قبل فريقين: إدارة المشروع وإدارة المشروع.
- صاحب المشروع (MOA) هو العميل أو ممثل المستخدم. إذا قمنا بالتوازي مع منزل ، فسيكون الشخص هو الذي يأمر. "أريد منزلًا أصفرًا بسقفه أحمر وجذام يهز رأسه بسعادة."
- ستكون إدارة المشروع (MOE) هي الفريق المسؤول عن تحقيق رؤية صاحب المشروع. في مواجهة الطلب السابق ، ستجيب بالتأكيد "سنستخدم الطوب والبلاط الخرساني. الطلاء سيكون خالي من الأمونيا. أما بالنسبة للبيكسي ... إنه ليس مجالنا حقًا ، آسف ".
يحدث أحيانًا أن يكون العميل غير مدرب على إدارة المشروع وأنه يستدعي مزودي الخدمة الذين تكون وظيفتهم. نحن نتحدث عن المساعدة في إدارة المشاريع (AMOA).
حسن. نحن نعرف بشكل أفضل قليلاً من يشارك في المشروع. دعونا الآن نرى المراحل المختلفة والوثائق المنتجة.
الخطوة الأولى: تعريف المشروع
السلطة المتعاقدة تكتب المواصفات الوظيفية. هذه وثيقة (طويلة) توضح بالتفصيل كل سلوك التطبيق نقطة تلو الأخرى. يمكننا رؤيته على أنه الكتاب المقدس للمشروع: المطورين ومديري المشاريع والكتاب ، باختصار ، سيستخدمه الجميع عند الشك. يحتاج إلى ضبطه!
في حالة Pur Beurre ، ستفصل المواصفات الوظيفية ، على سبيل المثال ، كيف يبحث المستخدم عن طعام. "يصل المستخدم إلى الصفحة الرئيسية. يكتب Nutella بالشكل الذي يظهر ويضغط على Enter. تظهر صفحة جديدة بنتيجة بحثه ".
الخطوة الثانية: التصميم المعماري
بمجرد كتابة المواصفات الوظيفية ، يقوم المقاول الرئيسي بكتابة المواصفات الفنية وتصميم الهيكل العام للتطبيق.
على عكس المواصفات الوظيفية التي تركز على استخدام التطبيق ، تهدف المواصفات الفنية إلى تحديد الإطار الفني للمشروع. إلى حد ما ، ستكون قاعدة عمل قوية للمطورين.
في حالة Pur Beurre ، ستحتوي المواصفات الفنية ، على سبيل المثال ، على قسم خاص بالبحث. "سيتم إجراء البحث من خلال Open Food Facts API الذي يعرض الردود بتنسيق JSON. وثائق API متاحة هنا ".
في نفس الوقت ، يقوم المدير الفني للمشروع بتصميم البنية باستخدام مخططات UML. يتم التحقق من صحة من قبل العميل ومدير المشروع الوظيفي.
الخطوة 3: اكتب الكود
حان دور المطورين لدخول المشهد! يستخدمون المواصفات والمخطط لإنتاج الكود المطلوب.
الخطوة 4: وصفة
تهدف المرحلة الأخيرة إلى التحقق من أن التطبيق يعمل كما ينبغي. يمكن إجراء الاختبار اليدوي ، ولكن كقاعدة عامة نفضل استخدام صلاحيات تكنولوجيا المعلومات لأتمتة هذه الفحوصات قدر الإمكان. نحن نستخدم اختبارات الوحدة على وجه الخصوص.
الغرض من كل اختبار وحدة هو التحقق من أن جزءًا من التطبيق ينتج بالفعل النتيجة المتوقعة عند حدوث حدث معين. يمكننا التحقق ، على سبيل المثال ، من عدم إرسال النموذج إذا لم يقم المستخدم بإدخال اسمه الأول. توفر الاختبارات الآلية الكثير من الوقت!
ثم يقوم العميل بإجراء اختبارات القبول ، أي أنه سيختبر يدويًا أن التطبيق يتوافق مع ما تم طلبه.
تسمح منهجية المشروع المتسلسلة بتنفيذ هذه المراحل واحدة تلو الأخرى بترتيب زمني. الهدف من كل مرحلة هو قبل كل شيء تسليم وثيقة ، أكثر من الوظائف. يتم اختبار البرنامج فقط في النهاية ويبدأ العميل في رؤية نتائج الأعمال التحضيرية في بعض الأحيان بعد عدة أشهر من بدء المشروع.
يعني اتباع هذا النهج التسلسلي للحرف وجود:
- 100٪ من المواصفات الوظيفية قبل البدء في التصميم ،
- 100٪ من المواصفات الفنية قبل بدء الكود ،
- 100٪ من الكود قبل بدء الاختبارات.
ليس من السهل ، في هذه الحالة ، تعديل العناصر على طول الطريق! إنه نموذج مثالي ولكنه غير واقعي. في الواقع ، غالبًا ما نعود إلى المراحل السابقة ، خاصة أثناء مرحلة الاختبار التي تتضمن إعادة كتابة التعليمات البرمجية لتصحيح الأخطاء ، وبالتالي إعادة صياغة التصميم وبالتالي تعديل المواصفات الوظيفية.
بالإضافة إلى ذلك ، من الصعب إجراء الفحوصات في جميع مراحل المشروع لأنها تتعلق بعدد كبير من المستندات التي يمكن أن تصبح مملة بسرعة. قد يفتقر المطورون إلى الحافز ، ويبدأ الاكتئاب. باختصار ، كل شيء سيء سيدتي الطيبة.
ماذا تفعل ولكن ماذا تفعل؟ هل محكوم علينا بهذا النهج؟
لا ، بالطبع ، لكنك تعرف ذلك بالفعل! ظهرت منهجيات المشروع الرشيقة لحل هذه المشاكل.
قم بتطبيق Scrum ، المنهجية الأكثر شيوعًا
Scrum منهجية المشروع هذه تأتي من لعبة الركبي! تستخدم الطريقة قيم وروح الرجبي لتكييفها مع تطوير البرمجيات. إحساس الفريق ، الاتصال ، العمل الجيد! مثل المجموعة أثناء الكرة المحمولة ، يتحد الفريق للوصول إلى الهدف. من ناحية أخرى ، يشبه ScrumMaster نصف سكرم الذي يقسم أعضاء الفريق ويعيد تنظيمهم لضمان نجاح المشروع.
فكيف يعمل؟ دعونا نرى ذلك بالتفصيل!
في بداية المشروع ، يتم تقسيم المشروع إلى وظائف مدرجة في قائمة الأعمال المتأخرة ، وهي نوع من الجدول الكبير.
ثم سنركز على الإصدار الأول الذي سيتم طرحه على الإنترنت. سيكون الحد الأدنى عن قصد ، مع التركيز على الوظائف الأساسية التي تم الإشارة إليها كأولوية في التراكم. يُطلق على كل إصدار اسم إصدار ويتكون من عدة سباقات سريعة.
يستمر العدو ما بين أسبوع وأسبوعين ويستخدم لتطوير ميزة واحدة أو أكثر. يقررها الفريق ومالك المنتج (والذي سنتحدث عنه لاحقًا). يتم تقسيم كل سباق سريع إلى قصص ، لكننا سنرى كل هذا بالتفصيل لاحقًا. في الوقت الحالي ، ضع في اعتبارك أن مطور كل قصة سينتج نفس المخرجات التي رأيناها في المنهجيات المتسلسلة ولكن على نطاق القصة وليس المشروع بأكمله.
لذلك سيتعين عليه / عليها:
- إنشاء المواصفات الوظيفية ،
- تصميم بنية القصة ،
- كود واختبار.
أثناء الركض ، يتم تحديد النقاط أثناء استخدام الصفن اليومي. هذا يسمح لـ ScrumMaster ، الميسر المسؤول عن فرض Scrum ، بتحديد التقدم مقابل التزامات الآخر وربما إجراء التعديلات.
في نهاية كل سباق ، يضيف الفريق لبنة جديدة إلى المشروع الذي يصبح أكثر وأكثر اكتمالًا ، من العدو إلى العدو السريع. يتيح تقييمه والتعليقات التي تم جمعها إمكانية ضبط الأعمال المتراكمة للعدو التالي. هذا يسمى التفتيش.
ثم ينتقل الفريق إلى سباق جديد ، مكون من قصص ، وما إلى ذلك!
الأدوار
تختلف مسؤوليات ومهام أصحاب المصلحة في مشروع رشيق اختلافًا كبيرًا مقارنة بالمشروع المتسلسل لأن التركيز ينصب على ملكية المشروع من قبل كل عضو في الفريق وعلى التعاون.
مالك المنتج
يمثل المستخدمين النهائيين (أو العملاء) للمشروع. إنه مسؤول عن تحديد محتوى المنتج وإدارة الأولويات. هذا هو السبب في أنه يغذي بانتظام الميزات الجديدة المتراكمة ويعطي الأولوية للميزات القديمة. يحدد مالك المنتج الهدف من الإصدار ويتخذ قرارات بشأن محتواه.
من الناحية المثالية ، يكون متاحًا بدوام كامل لتحديث الأعمال المتراكمة ، والإجابة على الأسئلة المتعلقة بالمنتج ، وإعداد اختبارات القبول (التي سنتحدث عنها لاحقًا) ، وإجراء الاختبارات.
سكرم ماستر
لا يوجد مدير مشروع في سكرم! يأخذ كل عضو ملكية المشروع ويقوم الفريق بالتنظيم الذاتي وفقًا لذلك. يساعد Scrum Master الفريق على تطبيق مبادئ Scrum ، من خلال إرشادهم لكتابة قصص المستخدم على سبيل المثال. كما أنه يتأكد من إزالة أي عقبات قد تعيق المشروع. كثيراً ما يقال أن ScrumMaster "يحمي" الفريق لأن أي طلب من الخارج يجب أن يمر أولاً بعملية Scrum.
الفريق
هذا هو الدور القيادي! هي التي تصنع المنتج. لذلك يجب أن تمتلك جميع المهارات اللازمة لتنميتها بالشكل الصحيح. يتم اختيار الأعضاء من قبل Scrum Master وفقًا لدوافعهم ومهاراتهم. إن الفريق هو الذي يحدد بنفسه الطريقة التي ينظم بها عمله ، وليس مدير سكرم أو مالك المنتج. كل عضو في الفريق يجلب خبراته. لذلك فإن مسؤوليات الفريق ضرورية!
ابدأ مشروعًا: Sprint 0
الفترة التي تسبق أول سباق سريع تسمى "Sprint 0". إنه مخصص لتنظيم المشروع: التعرف على المنتج وتوقعات المستخدم ، وتجنيد الفريق وإنشاء الأعمال المتراكمة.
رؤية
لقد رأينا أن المسؤولية الرئيسية لمالك المنتج هي التأكد من أن المنتج المطور يلبي احتياجات المستخدم. يجب أن يكون لديه رؤية قوية جدًا للمنتج الذي يريده ليكون قادرًا على تحويله.
تجيب هذه الرؤية على السؤال البسيط للغاية (والذي غالبًا ما يكون معقدًا) وهو "لماذا؟" لماذا سيستخدم مستخدمنا التطبيق الذي نقوم بتطويره؟ يجب أن تكون الإجابة واضحة تمامًا.
المستخدمون
يجب أن يعرف مالك المنتج تمامًا المستخدمين الذين يمثلهم. يعتبر وضع احتياجاتهم في الاعتبار هو الخطوة الأولى ، ولكن معرفة استخداماتهم الحالية أفضل.
للقيام بذلك ، يقوم "مالك المنتج" بإنشاء شخصية واحدة أو أكثر ومشاركتها مع باقي الفريق.
هذا مركب من مستخدم منتجنا. نعطيها الاسم الأول ، والعمر ، ونبني لها قصة ونعطيها عادات تعكس ما نعرفه بالفعل عن مستخدمنا.
الهدف هو جعل تطوير كل ميزة ملموسة بشكل أكبر. من الأسهل التفكير في ليزا بدلاً من التفكير في المستخدم Y!
يمكنك معرفة المزيد في فصل "اكتشف جمهورك" من الدورة التدريبية "ابدأ حملة إعلانات Facebook".
تراكم Backlog
ثم يقوم "مالك المنتج" بملء الأعمال المتراكمة.
Backlog عبارة عن جدول كبير يسرد الميزات المخطط لها للمنتج وحالتها (التطوير المعلق ، المخطط ، قيد التقدم ، الانتهاء ، إلخ). يتم ترتيب الأولوية لكل منها من أعلى إلى أسفل ، مع كون الميزة الأولى هي الميزة التالية التي سيتم تطويرها. تحقق من مثال تراكم تم إنشاؤه بواسطة Brian Cervino.
عادة ما يحتوي جدول backlog على الأعمدة التالية:
- تراكم المنتج: الميزات التي حددها مالك المنتج حسب الأولوية والتي تنتظر التطوير.
- التطوير: قصص المستخدم قيد التطوير
- قصص المستخدمين التي دخلت حيز الإنتاج.
في هذه المرحلة ، لا يتم ملء سوى عمود Product Backlog. هذا أمر طبيعي لأننا لم نبدأ أول سباق سريع بعد! سيقوم الفريق بتحليل الميزة الأولى ، وتقسيمها إلى قصص المستخدمين وتحديد نطاق السباق الأول. نرى كل هذا في الفصل التالي!
إرسال تعليق