المقدمة النهائية لإدارة المشاريع الرشيقة

الموجز

أنت مسؤول عن تقديم أحدث وأكبر مبادرة لشركتك والتي ستغير وجه "Widgets International" إلى الأبد. إنه مشروع برمجي يجذب عملاءك ويجذبهم ، ويجعل حياة زملائك أسهل ، ويجعل أرباح الشركة ملايين. هناك قدر كبير من الترقب والحماسة والإثارة والتوقعات. تحتاج إلى القيام بذلك في أسرع وقت ممكن حتى يتمكن عملك من البدء في جني الفوائد. يعتمد النجاح المستقبلي للشركة عليك. كل العيون عليك. لا يمكنك أن تفشل.

في البداية ، أنت تفكر في نفسك ، "رائع ، أنا على مستوى التحدي. دعونا ننجز هذا الشيء! " تتوقف للحظة ، وتراجع ، وتفكر في نفسك "حسنًا ، فكيف نفعل هذا؟" تبدأ في التحدث إلى زملائك وزملائك. تقضي وقتًا في البحث عن أفضل ممارسات تطوير البرمجيات وتقنيات إدارة المشاريع ، لكن الخيارات والأساليب لا تعد ولا تحصى. هناك الكثير من الاختصارات والمنهجيات. أبرزها يرتفع إلى القمة. الشك يتسلل إلى الداخل. أي واحد يجب أن نستخدمه؟ كيف أضمن النجاح؟ ماذا لو اتخذت قرارات خاطئة؟

عندما يتعلق الأمر بإدارة مشاريع البرمجيات ، هناك مزيج قوي من الخيارات التي تدعمها آراء لا تعد ولا تحصى. تهمس أصوات من أركان الغرفة ، "حاول أن تفعل ذلك بهذه الطريقة" ؛ يصرخ الآخرون ، "هذه هي الطريقة الوحيدة للقيام بذلك" ؛ والباقي يتذمرون ، "لا تدير الأمر على الإطلاق ، فقط استمر في ذلك." في الواقع ، كل هذه الأصوات تتحدث عن بعض الحقيقة. ولكن المهم هو تحديد ما هو مناسب لاحتياجاتك وفريقك وعملك وعملائك.

وضع المشهد

كان هناك وقت كانت فيه إدارة مشروع البرمجيات تجلس بشكل مباشر في واحد من ثلاثة معسكرات. كانت هناك أطر عمل ثقيلة تتيح لك اتخاذ قرارات بشأن كيفية التنفيذ والتسليم مع تقديم هيكل للحفاظ على السيطرة والحوكمة. كانت هناك منهجيات متسلسلة وصفية مثل الشلال التي أجبرتك على التخطيط لمشاريع طويلة ، وفهم جميع متطلباتك والالتزام بها ، وتصميم أنظمة معقدة وتوقيعها ، وكتابة الكثير من التعليمات البرمجية ، ثم اختبارها (كل ذلك قبل أن يتمكن العميل من رؤيتها لأول مرة زمن). وأخيرًا ، دورات حياة تطوير البرامج (SDLC) الأقل إلزامية ولكن التكرارية التي تشجع النماذج الأولية السريعة أو الأنظمة الأكبر على التصميم والبناء والتسليم بخطوات تدريجية ، كل مبنى فوق الآخر.

نشأ تطوير البرمجيات الرشيقة وإدارة المشاريع الرشيقة من أوجه القصور في الشلال وفوائد الأساليب التكرارية لتسليم البرامج. يمكنهم تتبع جذورهم إلى الخمسينيات من القرن الماضي ، وقيادة الفكر في السبعينيات ، والنضج في التسعينيات ، والتبني خلال القرن الحادي والعشرين. في عام 2001 ، قامت مجموعة من الممارسين والخبراء بإنشاء بيان Agile ، الذي يهدف إلى تحديد 4 قيم و 12 مبدأ إرشاديًا تسعى إلى تجسيد روح تطوير البرمجيات الرشيقة وتشجيع تطورها. وقد تطورت بالتأكيد.

الآن ، مجرد استدعاء شيء ما Agile ليس مفيدًا بشكل خاص. الكلمة ، حتى في سياق البرنامج ، تعني أشياء مختلفة لأشخاص أو مؤسسات مختلفة. هناك العديد من الأوجه والتعريفات والتطبيقات والتفسيرات. يميل كل جسم يتبنى Agile إلى محاولة منحه تعريفه الخاص.

يكفي أن نقول إن تطوير البرمجيات الرشيقة وإدارة المشاريع عبارة عن مجموعة من السلوكيات والأطر والتقنيات والمفاهيم ذات الصلة التي تفضل بشكل أساسي تقديم برنامج العمل الصحيح في أقرب وقت ممكن وبقدر الإمكان بشكل واقعي.

لقد ذكرت سابقًا أن Agile ، كما هو مطبق على تطوير البرامج أو إدارة المشاريع ، يمكن أن يكون أشياء مختلفة. باختصار ، يهتم تطوير البرمجيات Agile بتطوير برامج رائعة في الأعمال التجارية كالمعتاد (BAU) أو سياق المشروع. من ناحية أخرى ، تهتم إدارة المشاريع الرشيقة بالحوكمة والرقابة اللازمتين لتقديم المشاريع المعقدة بما في ذلك على سبيل المثال لا الحصر البرمجيات.

هناك العديد من طرق تطوير البرامج Agile المتاحة ، مثل Scrum و Kanban و XP و Lean Software Development. ولكن مثلما تدور لعبة الرجبي حول أكثر من مجرد سكرم ، فإن Agile كذلك. بشكل منفصل ، لا تتناول هذه النماذج الرشيقة دورة الحياة الكاملة لإدارة المشروع المطلوبة في المشاريع المعقدة مثل الحوكمة ، وتوفير الموارد ، والإدارة المالية ، وإدارة المخاطر الواضحة ، والعديد من مفاهيم إدارة المشاريع المهمة الأخرى. بالنسبة إلى هؤلاء ، قد ترغب في التفكير في PMI Agile أو PRINCE2 Agile - فكر في الأمر على أنه "أجيليتي محكومة".

لماذا نحتاج إلى أن نكون رشيقين؟

منذ زمن بعيد ، جابنا الأرض لجمع الطعام والمأوى للبقاء على قيد الحياة. كانت احتياجات بسيطة ، لكنها سريعة الحركة. بعد مرور بعض الوقت ، نمت البلدان والاقتصادات وازدهرت على خلفية الثورة الصناعية. كانت هذه ولادة الإدارة والتحكم وفقدان خفة الحركة. نحن الآن في عصر المعلومات أو الثورة ، حيث توظف الشركات عمال المعرفة. العاملون المعرفيون هم أنت وشركائك وزملائك وأقرانك ، الذين يسعون لخلق حلول رائعة لمشاكل العملاء والأعمال والمشاكل الاجتماعية والاقتصادية والعالمية. يطبق العاملون في مجال المعرفة التحليل ، والمعرفة ، والاستدلال ، والفهم ، والخبرة ، والمهارات في كثير من الأحيان للاحتياجات غير المحددة والمتغيرة. تحتاج هذه الشركات والعمال إلى أساليب وتقنيات لا يمكن أن تلبيها عمليات وإجراءات العصر الصناعي القديم. Agile يدعم التفاعلات.

عمليًا لا يمكن لأي مشروع برمجي أن يبدأ بثقة في البداية وأن يعرف كل ما يحتاجه من أجل تقديم برامج عمل قيّمة دون تغيير. يقدم التغيير كلاً من الفرص والمخاطر لنجاح المشروع. يمكن أن تعني الفرص غير المُدارة الفرق بين شركة رائعة وشركة رائعة. المخاطر غير المُدارة تنبئ بكارثة وخراب. Agile يدير التغيير.

يتيح لك اعتماد Agile أن تكون مستجيبًا للمتطلبات المتغيرة أو الجديدة. إنه يمكّن فرق التطوير ليكونوا خبراء واتخاذ قرارات مدعومة من قبل شركة نشطة وموثوقة ومستنيرة. إنه يمكّنك من تقديم ما يريده العملاء حقًا. في النهاية ، يضعك أنت ومؤسستك في السيطرة على تقديم برامج قيّمة وعالية الجودة تلبي احتياجات العملاء وتوقعاتهم مع استخلاص عائد على استثماراتك في أقرب وقت ممكن. رشيق يخلق قيمة.

هناك تكلفة لاعتماد Agile. لا يأتي مجانًا. يمكن أن يكون التحول إلى نهج رشيق لتسليم البرامج مسارًا صعبًا يجب اتباعه. ومع ذلك ، إذا استوعبت فلسفة أجايل ، وخطيت بعناية ، وقمت بإشراك الفريق المناسب مع الموقف الصحيح ، وقسمت الأمور ، وجعلها قابلة للتحقيق وواقعية ، واستجبت للتعليقات ، فسوف تجني ثمارًا. Agile يؤكد التعاون.

فيما يلي قائمة ببعض الفوائد التي يمكنك توقعها:

• سرعة الوصول إلى السوق
• توليد الإيرادات في وقت سابق
• التسليم المنتظم للقيمة الحقيقية
• حماية لاستثمارك
• البيانات والبيانات والبيانات
• جودة أفضل للمنتج
• توقعات يمكن التحكم فيها
• زيادة رضا العملاء
• فرق عالية الأداء
• تحسين الرؤية على التقدم
• القدرة على التنبؤ والشفافية والثقة
• مخاطر يمكن التحكم فيها

النجاح ليس نهائيا ، والفشل ليس قاتلا: إنها الشجاعة لمواصلة هذا الأمر المهم.

ربما لم يقل ونستون تشرشل هذا مطلقًا ، لكنني أعتقد أنه تلخيص جيد جدًا لـ Agile. نحن نعلم أن Agile هي أفضل خطوة إلى الأمام لمعظم المشاريع. إنه يشجعك على السعي لتحقيق النجاح ، لكننا دائمًا نكرره ونواصل البناء عليه. سيشجعك Agile على الفشل ، لكنك تفشل مبكرًا والمضي قدمًا. إن امتلاك الشجاعة للاستمرار وبناء الحل الصحيح بناءً على البصيرة المستنيرة من قبل عميلك هو ما يجلب لك المكافأة.

الشيء الذي يجب مراعاته هو أنه يمكنك تخصيص Agile وفقًا لاحتياجاتك. استخدم الطريقة والحوكمة المناسبة لعملك. أينما تبدأ ، كن صادقًا مع المحتوى والسياق وروح الطريقة التي تستخدمها - احتفظ بها الفانيليا. إذا كنت قد بدأت للتو ، فتعلم . إذا كنت تفعل ذلك لفترة من الوقت ، فتفهم . إذا أصبحت رائعًا ، تقدم بطلب . أخيرًا ، إذا كان عملك ومشاريعك معقدة ومترابطة ، فاحكم . بمرور الوقت ، ستكتشف أنت وفريقك ما هو الأفضل لعملك.

جدوى

لذا أنت الآن تفكر ، "حسنًا ، فهمت. كيف ابدأ؟ من أين أبدأ؟" حسنًا ، مع كل الأشياء الجيدة ، نبدأ من البداية. ومع Agile ، يسأل نفسك "ما هي القيمة التجارية التي أريد تقديمها؟" بعد كل شيء ، لهذا السبب نقوم بتنفيذ المشاريع ، لتوليد قيمة تجارية. من أجل تحديد ما إذا كان المشروع يستحق التعهد لاشتقاق قيمة العمل ، تحتاج إلى فهم ما إذا كان ذلك ممكنًا.

رؤية

هل من المتوقع أن يؤدي مشروعك إلى زيادة الإيرادات ، أو دخول سوق جديد ، أو اكتساب المزيد من العملاء ، أو تحسين إدراك العملاء ، أو تسهيل الحياة لمشكلة معينة قمت بتحديدها؟ مع وضع ذلك في الاعتبار ، يمكنك تحديد "رؤيتك".

• قد تأتي رؤيتك من مصادر مختلفة - شركتك الناشئة الجريئة لإصلاح مشكلة شائعة ، أو استراتيجية إدارة الأعمال ، أو مشروع حيوانك الأليف لمديرك التنفيذي ، أو فريق منتج معين ، أو حتى احتياجات عميلك.
• حاول التراجع عن حذائك الخاص و "انظر" كيف يبدو المستقبل بمنتجك أو خدمتك الجديدة في أيدي عملائك.
• قم بإشراك أصحاب المصلحة - الرئيس التنفيذي ورجل المنتج والعملاء. ورشة عمل ، لا تحاول ذلك بمعزل عن الآخرين. تحدي الافتراضات والتحقق من صحة الحجج.
• اكتبها ، اجعلها قصيرة. ركز على قيمة العمل.
• صقلها حتى تتفق جميعًا على أن الرؤية تلقى صدى لدى الجميع وتلتقي بتفسير مشترك ينص على المكان الذي تتجه إليه.
• نادرا ما تتغير رؤيتك ، إذا كانت صحيحة. كيف ستصل إلى هناك بالتأكيد.

الناس لا يشترون ما تفعله أو كيف تفعله. يشترون "لماذا" تفعل ذلك. هذا هو ما يخلق العلاقة العاطفية بين عملك وعملائك. سوف تساعد الرؤية في توضيح هذا.

هل هذا ممكن؟

تأتي الجدوى في ظلين على الأقل. عادةً ، سترغب في فهم ما إذا كانت رؤيتك لمستقبل أكثر إشراقًا لعملك وعملائك ممكنة من الناحية الفنية ، وأنه من الممكن لعملك تحقيق ذلك.

• إذا كانت رؤيتك هي السفر إلى أي مكان في جميع أنحاء العالم في أقل من ساعة ، فقد تواجه مشكلة في الجدوى الفنية. نظرًا لأن العلم والفيزياء والتكنولوجيا لم يلحقوا بهذا الحلم تمامًا حتى الآن ، فقد لا يكون الحل التقني الخاص بك قابلاً للتطبيق في أي شيء آخر غير النظرية. بالإضافة إلى ذلك ، إذا كان حلك جديدًا ، فإن هذا سيتجاوز فكرة الحد الأدنى من المنتج القابل للتطبيق (MVP).

• لاختبار الجدوى الفنية لمنتجك ، ضع في اعتبارك إما استكشافه بشكل أكبر في مشروع نموذج أولي للاكتشاف أو عن طريق إجراء زيادة مفاجئة في المراحل الأولى من المشروع. ستعرف الطريقة التي يجب استخدامها من خلال التفكير في نطاق أو مدى تعقيد الحل الذي تفكر فيه.

  "بعض من أفضل المعارف التي اكتسبتها فريقي في فهم الجدوى التقنية جاءت من إجراء زيادة مفاجئة. وغالبًا ما يكون الحل هو الحل الأبسط! "

• الظل الثاني للجدوى الذي يجب مراعاته هو ما إذا كنت أنت أو فريقك أو عملك لديك المهارات والحافز لإنجاحه. باستخدام مثال ، إذا كنت جيدًا في خبز الكعك في المنزل لعيد ميلاد أطفالك ، فهذا حلو. ولكن إذا كنت ترغب في تحويل هذا إلى عمل تجاري يبيع أفضل أنواع الكعك للعالم ، فأنت بحاجة إلى فهم ما إذا كان بإمكانك توسيع نطاقه والتعامل مع الأعمال التجارية بالإضافة إلى الإنتاج وإدارة التوزيع والوفاء والاهتمام بخدمة العملاء.
• قد يكون هذا النوع من الرؤية قابلاً للتحقيق على المدى الطويل. لكن في الوقت الحالي ، ربما لا. لذا قلل من حجمها ، وفكر على نطاق صغير ، وخذ جزءًا صغيرًا يبدو واقعيًا وركز على تقديم أفضل طموح أصغر يمكنك. إذا نجح ذلك في جذب عملائك وإسعادهم ، فاجعلهم يعودون للمزيد وإخبار أصدقائهم ، ثم قم بتوسيع نطاقه من هناك باستخدام ملاحظات العملاء كدليل لك وبوصلة.
• تحتاج أيضًا إلى معرفة ما إذا كان مشروعك ممكنًا من حيث الميزانية والإطار الزمني. هل يمكن لعملك تحمل تكاليف تنفيذ هذا المشروع؟ هل الإطار الزمني قابل للتحقيق؟ الوقت والمال هما اثنان من القيود الثلاثة في مشروع Agile التي تم إصلاحها. نحن نهدف إلى التسليم في غضون فترة زمنية محددة وضمن ميزانية ثابتة معينة.
• تشير جودة المنتج إلى المنتج النهائي الذي يستخدمه عملاؤك والممارسات الهندسية التي يستخدمها فريقك لتقديم برامج رائعة وقوية وموثوقة. الجودة هي أيضًا شيء لا نختصر تغييره. من ناحية أخرى ، يمكن أن تتغير معايير الجودة. إذا لم تكن بصدد بناء سيارة فيراري ، فقد لا يمتلك المنتج تصورًا عالي الجودة. إذا كنت لا تبني صواريخ فضائية ، فقد تكون التفاوتات التي تم تحقيقها في شروط الإنتاج أعلى من ذلك بكثير. حدد النغمة المناسبة والتوقعات في وقت مبكر.

إذاً الآن تأكدت أن حلمك هو أكثر من مجرد خيال شوكولاتة ، فقم باختبار افتراضاتك وإثبات للناس أن هذا المسعى يستحق الاستثمار فيه.

التبرير

الآن ، اعتمادًا على ظروفك ، سيأتي التبرير بأشكال مختلفة. لكن في الأساس ، تريد أن تثبت أن هذا المشروع سوف يلبي معايير نجاح العملاء ، ولديه فرصة للنجاح ، وسيقدم قيمة ، وبأسعار معقولة.

• حدد افتراضاتك بناءً على حاجة العميل ، ثم تحقق من صحتها. تقدم Lean Startup إرشادات رائعة حول تحديد وإثبات أن منتجك يحتاجه عملاؤك وسيخلق قيمة.

• اكتب ، واختبر ، وتحقق من صحة خطة عملك. الآن لا يبدو هذا مثل ما أخبرك البنك الذي تتعامل معه أو عملك وتمويلك الرئيسي بإنتاجه. لا تستخدمها - ستنتهي صلاحيتها قبل أن يجف الحبر. بدلاً من ذلك ، تحقق من نموذج العمل التجاري. هذه في الأساس خطة عمل قصيرة الشكل تحافظ على تركيزك على عرض القيمة الخاص بك وعملائك وإيراداتك وتكاليفك. استخدمه للتحقق مما إذا كان لديك عمل تجاري سيعمل.

  "لقد تجاهلت هذه النصيحة مرة واحدة وقضيت وقتًا طويلاً في كتابة خطة عمل تقليدية مطولة من 50 صفحة. لم تصلني إلى أي مكان. كل الافتراضات التي قدمتها لا أساس لها من الصحة ، ولا يمكن التحقق من صحة جميع التوقعات التي قدمتها. لقد كانت تجربة مؤلمة ومكلفة علمتني ألا أفعلها مرة أخرى ".

• إذا كنت تعمل في شركة ناضجة ولديك محافظ من المشاريع التي يتم تسليمها في بيئة معقدة ، فقد تكون النمذجة المالية ضرورية. إذا كان لا بد من ذلك ، فافعل ذلك فقط بعد أن تثبت ما ورد أعلاه.
• بمجرد قيامك ببناء MVP الخاص بك ، قد تكون هناك حالة لإنشاء خطة عمل أكثر تقليدية - على سبيل المثال ، إذا كان عليك الذهاب للتمويل أو الاختيار ضمن محفظة شركتك من المشاريع والموارد المتنافسة. ولكن ستكون هذه خطة عمل مبنية على الأدوات المستخدمة أعلاه ومعلومة بها. سيكون أخف أيضا.
• في أي حال ، استخدم هذه الأدوات كأدوات حية وتنفسية. استخدمها كدليل لك ورائدك. هم أبدا ثابتة. يمكنك الرجوع إليها ومراجعتها مع تطور مشروعك أو عملك.

بمجرد حصولك على المبرر الخاص بك وجميع أصحاب المصلحة لديك على متن الطائرة ، فسوف تشتعل.

يتم تنفيذ مرحلة الجدوى عادةً مرة واحدة في عمر مشروعك. قد تجد أنك تعيد النظر في رؤية وجدوى المشروع ، خاصةً إذا كانت بياناتك أو عملائك أو سوقك أو عملك تشير إلى ذلك. على أقل تقدير ، سيكونون أنوارك طوال الوقت.

المبادرة

مدهش. تم اتخاذ القرار ، حصل المشروع على الضوء الأخضر وأنت جاهز للبناء. حسنًا ، تقريبًا. أعلم أنك تفكر ، "هيا بالفعل ، حقًا؟ إذا لم نفعل هذا الآن فلن نفعل ذلك أبدًا. يتيح الحصول على هذا العرض على الطريق!" لكن ضع في اعتبارك أن - Agile ليس شيئًا إن لم يكن لتقديم قيمة في وقت مبكر وفي كثير من الأحيان أثناء إسعاد عملائك على طول الطريق. إن قضاء بعض الوقت في اكتشاف أفضل طريقة لتسليم مشروعك هو أفضل أساس للنجاح.

الفريق

في الرياضة ، من خلال التفكير في لعبة الفريق المفضلة لديك ، ستتمكن من التعرف على الأدوار الرئيسية التي تمكن الفريق من الأداء كما يفعل. تقليديا ، ستجد مديرًا وقائدًا وبقية الفريق. خارج ذلك ، ستجد المدربين ، وأخصائيي العلاج الطبيعي ، وخبراء التغذية ، ومجموعة متنوعة من الموظفين الداعمين. لكن إذا نظرنا إلى لعبة الرجبي ، فسنجد أن هناك فريقًا داخل الفريق: اللاعبون الذين يتألفون من لعبة الركبي. تتكون هذه الحزمة من لاعبين معينين تتمثل مهمتهم في استعادة الكرة ومواصلة اللعب. عندما يكون سكروم في اللعب ، يعمل اللاعبون من كل جانب ، بدون قائد ، كوحدة واحدة بشكل تعاوني ، تواصلي ، وفعال قدر الإمكان لاستعادة الكرة في الاستحواذ. إنها لعبة الرجبي التي ألهمت جيف ساذرلاند لتسمية منهجية تطوير برمجياته "سكرم".

• Scrum ليست الطريقة الوحيدة لتطوير البرمجيات في كتاب اللعب Agile. ولكنه أفضل وصف لمفهوم Agile وسلوكيات العمل كفريق واحد ، وتحفيز الأفراد ، وخلق علاقات ثقة ، والتنظيم الذاتي ، والقيادة بالخدمة ، والتواصل ، والشفافية ، والتعاون.
• سيتم تشكيل فريقك إلى حد كبير وفقًا للظروف التي تجد نفسك فيها. قد يكون لديك مطورون متاحون لك. قد يكون البعض ، أو لا أحد ، أو جميعهم على دراية بـ Agile بدرجات متفاوتة. قد ترغب في تعيين فريق جديد أو شراكة مع طرف ثالث.
• ستكون الأدوار الأخرى مطلوبة أيضًا ، لكننا سنناقشها لاحقًا.
• لقد قيل أنه إذا كنت من فريق التطوير الخاص بك ، فقد اخترت التكنولوجيا الخاصة بك. اعتمادًا على المكان الذي تجمع فيه فريقك معًا ، سيأتون بمهارات محددة. لذلك ، فكر جيدًا في كيفية تشكيل فريق التطوير الخاص بك وما إذا كنت بحاجة إلى إجراء تقييم تقني قبل الوصول إلى هذه النقطة في رحلتك.
• هذا يقودنا إلى فرق متعددة الوظائف. تعمل الفرق بشكل أفضل عندما تعمل معًا ، عندما يتدخل الأفراد لإنجاز المهمة بغض النظر عن المسمى الوظيفي. حاول بناء فريق مكتفٍ ذاتيًا وأفرادًا يقومون بأكثر من دور.
• قم ببناء بيئة ، وثقافة ، ومركز علاقات - مكان يمكن للفريق تقديمه فيه ، دون قيود أو قيود. امنح الفريق الأدوات والأشخاص والموارد والمساحة ليكونوا فعالين وذوي أداء.
• اجعل أحجام الفريق لا تزيد عن سبعة أو ثمانية. إذا كنت بحاجة إلى المزيد من المطورين ، فقم بتقسيم الفريق إلى عدة فرق جديدة. قد يكون كل فريق مسؤولاً بعد ذلك عن منطقة وظيفية معينة. إذا كان لديك فرق متعددة في مواقع متعددة ، ففكر في عقد Scrum of Scrums. وحيث تتعدد في البيئات المعقدة ، استخدم إدارة المشاريع الرشيقة.
• تأكد من أن الفريق والعمل وأصحاب المصلحة وحتى العملاء يمكنهم الوصول إلى بعضهم البعض. تأكد من تواصلهم وتعاونهم وإزالة أي شيء يعيق التقدم. التواصل اليومي هو أفضل علاج لأمراض المشروع. عندما يتحدث الناس ، فإنهم ينجزون الأشياء.

هناك العديد من الطرق التي يمكن من خلالها تكوين فريق لتقديم البرامج.

موجز المشروع

في خطوة الجدوى ، حددت "سبب" مشروعك وإما أن تبني ثقتك للمضي قدمًا في بدء التشغيل أو الحصول على دعم للمضي قدمًا. موجز المشروع هو المستند الحي الذي يجمع "لماذا" مع "ماذا" و "متى" و "من". إنه "حي" لأنه ، مع تقدمك ، قد تتغير معرفتك وفهمك ومسارك. لترك هذا المستند مكتوبًا مرة واحدة وعدم العودة إليه مطلقًا ، يؤدي فقط إلى إرسال أفكارك إلى نقطة زمنية معينة. في عالم رشيق ، قد يتغير مرجعك في نقطة زمنية أسبوعيًا أو حتى يوميًا في وقت مبكر ، لذلك من المهم الحفاظ على تحديثه.

• أداة رائعة لتغليف موجز مشروعك والحفاظ عليه هو شيء يسميه جوناثان راسموسون "سطح البداية" في كتابه The Agile Samurai . ستجد هنا نصائح رائعة حول ضمان وجود كل من يهتم بمشروعك أو يتأثر به أو يشارك فيه في نفس الصفحة.
• إن أكبر عدو لتسليم المشاريع هو وجود فهم مختلف غير واضح ، أو غير متسق ، أو مجرد فهم مختلف لما هو المشروع وما هي "المتطلبات" التي يجب تلبيتها. إذا كان أحد أصحاب المصلحة المهمين لديه فهم أو وجهة نظر مختلفة لما تفعله ، فقد تكون العواقب وخيمة.
• يوضح موجز المشروع الجيد ما يلي:
  1. توقع مشترك ومتفق عليه بين أصحاب المصلحة وأعضاء الفريق.
  2. فهم المشروع ، بنفس الفهم عبر جميع الأطراف.
  3. الهدف والرؤية والهدف والنطاق وسياق المشروع.
• سيكون لديك الكثير من المعلومات الجيدة للموجز الذي تم جمعه من الجدوى. سيساعدك موجز المشروع في تحديد والعثور على إجابات لأسئلة البحث. سيجمع أصحاب المصلحة ، وسبب وجودك ، والنطاق عالي المستوى ، والمخاطر ، والحل المستهدف ، والميزانية ، والجدول الزمني ، والتوقعات ، والأولويات.

أوقفني أحد الزملاء في أحد الممرات ذات مرة وسألني من أين يمكنه الحصول على موجز المشروع الخاص بالمشروع. قلت مازحًا "لسنا بحاجة إلى موجز ، نحن رشيقون". بدا مرتبكًا ، كما لو كان يشكك في عقلاني أو سلطتي. كان محقا في فعل ذلك.

قبل المتابعة ، تأكد من حصولك على الجميع في نفس الصفحة ، ورش العمل بها ، وطرح الأسئلة الصعبة ، ثم ضعها في مكان ما حيث يمكن للناس التوقف ، وقراءتها ، والتعليق عليها ، والمساعدة في مراجعتها.

الثقافة وطرق العمل

أنت تعرف الطريقة التي يعمل بها عملك وثقافته ، والطريقة التي يحبها لإنجاز المهام. قد تتحدى Agile ، بطبيعتها ، بعض طرق العمل هذه التي طورها عملك على مر السنين. لا تتوقع أن يتم تنفيذ Agile وأن يتبناه الجميع بمحبة من البداية. قد يجدها بعض الناس محيرة ولا ينظرون إليها إلا بفزع وخوف. قد يرفض بعض الناس علانية الانخراط في ذلك. هذه هي التحديات والتصورات التي يجب عليك التغلب عليها. لكن في أيامك الأولى ، لا تذهب للتلويح بالعصا الرشيقة وتضرب أي شخص لا يستمع إليها. لن يؤدي ذلك إلى بناء الثقة أو التبني أو المشاركة.

كنت من محبي التلويح بعصي كبيرة يضرب بها الأمثال مرة واحدة ، وقد أكسبني ذلك الكثير من الصحافة السلبية. قلبتها ، ولكن ليس قبل أن أعاني من ألم شديد أولاً.

بينما تنطلق في طريق التبني ، تخطو بحذر واحترام وتعاطف. إذا كنت تمارس نشاطًا تجاريًا تقليديًا قديمًا ، فربما لن يكون هذا هو أفضل نهج لمواءمة العمل بأكمله. ابدأ صغيرًا واكسب الاحترام والتقدير بشكل متزايد. ابدأ بفريقك فقط. بمجرد أن تبدأ في تقديم برنامج أسرع بجودة أفضل من أي وقت مضى ، سيبدأ الناس في ملاحظة ذلك وسيرغبون في اللعب للعبك. عندما يفعلون ذلك ، قدم لهم الكرة ، وأخرجهم لتناول القهوة ، ودخلهم إلى عالمك الجديد. ساعدهم.

مع فريقك ، الآن بعد أن عرفوا ما يدور حوله المشروع وتم الاتفاق على خططك لتبني Agile ، دع الفريق يقرر كيف يرغبون في التصرف والعمل كفريق واحد.

• قم بتوجيه فريقك لتحديد المفاهيم والتقنيات والسلوكيات والأطر المرنة التي تشعر أنها تناسب احتياجاتك الجماعية.
• خذ الطلبات من أعضاء فريقك فيما يتعلق بالمتطلبات التي يحتاجونها لمساعدتهم على الأداء بأفضل ما يمكنهم. ستتمكن من حل بعض هذه الطلبات على الفور. البعض الآخر ، قد تحتاج إلى الحصول على ميزانية أو مساعدة خارجية. افعل ما بوسعك لتحقيق ذلك.
• هذه هي خطواتك الأولى لتصبح قائد خادم حقيقي.
• ضع في اعتبارك تنظيم بعض التدريب المناسب على المفاهيم والتقنيات التي يختار فريقك تبنيها. هذه هي أفضل طريقة للتأكد من أن جميع أعضاء فريقك ، حتى أصحاب المصلحة ، على نفس الصفحة والحصول على نفس الرسالة. اعمل مع مؤسسة موردة يمكنها تكييف عروضها وفقًا لاحتياجاتك.
• كن حذرًا. لن يكون أي شخص نينجا رشيقًا بعد بضعة أيام في ورشة عمل يتعلم فيها كيف تصبح رشيقًا. سيكون طريقك طويلا. كلمة "تصبح" معرّفة تمامًا. فقط عندما تتبنى Agile حقًا ، سترى قيمتها. يجب أن يثيرك. إذا كان هذا يثيرك ، فقم بإثارة الآخرين أيضًا.
• الآن بعد أن وافق فريقك على المفاهيم والتقنيات ، وتم تلبية رغباتهم ، وهم في تدريب أجايل ، وجه انتباه فريقك إلى أنفسهم وما يتوقعونه منك ومن الشركة ومن بعضكم البعض.
• تحديد بعض طرق العمل (WoW) داخل الفريق وبواسطته يساعد على بناء الثقة والعلاقة والتوقعات. الحرب العالمية الثانية ليست حربًا وسلامًا . يجب أن يكون قصيرًا ومباشرًا ، بين سبع وعشر جمل مدببة. توضح هذه الجمل بوضوح كيف يتصرف الناس ويتواصلون ويتعاونون ويدعمون ويقدمون ويؤديون معًا. يجب أن يذكر أيضًا ما يتوقعه الفريق من العمل.

• Agile هي عقلية بقدر ما هي توجه المبادئ والمفاهيم. يساعدك على تطوير الطريقة التي تتصرف بها ، وتفكر ، وتفاوض ، وتتفاعل ، وتتواصل ، وتؤدي ، وتتحسن. يعتمد على الأفراد المتحمسين الذين يدعمون بعضهم البعض للوصول إلى هدف مشترك ، معًا كواحد. يوجد مثل أفريقي:

الآن ، يجب أن يكون فريقك متحمسًا للغاية وحيويًا ومحفزًا. الآن ، قم بإشراكهم بشكل أكبر في الأعمال المتراكمة الخاصة بك من قصص المستخدمين.

تراكم

ليس لديك أدنى شك في أن هناك عدم يقين في مشروعك. لا يمكنك أن تعرف بالضبط ما الذي يتطلبه الأمر لبناء المنتج المناسب لعملائك في وقت مبكر جدًا من حياته. لا يمكنك التحديق بحزن في كرة بلورية والتنبؤ بالمستقبل.

"backlog" أو "Product backlog" هو المكان الذي تعيش فيه متطلباتك. يفضل Agile كتابة عبارات قصيرة وقوية تجسد جوهر "المطلب". التراكم هو ببساطة قائمة طويلة من الإدخالات ، كل إدخال يحدد "مطلب" فردي منفصل كقصة مستخدم. ومن الآن فصاعدًا ، سنستخدم كلمة user story وليس "المتطلبات". ربما تسأل "لماذا؟" هذا سؤال جيد. لما يبدو إلى الأبد ، فإن ذكر الميزات أو الجوانب المطلوبة في مشروع برمجي من قبل العميل كان يشار إليه دائمًا على أنه مطلب. هذه الكلمة لها تفسير لا قيمة له في Agile. يعرفه قاموس أكسفورد بأنه:

الشيء المطلوب أو المطلوب. أو شيء إلزامي. شرط ضروري.

ولسوء الحظ ، إذا شرعنا في تحديد ما يجب أن يكون الحل لدينا ، وذكر أن الأشياء "إلزامية" ، فسننتهي في مشكلة. من السهل جدًا القول إن كل قصص المستخدمين هذه إلزامية. إذا أخذنا هذا الرأي ، فإننا نخاطر بتجاوز الجدول الزمني والميزانية في محاولة لتقديم كل نطاق معين. ليس من الصعب أن نقول أنه ، بالنسبة لهذا المنتج ، هناك حاجة إلى هذه القصص لكي يكون الحل قابلاً للتطبيق ، نريد فقط تجنب تفسير تلك الكلمة المعينة.

• اكتب دائمًا القصص من منظور الشخصية. تمثل الشخصية مستخدمًا أو صاحب مصلحة في الحل. إنها فكرة جيدة أن تطور هذه الشخصية قبل أن تبدأ في تراكم الأعمال.
• في هذه المرحلة ، اكتب فقط عبارات قصيرة وبسيطة تقترح بشكل أساسي تذكيرًا لإجراء محادثة أعمق حول قصة المستخدم عندما يحين الوقت.
• يفكر الأشخاص الحقيقيون من حيث المهام التي يحتاجون إلى إنجازها لتحقيق هدف ما. اكتب قصصك من منظور الشخصية وفيما يتعلق بما يحتاجون إلى إنجازه.
• لا تحتاج إلى كتابة الأعمال المتراكمة بالكامل - فقط اكتب بقدر ما تتخيل أن العملاء سيحتاجون إليه ليكون منتجك قابلاً للتطبيق.
• ستكتشف لاحقًا من خلال عمر المنتج أن قصص المستخدمين ستتغير ، أو تصبح أكثر أو أقل أهمية ، أو يمكن حذفها تمامًا. الإفراج في كثير من الأحيان ، والحصول على ردود الفعل ، وتقييم ما هي الأولوية سوف يوجه هذا السلوك.
• لا تكتب القصص في عزلة. قم بإشراك فريقك وأصحاب المصلحة وحتى العملاء. يمكن تحديث القصص في أي وقت من عمر المشروع ولكن يجب تجنب التغيير بمجرد بدء أعمال التطوير عليها.
• يمكن اعتبار بعض قصصك "ملاحم". هذه قصص كبيرة تغطي الكثير ، وسيتم تقسيمها أقرب إلى وقت التسليم إلى قصص أصغر.
• ضع في اعتبارك استخدام نموذج INVEST ، وهو قائمة تحقق للتحقق من جودة قصة مستخدم جيدة.
• يمكن لأي شخص إضافة قصة إلى الأعمال المتأخرة. يجب وضعها في الأسفل ، أو في "ساحة انتظار" مُنشأة خصيصًا. هذه القصة المضافة بمثابة حافز للمناقشة مع الفريق والعمل. إذا دعمها العمل والفريق ، فيمكن تقديرها وتحديد أولوياتها
• يمكنك أيضًا التفكير في أجزاء النظام الأكثر خطورة. إذا كانت لديك قصة مستخدم أو ميزة معقدة أو جديدة أو غير معروفة تقنيًا ، فامنحها الأولوية على رأس الأعمال المتراكمة. بهذه الطريقة ، لن تحاول تقديم الأجزاء الصعبة والحاسمة من منتجك قبل أسابيع قليلة من إصدارك الأول.

بمجرد أن يكون لديك تراكم يلبي احتياجاتك ، يمكنك تقدير القصص الموجودة فيه ، وترتيبها حسب الأولوية ، وبناء خطة إصدار.

تقدير عالي المستوى وتحديد الأولويات

التقدير عالي المستوى هو عملية تحديد حجم الأعمال المتراكمة. ما مدى "ضخامة" المشروع ، وما هي القيمة التي يقدمها؟ تحديد الأولويات هو عملية تحديد القصص الأكثر أهمية بالنسبة لك ، وجدوى المنتج ، ومصالح عملائك. نريد تقديم العناصر الأعلى قيمة في أقرب وقت لتقديم أكبر قيمة للأعمال ، والحصول على تعليقات من العملاء ، وعدم إجهاد الأشياء الصغيرة. سيكون الناتج عبارة عن تراكم مرتب مرتبة حسب الأولوية والحجم المناسب.

• تعتبر القصص في الجزء العلوي الأكثر قيمة. نريد تسليم العناصر الأكثر قيمة في أقرب وقت ممكن.
• هناك العديد من الأساليب لتحديد الحجم والتقدير ، ولكن في هذه المرحلة ، ما عليك سوى الحصول على إحساس جيد بالمؤشر لحجم القصة.
  • استخدم أحجام القمصان أو المقاسات النسبية أو الأيام المثالية أو نقاط القصة.
• لن يكون لديك جميع المعلومات المتاحة في هذه المرحلة أيضًا ، ولا بأس بذلك. فقط اركض معها.
• قم بإشراك أصحاب المصلحة في عملك أو مدير المنتج إذا كان لديك واحد ، والفريق الذي سيقوم بالعمل.
• نريد أولئك الذين سيصممون العمل ويطورونه ويختبرونه ليقيسوه ، لأن أفضل الأشخاص الذين يمكنهم تقديرهم هم الخبراء.
• قد يبدأ الفريق في تقسيم القصص إلى أجزاء أصغر. إذا حدث هذا ، فاكتب قصصًا أكثر تفصيلاً ولكنها منفصلة.
• قد يبدأ الفريق أيضًا في تصنيف بعض القصص ، حيث يجب بطبيعة الحال تسليم بعض الأشياء قبل غيرها لدعم التكنولوجيا أو رحلة مستخدم معينة.
• بينك وبين الفريق ، قد تبدأ أيضًا في العثور على ثغرات في الأعمال المتراكمة التي يجب سدها. ما عليك سوى ملء تلك الفجوات بقصص جديدة وتقديرها وتحديد أولوياتها حسب الاقتضاء.
• يتم تحديد الأولويات بسهولة أكبر باستخدام تحليل MoSCoW. MoSCoW هي تقنية بسيطة تساعدك على تحديد القصص "التي يجب أن تمتلكها" حتى يكون منتجك ناجحًا.
• يمكنك إجراء تمرير تحديد الأولويات قبل أن يبدأ التقدير. ومع ذلك ، فإن تحديد حجم بعض العناصر قد يحدد أيضًا قرارًا بشأن الأولوية وقيمة العمل الحقيقية. لذا قم بتقدير وترتيب الأولويات بعيدًا عن بعضكما البعض ، لكن لا تتشاجر عليها!
• لا يمكن أن تكون هناك قصتان بنفس أهمية الأخرى. القصة في المرتبة 1 أكثر أهمية أو قيمة من القصة في المرتبة 2.
• طريقة رائعة لإثبات أهمية أو قيمة القصة هي إضافة قيمة نقدية إليها. على سبيل المثال ، إذا كان يُعتقد أن القصة (أ) تجلب 5000 دولار من العائدات الإضافية ، والقصة (ب) قد تجتذب 100 دولار ، فإن القصة (أ) تكون أكثر قيمة. وبالمثل ، إذا كانت القصة "ج" تحفظ العمل أكثر من القصة "د" ، فإن القصة "ج" تكون أكثر قيمة.
• بمجرد تحديد حجم الأعمال المتراكمة الخاصة بك ، سيتبقى لك رقم. عندما نأتي إلى إصدار التخطيط ، سيساعدنا هذا الرقم على فهم المقدار الذي يمكن لفريقنا تسليمه خلال إطار زمني معين.

Remember that you don't need to know all your user stories up front. Also, remember that it's not necessary to deliver all of your stories before a customer sees your product. You want to remain Agile—and that means only creating what you need to when you need to, wasting as little as possible, and responding to changes in customer needs and market conditions. A roadmap will help you lay out your product and plan your objectives for the next 3, 6, 9, and 12 months.

Roadmap and Storymaps

A roadmap is exactly as it sounds, it offers the same as a roadmap of a country. It details the relative position of cities (or in your case, features) to each other and the routes that can be taken to get from city A to city B, or feature X and feature Z. It doesn't tell you which route you should take, or how you should get there. It doesn't tell you which mode of transport to use, but it might illustrate options to take the highway or the train.

In a city, there are many roads, buildings, parks, services, and facilities. All features of a city. This is also true of the roadmap for your product. At this level, your roadmap shows major goals or milestones to be achieved. A goal is a logical grouping of themes, features, and user stories rolled up in a consumable view that demonstrates tangible value. The roadmap of a software product shares this view and communicates your intent. It doesn't necessarily show you how or when features will be delivered; only the relative value of the goals and features to you and your business.

One great way to demonstrate a roadmap is to generate a story map. This tool indicates customer valued prioritization. It lays out the backbone, or essential building blocks of your product. The walking skeleton hangs off the backbone and illustrates the features that make it an MVP. All the other features are what add further value and importance to the system. The story map lays features in relative position to each other and is an awesome visual tool.

It's worth noting that after carrying out a story mapping exercise, your backlog may need to be refined. This will be apparent where stories have been split into multiple stories, identified as redundant, newly created, or as a higher or lower priority than previously thought. The story map is another artifact that is continually revisited and revised.

The Initiation phase is typically performed once in the life of your project. However, many of the tools and documents you created will be revisited and revised throughout the project.

Release Planning

“At last,” I hear you cry, “finally, some planning.” Well, you have essentially been planning all through the feasibility and initiation stages; we just didn't call it as such. This is evidence of iterative or adaptive planning—the art of only planning enough to achieve your immediate and most valuable goals. We'll see later more about adaptive planning, but for now release planning is our focus.

Your release plan may well be determined by external events. Perhaps there is a trade show you want to demonstrate your app at, or your customers will get the most benefit using your app on the run-up to Christmas. These are timeline events that your goals may be aligned with. You would most likely plan to deliver user stories or features that make the most sense to facilitate these events. If there are no external dates that you need to consider, then you can just go with feature prioritization and delivering earliest what makes the most sense and delivers the most value to your customers.

• If you created a story map in initiation, this will help guide your release plan. Use it to identify your MVP, the minimum feature set that will get your product in the hands of your customers, start earning revenue, get feedback, and acquire more customers.
• The story map will help you carve out future releases too. But keep in mind that as you learn, get feedback, inspect, and adapt, future releases may change. So don't plan in great detail.
• You may have from two to four releases in a 12-month period. Don't do less, because your first release is your MVP and gets your foot in your door, after which you'll want to iterate and release more features and bug fixes in a regular cycle. Don't do more unless you're performing well and have plenty of Agile techniques and tools in place to manage continuous delivery.
• Each release is a timebox which is broken down into smaller iterations. An iteration is a timebox. The timebox is one of the most important control measures in Agile.
• To size your release:
  • Divide your release timebox by two. This will give you how many iterations you have. So if you have a release of 12 weeks, you get six two-week iterations.
  • Then remove two iterations—you'll reserve one for a “sprint 0” iteration and another for a “release” iteration. This leaves you with four development iterations.
  • Work with your team and product owner to fill each iteration with stories, starting from the top of the backlog and working down. When the team thinks they've filled an iteration with enough stories they can realistically achieve based on their capacity in the two-week timeframe, repeat for the next iteration(s). Use the release plan and story map to guide what goes into each iteration.
  • Do not plan the next release yet. You'll do that as you near the end of the current release.
  • Take the user stories from each of your iterations and add up the story sizes. So if your iteration 1 has 25 story points, but iterations 2, 3, and 4 have 10, 45, and 65 points, respectively, you will need to refactor. Target an equal number of story points in each iteration. This becomes your anticipated velocity—the amount of valuable “stuff” completed for each iteration.
• The team may not have worked together before. They are almost certainly working on a new problem or product. They will not perform at their best from day one. For this reason, your velocity may be volatile in the first few sprints. But as the team settles down, it should stabilize. Use this data to refactor your release planning which, in turn, helps you plan your product with a known velocity and confidence.
• If necessary, break stories into smaller chunks and resize.
• Your release plan, especially early in the life of a project and a new team, is only ever a guide. Do not treat it as a commitment or guarantee that all or these exact stories will get delivered as planned. As your team matures, work gets done and trust and confidence builds, so will the accuracy of your plans.
• Never force your team to “commit” to more than they are comfortable with. Trust their judgement and their expertise.
• Future release planning exercises will be simpler, because you'll take the release size, multiply the number of iterations by your team's velocity, and fill the release plan with the stories that add up to velocity multiplied by the number of iterations.

Consider this as an example. If you go to a restaurant to eat, you wouldn't go ahead and order all the items on the menu and expect to eat it all in one sitting. You'd never be able to eat it all, you might not afford the cost, you'll be sick of food, and the restaurant may close while you're eating the fifth of 19 courses! You may not leave a happy customer, the restaurant may not find you to be a great customer, and the experience will be bad all around. More likely, if you love the restaurant, it'll be because you enjoyed a lovely meal there once. You'll decide to go back and enjoy a different meal. You'll tell your friends, you'll go there often. The moral of the story is:

• Plan your releases in small chunks.
• Consider your capacity.
• Don't take on more than you can realistically achieve.
• Revisit the plan often to see what you can change and improve.
• Plan, execute, inspect, learn, adapt, repeat .

Release planning takes place often in a software project. Each new release requires a release plan. The release plan can also be refactored at any time during a project. Just take care to not overdo it and fall into zombified planning psychosis. At the end of release planning, you'll want to prepare for the first iteration, which is where we're happily going next!

Product Iterations

Your team is in place, they're motivated, you have an engaged business, your initial planning is done—you're now ready to build your dreams.

We talked earlier about some of the tools, techniques, and concepts that Agile subscribes to. There are many resources already available that do a great job at laying the foundations for delivering an Agile software project. Pick one, keep it vanilla, and grow into your Agile journey. To help shorten the trauma in deciding the right Agile software development methodology to start with, I'd recommend Scrum. And only Scrum. The temptation will be there to use elements of other methodologies. Don't do it yet. Save that kind of change until you have lived and breathed Scrum for 6 or 12 months. Then, if either you've determined it alone does not work for you or you want to mature as a team, steadily introduce new methods, techniques, or frameworks.

I choose Scrum as the recommended approach for new team's adopting Agile because it has all the basics built in. It's very popular and has many good-quality communities and resources online, in books, or in the training room. It will serve you well, even for the smallest of teams. The rest of this post is dedicated to discussing some important aspects of software delivery that you, your team, and stakeholders should always keep in mind.

Adaptive Planning

Planning in an Agile project is an ongoing process. We do some initial planning up front, just enough to understand what we know at a given point. Our initial plans will be loosely defined and flawed. And then we iterate our planning, adapting to new information, planning in greater detail just before we enter into delivery, responding to changing scope. This is one way of minimizing waste—only putting effort into planning when we need to.

• The team and the business, or its informed and authorized representative such as a product manager, actively plan together—the team because they are the experts that will deliver and the product manager because the are the experts who can guide the needs of the business.
• Estimates for user stories will be less accurate the further out they are from being developed. For example, epics will attract high-level estimates that will be based on a lot of unknowns. Well-defined and granular user stories that are estimated just before a sprint starts will be much more accurate.
• There are many estimation “scales” you can use. Use the technique that feels most right for your team and the right stage of planning—wide-band delphi, planning poker, ideal time, relative sizing, story points, or t-shirt sizes.
• When sizing a story, one size really does fit all. All stories should be sized using the same technique and encompass all elements such as design, development, testing, and refactoring. When you come to do iteration planning for a sprint, certain tasks can be created which all contribute to the completion of the story.
• Always factor risk, unknowns, outside influences, your team's capacity, and ever-improving velocity in planning.
• If user stories that were taken into a sprint were not completed, we do not extend the timebox. These unfinished or unstarted items are put back to the top of the backlog and taken into the next sprint.
• Always plan to deliver the least amount required to achieve a given goal. Identify techniques to prune features. Reduce waste and find the real value that can be realistically delivered with your time-constrained resources.

Story Creation

Stories get elaborated upon when you need them. You don't need full story explanations for features that are six months away from being delivered. Writing them at the beginning may be wasted effort, when that need disappears from scope. Write your stories at most two iterations before they are needed. Reducing that timeframe to one sprint is preferable.

Let's take your time in sprint 0 to set the scene. In two weeks, you'll start development. It's now time to take enough of the stories from the top of the backlog that could potentially get delivered on sprint 1. You might take 10-15% more if you're unsure on your velocity. These one-liners can now be expanded into truly valuable documents with scenarios, acceptance criteria, and wireframes. If the wireframes haven't been created yet, now's the time to do so. You might find as you review these candidate stories that they need to be broken down. Perhaps they were epics that couldn't possibly be completed in a sprint. If you break stories down, re-estimate them with the team.

A good story follows the following rules: - Written in a common format, eg, AS A <persona> I WANT <to do some task> SO THAT <achieve some result>. - Includes acceptance criteria that the story must meet to be considered acceptable to the business for sign-off. - Uses language that the business and your customers understand. - Follows the INVEST model. - Includes all supporting documents to inform the developer, designer, and tester: wireframes, technical design overview, other assets. - Meets your standard “definition of done” criteria.

Sprinting

Whether you call it a sprint, an iteration, or a timebox, each incremental delivery of your Agile project is time-constrained. The timebox doesn't shorten and it doesn't lengthen. Focus on two-week iterations at the beginning. You might find that 1, 3 or 4 weeks suits your business model better. Once you choose a length, don't change it. You want to maintain a regular cadence, or a sustainable pace. This means the team and business focus on delivering regular software without mad-dash overtime being employed to get the job done and releasing potentially shippable increments every two weeks.

• العمل بزيادات صغيرة له فائدة كبيرة. هذا يعني أنك تركز فقط على المستقبل القريب للتسليم ، ومن خلال المدخلات والتعليقات الجديدة والتعلم ، يمكنك الاستجابة للتغيير في دورة تكرارية قصيرة.
• في بداية الإصدار ، قم بإجراء سباق سريع 0. يتيح ذلك للفريق والعمل وإصدار مشروعك الاستعداد ويضع عقلية التسليم الناجح. ارسم الإطار الفني الأساسي والبنية التي ستدعم الأساس للإصدار. إعداد البيئات والحسابات والأدوات. قم بإجراء التموجات لفهم المشاكل الصعبة أو غير المعروفة. قم بتفصيل قصص المستخدم الخاصة بك استعدادًا للعدو السريع 1. يتعلق Sprint 0 بالاستعداد.
• أثناء الإصدار ، استمر في تحسين الأعمال المتراكمة. كلما فهمت أكثر أو تتعلم شيئًا جديدًا ، قد تتغير أولوياتك ، وقد تتكشف متطلبات جديدة ، وما كنت تعتقد سابقًا أنه ميزة رائعة قد تتم إزالته تمامًا.
• لا تبدأ العمل الذي ليس لديه فرصة لإكماله في سباق سريع. إذا لم تستطع ، قسّمها إلى أجزاء أصغر. ولا تبدأ عملًا جديدًا عندما لم يكتمل العمل الذي بدأ مسبقًا. أنت لا تخلق أي قيمة ببدء الكثير من الأشياء التي لا يمكن اعتبارها كاملة. علاوة على ذلك ، تجنب تبديل السياق. هذا هو نشاط بدء مهمة واحدة ، والانزعاج ، وبدء مهمة أخرى ، وفي أكثر حالاتها إشكالية ، عدم إكمالها أيضًا.
• حدد مقدار العمل الجاري من قبل الفريق في أي وقت. على سبيل المثال ، إذا كان لديك ثلاثة مطورين ومختبِر واحد ، فيمكنك وضع حد ويب للمطورين وعلى المختبِر.
• لا تقم أبدًا بإضافة المزيد من العمل للعدو السريع بعد التخطيط له. لا تتوقف أبدًا عن الركض السريع جزئيًا. الاستثناءات من ذلك هي:
  • إذا كان أداؤك أسرع من المتوقع ، ففكر في أخذ القصة التالية من الجزء العلوي من الأعمال المتراكمة ، طالما أنها معدة بشكل مناسب.
  • إذا كان أداء العدو سيئًا لدرجة أنه لن يكتمل. يحدث هذا عادة فقط عندما تكون هناك كارثة ببعض الوصف.
  • إذا لم يعد من الممكن دعم هدف العدو بسبب الاحتياجات الفورية المتغيرة للشركة.
• إذا ألغيت العدو ، فافعل ذلك برشاقة ، وخذ وقتًا لإعادة التركيز ، وابدأ في سباق سريع جديد كما تفعل مع أي شخص آخر.
• قرب نهاية الإصدار ، ضع في اعتبارك إطلاقًا سريعًا نهائيًا. لم تتم كتابة أي ميزات جديدة ، ويمكن تنظيف بعض الأخطاء ، ويمكن إجراء الاستعدادات لإصدار نسخة جديدة من منتجك لعملائك. هذا لا يعني أنه لا يمكنك عمل إصدارات إضافية للعملاء في هذه الأثناء - إنها مجرد آلية إصدار محكومة ومحسوبة ومستدامة.
• في نهاية الإصدار ، قد تفكر في الركض لمدة أسبوع واحد. في هذا السباق السريع ، قد تعمل مع الفريق لتحليل بعض الأفكار الجديدة أو اكتشاف بعض التقنيات الجديدة. هذه أدوات رائعة تفيد الأعمال ، وتمنح الفريق بعض المساحة الموجزة للتفكير والإبداع. إنه ليس من أجل التخبط وسيظل يخلق قيمة. وبالمثل ، يحتاج الجميع إلى استراحة. يساعد أخذ إجازة في هذا الوقت في الحفاظ على إيقاعك وسرعتك في حالة جيدة عندما تكون في منتصف فترة الإطلاق.

تحديد تم

من المهم للغاية تحديد ما تعنيه كلمة "تم". هناك العديد من إصدارات "تم" خلال حياة مشروعك - ما يعنيه "إنجاز" قصة أو إصدار أو مشروع كامل. كل هذا يتلخص في ما ستعتبره أنت وفريقك وعملك كاملاً إلى المستوى الصحيح من الجودة لتلبية الاستعداد للشحن.

بالنسبة لفريقك ، سيكون تعريف القصة "تم" شيئًا مثل اكتمال كل التعليمات البرمجية ، ومراجعتها من قبل الزملاء ، وتفي بمعايير القبول المحددة ، واختبار الوحدة ، و UAT ، ودفعها إلى مستودع الكود الخاص بك. لتمكين تمرير قصة من مصمم إلى مطور إلى مختبِر ، يجب قبول تعريفات "تم" من قِبل الشخص التالي في السلسلة. سيكون لدى مالك المنتج الخاص بك توقعات بشأن ما يعنيه هذا بالنسبة لهم من أجل إطلاق زيادة المنتج لعملائك. على أي حال ، يجب أن يكون الجميع على دراية بما تعنيه كلمة "تم" وأن يكونوا طرفًا مسؤولاً في ضمان تلبية معناها. حدد تعريفك لمصطلح "تم" ، وقم بتوصيله ، واتفق عليه ، وقم بتطويره. انتهى.

القياس المستمر

إذا لم تتمكن من قياسه ، فلا يمكنك إدارته. الشيء نفسه ينطبق على التحسينات. إن الحاجة إلى جمع البيانات التجريبية في مشروع Agile أمر حيوي تقريبًا مثل وجود دورة الدم في عروقك! كيف تعرف ما الذي يحتاج إلى إدارة أو تصحيح أو تحسين إذا لم تكن هناك بيانات؟ حسنًا ، ببساطة ، ستعتمد على الشعور الغريزي والتخمين الذي لا أساس له ، والذي ينهار بسرعة كبيرة تحت الفحص. واعتمادًا على من يقوم بالفحص ، قد يكون هذا مكانًا غير مريح إلى حد ما. لذا ، من بداية مشروعك ، تأكد من أنك تعرف كيف ستظهر التقدم وما هي التدابير التي سيشاهدها الآخرون لنجاحك.

لحسن الحظ ، تأتي Agile محملة بأدوات وتقنيات مفيدة. أول ما عليك فعله هو الرجوع إلى Agile Manifesto ، كتابة الكلمات التالية في معالج الكلمات المفضل لديك ، وتفجيرها حتى 96 نقطة ، والطباعة ، وتطبيقها على الحائط ليراها الجميع:

إن أعظم قوتك التي يمكن إثباتها في تقديم البرامج هي إظهارها للأشخاص العاملين ، والقيام بما يفترض القيام به. لن يؤدي ذلك إلى إسعاد عملائك فحسب ، بل سيكسب فريقك احترامًا كبيرًا ويزيد العجلات من أجل اعتماد أكبر من خلال العمل.

فيما يلي بعض الأدوات الأخرى:

• الموقف اليومي: هناك عدد قليل من الاختلافات في هذا الحفل ، ولكن الجوهر هو أن يتحدث جميع أعضاء الفريق مع بعضهم البعض وجهًا لوجه: اجعله قصيرًا ، وحافظ على تركيزه ، واجعله خفيفًا. إذا كان هناك أي شيء يحتاج إلى مناقشة مطولة ، فقم بإيقافه لإجراء محادثة أطول بين الأشخاص المطلوبين بعد الوقوف. إذا أثيرت العوائق ، فاكتبها مثل قصة ، وأضفها إلى الأعمال المتراكمة الخاصة بك ، وقم بمعالجتها في أسرع وقت ممكن. أي شيء يعيق فريقك يؤدي إلى إبطاء تقدمهم ويمكن إثباته بسرعة منخفضة وبرمجيات لا تلبي التوقعات.
• السرعة: أداة تاريخية. إنها تشبه إلى حد ما تلك التحذيرات المالية التي تحصل عليها والتي تقول إن الأداء السابق ليس ضمانًا للأداء المستقبلي. لكن في حالة Agile ، نأمل في تحقيق سرعة فريق سلسة إلى حد كبير. إنها السرعة التي تسمح لنا بإسقاط الأداء المستقبلي والثقة في خططنا. قد تكون هناك تأثيرات خارجة عن إرادتك مما قد يقلل من عدد نقاط القصة الناتجة عن سباق معين. إذا حدث هذا ، فمن المحتمل أن تتمكن من التعافي. لا تستخدم السرعة أبدًا كعصا للتغلب على فريقك ؛ لن يكسبك أي نعمة. شيء واحد مؤكد هو أن السرعة ستكون غير منتظمة في أول 2-4 سباقات السرعة. ومع ذلك ، في مكان ما في هذا الإطار الزمني ، يجب أن تبدأ في رؤية الاتساق والاستقرار. إذا كانت سرعتك تتأرجح من طرف إلى آخر ، فلديك مشكلة ستحتاج إلى حلها مع فريقك.
• مخطط الإنهيار: الآن مقياس التقدم هذا مقياس شائك. لهذا السبب ، لم أعطي رابطًا للبحث عن المزيد - سيتعين عليك إجراء البحث الخاص بك والاتفاق كفريق وعمل يعمل من أجلك. ما السبب في أنها شائكة؟ حسنًا ، لا يوجد مصدر واحد يحكي نفس القصة! هناك شيء واحد متفق عليه وهو أنه سيُظهر ، خلال سباق أو إصدار ، كيف تقوم بأدائك مقابل Timebox الخاص بك. إذا تم صيانته يوميًا ، فسيظهر ما إذا كنت على المسار الصحيح أم منحرفًا. تستخدمه بعض الفرق لتمثيل مقدار القيمة المتبقية ليتم إنشاؤها ، في كثير من الأحيان ، يستخدمها آخرون لإظهار مقدار العمل المتبقي لإنجازه. الأول هو احتفال بالنجاح وتوليد القيمة ، والثاني أقل إلهامًا وتحفيزًا.
• مخطط الاحتراق: إذا كان يجب عليك إظهار معدلات إتمام العمل ، فاستخدم مخطط التوقف لذلك. لكن استخدام مخطط الاحتراق يسمح لك بإظهار مقدار القيمة التي تم إنشاؤها ومقدار القيمة الإضافية التي تخطط لإنشاءها بنهاية السباق. أداة أكثر تحفيزًا للفريق ليوضح للشركة ما تم إنجازه (أو القليل إذا لم تكن الأمور تسير على ما يرام ...) وما الذي لا يزال لديهم نصب عينيه. على أي حال ، استخدم المخططات لتحديد أين لا يتم تتبع التقدم كما هو متوقع وابحث عن الأنماط أو الانحرافات وتغلب عليها لإصلاح المشكلة الأساسية في أسرع وقت ممكن. قم بتحديثها يوميًا من أجل سباقات السرعة ومرة ​​واحدة في نهاية السباق لإصدار مخططات الإصدار.
• لوحات المهام: هذه مشعات بصرية رائعة لإثبات القيمة التي يتم إنشاؤها. عند تحديثها يوميًا ، أو في أي وقت من اليوم ، فإنها تُظهر على الفور التقدم المحرز. إذا تم دمجها مع Kanban ، فهي أيضًا أدوات رائعة لتصور التدفق والانسدادات في النظام. إذا كان بإمكانك رؤية أن الكثير من التطوير قد اكتمل ، ولكن الاختبار ليس مثمرًا ، يمكنك رؤية المشكلة تحدث والاستجابة بشكل مناسب وسريع.

الأدوات الأخرى التي يجب مراعاتها هي القيمة المكتسبة من Agile ووقت الدورة ومخططات التدفق التراكمي (CFD's).

حافظ على هذه المقاييس والمخططات والأدوات الأخرى مرئية ، ويفضل أن تكون عالية وفخورة على الحائط ليراها الجميع. يمكن للفريق وأصحاب المصلحة والأطراف المعنية الأخرى رؤية حالة المشروع على الفور. إنها شفافة وتعمل كأداة اتصال قيمة. إذا لم تتمكن من وضع هذه القطع الأثرية على الحائط ، فاستخدم الأدوات التي يمكن مشاركتها وتعاونية وتأكد من أن أولئك الذين يريدون الوصول إليها يمتلكونها.

تحسن مستمر

طوال حياتك المرنة ، اسع إلى تحديد ومعرفة أين يمكن إجراء التحسينات. لا يتم التقاط الدروس وتعلمها في نهاية المشروع. إنه مثل اجتياز اختبار القيادة الخاص بك وأخذ قيادتك الأولى مبدئيًا بدون مدرب. ستعرف ما الذي ينجح وما يفترض أن تفعله ، ولكن بمرور الوقت ستصمم مهاراتك وقدراتك في القيادة ، وتتعلم تقنيات جديدة. حتى أنك ستلتقط عادات سيئة. ابحث عنها ، وافهمها ، وابحث عن طرق لتحسينها.

هناك العديد من الفرص لتحديد ما لا يعمل وتطبيق العلاجات. النهج المدمج لهذا في Agile هو بأثر رجعي. هذه هي الأداة الأساسية للتفكير والتعديل. في نهاية كل سباق ، خذ وقتًا مع الفريق لتحسين كيفية إنجاز العمل ، وكيف يتم تقديم الجودة ، وكيف يمكن تعظيم الكفاءة ، وكيف يمكن تقليل النفايات إلى الحد الأدنى وكيفية زيادة السعة. عندما تحدد تدابير للتحسين ، لا تنجذب لإصلاح كل مشاكلك على الفور. حدد العناصر التي سيكون لها أكبر تأثير ويمكن تنفيذها في السباق التالي. القياس والمراقبة. إذا كان له التأثير المطلوب ، فقم بإغلاقه ، واكتبه في طرق العمل وتعريفات الإنجاز. إذا لم ينجح الأمر ، فكر مرة أخرى. يمكن إيقاف أي دروس مستفادة لا يتم وضعها في السباق القادم وتحديد أولوياتها في السباق التالي.

تفصيل العملية. قم بإزالة أي شيء لا يعمل. إزالة العوائق. نضجك كفريق رشيق لن يعرف أي حدود إذا سمحت بذلك.

ما وراء Agile Project Management

من المهم معرفة ما يحدث بعد تسليم المشروع. يعد الدعم والصيانة عاملين أساسيين لضمان استمرار أداء المشروع بمجرد أن يصبح في أيدي العملاء ؛ يمكن أخذ ملاحظات العملاء في الاعتبار في الإصدارات المستقبلية ؛ ويتم التعامل مع قضايا العملاء بشكل مناسب. المشروع هو مسعى فريد من نوعه مقيد بالوقت. المنتج الذي يقدمه له عمر بعد حل فريق المشروع. تأكد من أنك قادر على دعم المنتج بمجرد نشره.

تتعايش المشاريع الرشيقة مع الأساليب التقليدية. تحقيق التوازن بين متطلبات مراقبة الميزانية ورؤية أصحاب المصلحة مع أهداف Agile المتمثلة في المرونة والاستجابة.

يتم استخدام إطار الحوكمة أو نموذج الحوكمة الرشيق جنبًا إلى جنب مع عمليات Agile القياسية ، مثل Scrum. إنهم يعملون بطريقتين محددتين:

• أنها توفر غلافًا لمشروع Agile من خلال توضيح العمليات التي تحدث خارج تكرارات التطوير (سباقات السرعة). وهذا يشمل توفير معايير واضحة للانتهاء بنجاح من بدء المشروع والتحقق المناسب من القرارات والخطة.
• إنهم يغيرون تركيز أجزاء معينة من عملية Agile القياسية ويسلطون الضوء على مبادئ وتقنيات معينة تحتاج إلى الحوكمة أو دعم الحوكمة.

في عالم اليوم المتغير باستمرار ، تحرص المؤسسات والشركات على تبني نهج أكثر مرونة لتقديم المشاريع ، وتريد أن تصبح أكثر مرونة. ومع ذلك ، بالنسبة للمنظمات التي تقدم المشاريع والبرامج ، وحيث توجد بالفعل عمليات إدارة المشروع الرسمية الحالية ، فإن الطابع غير الرسمي للعديد من مناهج Agile أمر شاق ويُنظر إليه أحيانًا على أنه محفوف بالمخاطر. تحتاج هذه المنظمات التي تركز على المشروع إلى نهج رشيق ناضج - خفة الحركة ضمن مفهوم تسليم المشروع - إدارة المشاريع الرشيقة .

تعلم وتنمو مع تبنيك لـ Agile. لا تفعل أبدًا إلا ما يرتاح إليه فريقك ، وتأكد من سماع صوتهم ، والتصرف بناءً على طلباتهم. شجع فريقك على تبني تقنيات جديدة وأكثر قيمة عندما يحين الوقت. تفاوض مع الشركة وشجعها على فهم ما يعنيه أن تكون منظمة أجايل.

استمتع بالرحلة.