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

لا تفقدها.اشترك واحصل على رابط المقال في بريدك.

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

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

الطريقة الرشيقة: تعريف وتاريخ موجز

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

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

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

• في عام 1991 ، كانت هناك طريقة للتطوير السريع لتطبيقات RAD
• في عام 1994 ، ظهرت طريقة لتطوير الأنظمة الديناميكية DSDM
• في عام 1995 ، ظهرت منصة (إطار) التطوير السريع Scrum
• شهد عام 1996 تقديم منهجية التطوير الرشيقة Crystal Clear بالإضافة إلى البرمجة القصوى XP
• في عام 1997 ، ظهرت منهجية تكرارية لتطوير برامج FDD

بشكل جماعي ، تم تجميع هذه التقنيات معًا تحت الاسم العام لتطوير البرمجيات الرشيقة.

بعد أربع سنوات ، في عام 2001 ، اجتمع سبعة عشر من مطوري البرمجيات في Snowbird في ولاية يوتا ، الولايات المتحدة الأمريكية. نتيجة لمناقشة طرق التطوير ، تم نشر بيان تطوير البرمجيات الرشيقة (مترجم من مفهوم اللغة الإنجليزية"Agile" تعني "agile" أو "nimble" أو "سريع" ، ولكن في معظم الحالات تُترجم إلى "agile"). حدد وتيرة جميع الأعمال الإضافية المتعلقة بإنشاء البرامج.

بيان أجيل

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

1. يعتبر الأشخاص وتفاعلاتهم أكثر أهمية من العمليات والأدوات
2. برنامج العمل أكثر أهمية من التوثيق
3. العملاء والتعاون معهم أهم من عقد والتفاوض على الشروط
4. الاستعداد لإجراء التغييرات أكثر أهمية من الخطة الأصلية

مبادئ رشيقة:

1. إرضاء العملاء من خلال تقديم البرامج في وقت مبكر وبشكل مستمر (يسعد العملاء عند وصول برنامج العمل إليهم بانتظام وعلى فترات منتظمة)
2. قم بتغيير متطلبات المنتج النهائي طوال دورة التطوير بأكملها
3. تقديم برامج العمل قدر الإمكان (مرة واحدة في الأسبوع ، كل أسبوعين ، في الشهر ، وما إلى ذلك)
4. الحفاظ على التعاون بين المطورين والعميل طوال دورة التطوير
5. دعم وتحفيز كل من يشارك في المشروع (إذا قامت بعمل أفضل بكثير في مهمتها من الفريق الذي يكون أعضاؤه غير راضين عن ظروف العمل)
6. توفير تفاعل مباشر بين المطورين (إمكانية الاتصال المباشر يساهم في مزيد من التواصل الناجح)
7. قم بقياس التقدم باستخدام برنامج العمل فقط (يجب أن يتلقى العملاء برامج وظيفية وعاملة فقط)
8. الحفاظ على وتيرة العمل المستمرة (يجب على الفريق تطوير سرعة العمل المثلى والمستدامة)
9. انتبه إلى التصميم والتفاصيل الفنية (بفضل المهارات الفعالة والتصميم الجيد ، يحصل فريق المشروع على فرصة لتحسين المنتج باستمرار والعمل على تحسينه)
10. حاول أن تجعل سير العمل بسيطًا قدر الإمكان ، والبرنامج بسيط ومفهوم
11. السماح لأعضاء الفريق (إذا كان بإمكان المطورين اتخاذ القرارات بأنفسهم ، وتنظيم أنفسهم والتواصل مع أعضاء الفريق الآخرين ، وتبادل الأفكار معهم ، تزداد احتمالية إنشاء منتج عالي الجودة بشكل كبير)
12. التكيف باستمرار مع البيئة المتغيرة (بفضل هذا ، سيكون المنتج النهائي أكثر تنافسية)

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

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

النقاط الرئيسية في تطبيق Agile

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

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

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

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

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

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

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

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

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

• ماذا فعلت البارحة؟
• ماذا سأفعل اليوم؟
• ما الذي يمنعني من العمل؟

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

1. يشار بوضوح إلى معنى المشروع
2. يشارك العميل بنشاط في عملية التنفيذ
3. يتم تنفيذ إجمالي حجم العمل خطوة بخطوة
4. يجب أن تركز على نتيجة محددة
5. حجم مجموعة العمل الواحدة: من 7 إلى 9 أشخاص

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

أمثلة: حكومة نيوزيلندا ، حكومة نيجيريا ، صندوق المعاشات التقاعدية النرويجي ، مسار العودة (برنامج) ، Oreo (شركة بسكويت) ، Aviasales (أكبر محرك بحث عن تذاكر الطيران) ، Hewlett-Packard (أكبر شركة تكنولوجيا معلومات في أمريكا) ، Sberbank "( ربما تعرف ما هو).

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

تقنيات إدارة المشاريع الشعبية

هناك العديد من طرق إدارة المشاريع التي يتم استخدامها من قبل مختلف الشركات الحديثة... لكن أشهرها وأكثرها طلبًا هي سكرم وكانبان.

طريقة سكروم

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

تتمثل الطريقة في حقيقة أن تطوير المشروع ينقسم إلى سباقات سريعة ، في نهايتها يتلقى العميل برنامجًا محسّنًا. يتم تحديد أوقات السباقات بدقة ويمكن أن تستمر من 2 إلى 4 أسابيع. يتضمن سير العمل في سباق واحد عدة مراحل:

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

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

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

طريقة كانبان

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

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

على عكس Scrum ، اكتسب Kanban شعبية في وقت لاحق ، لكن هذا لا يقلل بأي حال من مزاياها ولا يجعله أقل فعالية. هذه الطريقة مفيدة في مجال تكنولوجيا المعلومات وفي مجال الأعمال.

هذه مجرد أمثلة على تقنيات إدارة المشاريع المبنية على أساس رشيق. لكن لا تهمل الطرق الأخرى مثل PRINCE2 و Lean و ستة سيجما، XP ، CCPM ، ECM ، الشلال وغيرها. بالإضافة إلى ذلك ، فإن Agile لها بعض العيوب إلى جانب مزاياها.

إيجابيات وسلبيات Agile

عند فهم Agile ، من المهم أن تكون على دراية بالجوانب الإيجابية والسلبية لهذه المنهجية. لنبدأ بالإيجابيات.

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

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

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

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

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

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

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

تنفيذ رشيق

هناك الكثير من الأمثلة على تطبيق Agile في عمل الشركات. وعمليًا جميعهم يقولون إنها تتطلب مجموعة كاملة من التدابير المهمة.

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

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

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

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

استنتاج

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

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

نفسر ماهية المنهجية الأساسية ، ونكشف عن المفاهيم الأساسية ، ونوضح كيف يعمل فريق أجايل وكيف يتم تقييم فعاليته.

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

أسئلة مزعجة

• كيف تتأكد من أن التأخير في أحد الأقسام لا يمنع الآخرين؟
• كيف تتعامل مع حقيقة أن تطوير خطة المشروع لا يستغرق حتى 30٪ من الوقت من الحجم الإجمالي لتنفيذه؟
• كيف يمكن في النهاية اتباع هذه الخطط؟

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

من أجل الانتقال إلى مستوى جديد نوعيًا عمل التصميم، فقد تطلب الأمر نقلة نوعية أساسية.

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

افعلها على الفور!

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

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

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

التنظيم الأفقي

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

تختلف مبادئ بناء فرق أجايل من مشروع إلى آخر. على سبيل المثال ، في خدمة الموسيقى Spotify ، تم إنشاؤها على النحو التالي:

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

ولكن من الضروري أن يكون لديك معرفة أساسية بالتخصصات ذات الصلة في تطوير Agile.

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

كيف يتم تطبيق Agile؟

قد يكون الانتقال من تطوير الشلال ، الذي لا يزال شائعًا في العديد من المؤسسات ، إلى إدارة المشاريع الرشيقة أمرًا مؤلمًا.

أولا،يجب عليك إلغاء التسلسل الهرمي وفي نفس الوقت التأكد من أن جميع المشاركين في العمليات يمكن أن يتقاسموا المسؤولية عن النتيجة بالتساوي.

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

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

ما هي منهجية Agile؟

Agile هو نموذج تطوير تكراري يتم فيه إنشاء البرنامج بشكل تدريجي من بداية المشروع ، على عكس نماذج الانحدار ، حيث يتم تسليم الكود في نهاية دورة العمل.

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

يمكن تقسيم المبادئ الـ 12 التي تشكل منهجية Agile إلى 4 أفكار رئيسية:

• أولوية الأشخاص والتواصل على الأدوات والعمليات ؛
• أولوية المنتج العامل على الوثائق الكاملة ؛
• أولوية التعاون مع العملاء على الموافقة على العقد ؛
• إعطاء الأولوية للاستعداد للتغيير على الالتزام بالخطة الأصلية.

الأساليب الموجودة في Agile:

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

تم استخدام الطريقة بنجاح من قبل شركات مثل Microsoft و Yahoo و Siemens Healthcare ، حتى أن مدير المشروع في Amazon وصفها بناءً على الخبرة المكتسبة.

نظرًا لأن Scrum هو إطار تطوير ، فقد يختلف في كل مثال لاحق بشكل كبير عن المثال السابق.

حدد جيف ساذرلاند ، المؤلف 8 خطوات لاستخدام هذه التقنية:

1. الرجاء التحديد مالك المنتج- يعرف الغرض من المشروع والنتيجة المتوقعة.
2. تجميع يأمر- ما يصل إلى 10 أشخاص لديهم المهارات اللازمة لإنشاء منتج عملي.
3. تجد سادة سكروم- يراقب تقدم المشروع ويساعد فريق المشروع على التغلب على الصعوبات.
4. ميك أب تراكم المنتجقم بإعطاء الأولوية لكل متطلب منتج على لوحة Agile. يلعب مالك المنتج دورًا مهمًا في هذا ، حيث يجمع رغبات المنتج لتقييمها من قبل فريق backlog.
5. يخطط سباقات السرعة(التكرارات) - فترات زمنية لإكمال مجموعة محددة من المهام.
6. تنظم يوميًا لمدة خمس عشرة دقيقة "MIT-ups"- اطرح 3 أسئلة على كل فريق: ماذا فعلت بالأمس ، ماذا سيحدث اليوم ، ما الذي يمنعك من إتمام المهمة.
7. يفعل مراجعات أجزاء عمل المنتج- بمشاركة أصحاب المصلحة في المراجعة والمناقشة.
8. أنفق بأثر رجعي- مناقشة المشكلة والبحث عن حل بعد كل سباق. قم بتنفيذ خطة التغيير الناتجة في السباق التالي.

رشيقة بأثر رجعي

يحتوي سكرم على 4 عناصر رئيسية:

• المنتج Backlog- قائمة متطلبات المشروع
• سباق المتراكمة- قائمة بالمتطلبات التي يجب تلبيتها في السباق التالي
• هدف Sprint- هدف العدو
• سبرينت بيرنداون الرسم البياني- رسم تخطيطي يتم تحديثه عند اكتمال المهام. من السهل فهم ديناميكيات ومستوى تقدم الفريق في المشروع.

(XP)

ابتكر مطور المنهجية ، كينت بيك ، طريقة برمجة متطرفة ، تهدف إلى التعامل مع المتطلبات المتغيرة باستمرار لمنتج برمجي وتحسين جودة التطوير.

إنه قابل للتطبيق حصريًا في مجال تطوير البرمجيات ، وهو مبني على 4 عمليات:

1. الترميز- وفقًا لمعايير التصميم الموحد في الفريق ؛
2. اختبارات- الاختبارات يكتبها المبرمجون أنفسهم قبل كتابة الكود المراد اختباره ؛
3. تخطيط- كل من الإنشاء النهائي والتكرار الفردي. يحدث هذا الأخير في المتوسط ​​مرة كل أسبوعين.
4. سمع- كل من المطور والعميل ، حيث تختفي الغموض ويتم تحديد المتطلبات والقيم.

منهجيات

تم تطوير مجموعة من المنهجيات ، غير المعروفة كثيرًا في المساحات المفتوحة المحلية لإدارة المشاريع ، من قبل أليستير كوكبيرن ، أحد مؤلفي بيان تطوير البرمجيات Agile. يقترح كوكبورن إجراء التصنيف حسب اللون وفقًا لمعيار عدد الأشخاص في الفريق: من 2 (Crystal Clear) إلى 100 (Crystal Red). بالنسبة للمشروعات الأكبر حجمًا ، يتم تمييز ألوان المارون والأزرق والبنفسجي.

يجب أن تلبي مشاريع الكريستال 3 مؤشرات رئيسية:

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

طريقة تطوير البرمجيات الديناميكية (DSDM)

لم يعمل شخص واحد أو حتى فريق على تطوير DSDM ، ولكن مجموعة من 17 شركة إنجليزية. يستخدم DSDM ، مثل البرمجة المتطرفة ، في المقام الأول لتطوير البرمجيات.

يتم تعيين دور خاص لمشاركة المستهلك النهائي (المستخدم) في عملية التطوير. بالإضافة إلى هذا المبدأ ، تشمل المبادئ الأساسية ما يلي:

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

ينقسم DSDM إلى إصدارات يتم تحديثها مع تطور التكنولوجيا ، وتظهر متطلبات جديدة لتطوير البرامج. آخرها اليوم هو DSDM Atern ، الذي صدر في عام 2007 ، على الرغم من أن الإصدار السابق (2003) لا يزال في الخدمة.

في البداية ، يدرس الفريق واقع تطوير التطبيق ونطاق التطبيق. علاوة على ذلك ، ينقسم العمل إلى ثلاث دورات مترابطة:

1. دورة النموذج الوظيفي- إنشاء التوثيق التحليلي والنماذج الأولية.
2. دورة التصميم والبناء- جعل النظام في حالة صالحة للعمل.
3. دورة التنفيذ- نشر النظام.

التطوير المدفوع بالميزات (FDD)

منهجية تسبق بيان تطوير البرمجيات السريع Agile Software Development Manifesto.

على الرغم من أن FDD يستخدم أيضًا نموذج تطوير تكراري ، إلا أنه يختلف عن Agile في ما يلي:

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

يتكون التطوير المدفوع من الميزات من المراحل الدورية التالية:

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

تطوير البرمجيات

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

تتضمن المجموعة المبادئ السبعة التالية:

1. التخلص من الخسائر- أي شيء لا يضيف قيمة للمنتج للمستهلك النهائي.
2. التعلم المستمر- يزيد التطوير المستمر للفريق من القدرة على إنجاز المهام بشكل فعال.
3. اتخاذ القرار في وقت متأخر قدر الإمكان- الأولوية ليست قرارات عفوية ، بل قرارات مدروسة ، يتم تطويرها على أساس المعرفة المكتسبة.
4. توصيل سريع- أساس النموذج التكراري بشكل أساسي.
5. تعزيز الفريق- أحد مبادئ "البيان ..." ينص على أن الناس والتفاعل أهم من العمليات والأدوات. فريق المشروع هو العمود الفقري لإنجاز المهام بنجاح.
6. النزاهة والجودة- تحتاج في البداية إلى صنع منتج عالي الجودة حتى لا تضيع الوقت والموارد في إجراء مزيد من الاختبارات والتخلص من الأخطاء.
7. رؤية الصورة كاملة- من المستحيل تقسيم المشروع إلى أجزاء منفصلة دون فهم حالة التطوير الحالية وأهداف ومفهوم واستراتيجية البرنامج الجاري تطويره.

مجموعة متنوعة من منهجيات التطوير السريع

النمذجة الرشيقة (AM)

النمذجة الرشيقة هي مجموعة من القيم والمبادئ والممارسات لنمذجة البرمجيات.

يتم استخدام AM كجزء من منهجية تطوير برامج كاملة - على سبيل المثال ، البرمجة المتطرفة أو التطوير السريع للتطبيقات.

مبادئ النمذجة الرشيقة هي كما يلي:

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

عملية موحدة رشيقة (AUP)

AUP هي نسخة مبسطة من منهجية تطوير برمجيات أخرى - العملية الموحدة العقلانية (RUP). منذ عام 2012 ، تم استبدالها بـ "التسليم السريع المنضبط" (DAD) ، ولكن في بعض الأماكن لا تزال سياسة الاستخدام المقبول (AUP) موجودة.

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

• يعرف فريقك ما يفعلونه ؛
• البساطة تأتي أولا.
• الامتثال لمبادئ منهجية التطوير السريع.
• ركز على الأنشطة ذات القيمة للمشروع.
• الاستقلال في اختيار الأدوات.
• التخصيص الفردي لـ AUP لاحتياجات مشروع معين.

طريقة البيانات الرشيقة (ADM)

ADM عبارة عن مجموعة من منهجيات تطوير البرمجيات الرشيقة التكرارية التي تركز على تشكيل المتطلبات وقرارات المشروع من خلال تعاون الفرق الفردية. مثل AUP ، فهي ليست تقنية مكتفية ذاتيًا.

يتم تحديد جوهر طريقة البيانات المرنة بست نقاط:

1. البيانات- أساس إنشاء أي تطبيق.
2. مشاكل مع المشروع- لا يمكن العثور عليها إلا من خلال فهم واضح لهدف المشروع ومفهومه.
3. مجموعات العمل- بالإضافة إلى فريق التطوير المباشر ، هناك مجموعات مؤسسات تدعم مجموعات العمل الأخرى.
4. التفرد- لا توجد منهجية مثالية ، فكل مشروع تحتاج إلى الجمع بين أدوات من منهجيات مختلفة.
5. العمل بروح الفريق الواحد- العمل الجماعي أكثر فعالية من العمل الفردي.
6. "مكان جميل"- البحث عن الحل الأمثل للمشكلة ("البقعة الحلوة") ، وتجنب التطرف.

العملية الأساسية الموحدة (EssUP)

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

تعمل EssUP بمفهوم الممارسة ، والذي يشمل:

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

تم العثور على جميع الممارسات بشكل أو بآخر في منهجيات التطوير RUP و CMMI و Agile.

الحصول على ريال مدريد (GR)

منهجية فعالة للشركات الناشئة والفرق المبتدئة ، والتي تتيح تحقيق أقصى استفادة من ميزات المشاريع والشركات الصغيرة: التنقل ، والمرونة ، والبحث عن حلول جديدة ، وغياب التسلسل الهرمي الصارم المربك ، إلخ. عرّف Jason Freed و David Hansson ، مؤسسا 37signals (الآن Basecamp) ، الحصول على الواقعية كنظام لحل المشكلات الحقيقية: بسيط ومفهوم وعملي قدر الإمكان.

GR عبارة عن خليط مسبق الصنع من عشرات أدوات التطوير الرشيقة التي تُستخدم لتقليل:

• فرص
• الخيارات والإعدادات
• هيكل الشركة
• الاجتماعات
• وعود.

لم يتم تبني المفهوم غير المعتاد على نطاق واسع ، على الرغم من أن بعض العناصر تستخدم تقنيات مختلفة.

OpenUP (OUP)

منهجية تطوير برمجيات مستقلة عن الأداة بدون بنية صلبة تحتوي على الممارسات التالية:

• قياس سرعة الفريق.
• عقد اجتماعات يومية وجلسات استرجاعية عند الانتهاء من التكرارات ؛
• مفهوم الخطو الدقيق والاختبار المبكر باستخدام قوائم المراجعة ؛
• تقنية النمذجة الرشيقة (AMDD).

يتم تنفيذ الممارسات على أساس أربعة مبادئ:

مقاييس رشيقة

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

بالنسبة لمعظم المشاريع ، 4 مجالات من المقاييس كافية:

1. أداء- وهذا يشمل السرعة والعمل قيد التقدم. الأول غير مناسب لجميع المشاريع ، حيث يتم قياس عدد المهام المكتملة لكل تكرار ، وهي غير متكافئة. يحدد مقياس العمل قيد التقدم حدود المهام في مراحل مختلفة: كلما ارتفع ، كان أسوأ ؛
2. التوقع- مقياس السعة: تحديد عدد الساعات المثالية المتاحة في السباق التالي. وفقًا لذلك ، يمكنك فهم مقدار الوقت الذي لديك للعمل ، ومدى كفاءة إنجاز المهام ، وكيفية العدو ؛
3. جودة- على سبيل المثال ، مؤشر ثبات المتطلبات ، والذي يتم حسابه بواسطة الصيغة = ( مجموعمتطلبات العمل الأصلية + عدد المتطلبات التي تغيرت بحلول هذا الوقت + عدد المتطلبات المضافة + عدد المتطلبات التي تمت إزالتها) / (العدد الإجمالي للمتطلبات الأصلية). يتم استخدام المقياس لتحديد مقدار الوقت المستغرق في إعادة صياغة المهام ؛
4. قيم- في كل حالة يتم احتسابها على حدة حسب شكل المشروع. على سبيل المثال ، اختار بدء التشغيل AirBnb عدد الصور عالية الجودة التي تم تحميلها كمقياس يحدد القيمة النهائية للمنتج للمستخدمين. مع زيادتها ، نما عدد المستهلكين بشكل متناسب.

تنطبق نفس القواعد على المقاييس مثل أدوات Agile الأخرى.

لا يوجد مقياس واحد صحيح أو ضروري لمشروعك.

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

ميثبوسترز: رشيق

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

الخرافة الأولى: Agile يعمل في جميع المشاريع.

أكثر الوهم إصرارا. لا توجد طريقة Agile في حد ذاتها تضيف قيمة إلى منتج أو تحفز الفريق.

الخرافة الثانية: الرشاقة مقابل التوثيق.

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

الخرافة الثالثة: المرونة والتخطيط غير متوافقين.

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

الخرافة رقم 4: تتطلب الرشاقة الكثير من إعادة العمل.

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

إيجابيات وسلبيات استخدام Agile

الايجابيات:

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

سلبيات:

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

التطبيقات

لإدارة المشاريع مع لا يناسب Agile جميع الخدمات أو البرامج لإدارة المشاريع ، لأن لكل منها خصائصه الخاصة.

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

في ما يلي بعض الاختراقات في الحياة لإعداد Agile فيها

1. تخصيص التسميات والحالاتالضرورية لعمل شركتك.
   يمكن أن تكون الحالات على النحو التالي: في التقدم التدقيق القيام به يحتاج العمل الحرجة الميزة دفع.
   غالبًا ما تبدو العلامات بالشكل: تخطيط ، اختبار ، إنتاج ، مفهوم ، كود.
2. إنشاء مشروع متراكمو ربيع المشروع.
3. إنشاء المهاموقوائم المراجعة الأولية والرسومات ، إلخ. في التراكم.
4. على وسائل المساعدة تحديد المنبثقة مهام الربيعو نقلها من التراكمفي العدو.
5. استعمال وصول ضيف العملاءللمهام من أجل الحصول دائمًا على تعليقات متسقة ومحدثة على المشروع.
6. احتفل مسؤول عن المهامحتى يعرف كل زميل مجال مسؤوليته ويشعر بأنه متورط في نتيجة العدو.

حكم

مع تطوير البرمجيات الرشيقة ، تزيد فرق المشاريع الصغيرة من الكفاءة إلى أقصى حد. يتم تنفيذ Agile من خلال طرق Agile الأخرى: Scrum و XP و Lean وما إلى ذلك.

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

الخامس الإدارة الحديثةيُنظر إلى نموذج الإدارة الرشيقة في ثلاثة سياقات مختلفة ، والتي (كل منها بطريقتها الخاصة) تحدد ما هو Agile.

النطاقات الثلاثة للمعنى الرشيق

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

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

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

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

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

مبادئ الإدارة الرشيقة

يتم استخدام Agile في إدارة المشاريع كنموذج لإدارة عمليات الأعمال من قبل آلاف الفرق حول العالم ، وما يلي موجود في كل مكان السمات المميزةهذا النهج:

1. المستهلك ودرجة مشاركته في إنشاء النتيجة أمران حاسمان لتخصيص المنتج.
2. لاتخاذ قرار ، يجب أن تكون الفرق عالية الكفاءة والتماسك.
3. يصبح العمل المرحلي والدوري أساس العملية. ينقسم المشروع إلى أجزاء صغيرة تكتمل في موعد محدد قبل الانتهاء من المشروع ككل.
4. ينصب تركيز تقييم الأداء على العرض المتكرر للحالات الوسيطة للمشروع.
5. يعتمد الفريق في عملهم على قانون باريتو ، الذي بموجبه يعطي 20٪ من الجهود 80٪ من الكفاءة ، مما يسمح بعدم تحقيق الكمال في كل دورة منفصلة قبل تقديم النتيجة إلى المستهلك. المنتج يتطور بشكل طبيعي مع كل تكرار.
6. من المفترض أن تكتمل إحدى المراحل قبل الانتقال إلى المرحلة التالية.

لقد أصبح النهج "المرن" أساسًا لعدد من الممارسات المنهجية التي تختلف عن بعضها البعض ، ولكنها تتضمن أفكار Agile: Scrum ، و Kanban ، و Lean ، و Crystal ، إلخ. مع Agile نظام واحدإدارة مشروع تطوير البرمجيات.

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

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

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

أخطاء وأوجه القصور الشائعة في تنفيذ Agile

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

تتضمن أخطاء التنفيذ الشائعة ما يلي:

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

18 أكتوبر 2017

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

"ما الذي يجب أن نفعله بهذا ، ليس لدينا سوى موقع ويب من البرمجة؟"

نتيجة لذلك ، بالنسبة لحوالي 100٪ من الشركات ، تبدو Agile مثل الدجل.

ولكن ها هي المفارقة - في العالم 77٪ من الشركات * التي تستخدم Agile في المشاريع لا تشارك في تطوير البرمجيات على الإطلاق.

* من المسح السنوي الكبير للشركات VersionOne

بدلا من التعريف. ماذا أقول عن Agile عندما يجتمع أشخاص مختلفون من أقسام مختلفة

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

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

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

السبب الرئيسي لظهور وتطور Agile هو أن كل شيء المزيد من المشاريعليس لديك فهم 100٪ لما يجب أن يكون في النهاية. من المستحيل ببساطة كتابة المهام الدقيقة. وقررنا أن التفاعلات المجانية أهم من التعليمات ، والاستعداد للتغيير أهم من الخطط.

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

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

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

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

إجمالي القيم الأساسية المرنة (البيان):

• تفاعل مجاني مع الفريق
• أداء المشروع (منتج رائع)
• تواصل الشريك مع العميل
• الاستعداد للتغيير

ما هي فرق الدور؟

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

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

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

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

السؤال الرئيسي هو: "كيف تدير الموارد عندما يكون كل شيء مرنًا جدًا؟"

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

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

هناك العديد من المبادئ والأساليب المهمة التي تهدف بشكل واضح إلى التنبؤ بالموارد على وجه التحديد:

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

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

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

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

نستخدم الصف الثالث ، ولكن لا يوجد سوى الصفوف 1 س ، 2 س ، 4 س ، 8 س.

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

5. رسم بياني محترق(جدول الاحتراق)
الشيء البسيط للغاية هو مخطط من سطرين ؛ الأول - مقدار الوقت المستنفد وهذا دائمًا خط مستقيم ، والثاني - كم عدد المهام من حيث الموارد المغلقة وهنا يمكن التقلبات. في الواقع ، هذه إجابة بيانية لسؤال ما إذا كان الفريق يسير وفقًا للخطة أو يتخلف عن الركب.

فيما يلي طرق عامة فقط بدون تفاصيل ، قد يكون من المفيد كتابة مادة منفصلة مع تفاصيل إدارة الموارد. ولكن إذا لخصت هنا في سطرين ، فستحصل على:

• الخطأ الأكثر شيوعًا هو محاولة الدخول في التقديرات بدقة شديدة ، يتوقف الفريق عن العمل من أجل النتيجة
• أنجح نهج هو حجز الوقت والتخطيط لـ 80٪ من الموارد

من الداخل من أكبر وأقدم وأشهر استوديوهات SEO في روسيا- يضعون المخزون في الموارد مرتين ، الأولى عند المناقشة مع العميل ، والثانية عند التخطيط داخليًا.

أشهر 5 ممارسات رشيقة يفهمها الجميع

مرة أخرى ، يعد تطبيق Agile الأساسي أمرًا سهلاً. لا توجد تقنيات فائقة التعقيد تستغرق وقتًا طويلاً لتعلمها. فيما يلي ، على سبيل المثال ، أكثر 5 ممارسات شيوعًا (وفقًا للاستطلاع نفسه من VersionOne)

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

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

2. اجتماعات التخطيط اليومية(88٪ من الفرق تستخدم)
المهمة هي أن يقوم الفريق بتأكيد الاتجاه الوحيد للحركة لجميع المشاركين كل يوم. وفقًا للوصف الكلاسيكي ، يكشف كل فرد في الفريق عن ثلاثة أسئلة:

• ما الذي تم إنجازه من العدو حتى الآن؟
• ما المخطط له اليوم؟
• ما هي المشاكل التي واجهتها أو ما الذي يمنعك؟

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

3. استعادية(83٪ من الفرق تستخدم)
اجتماع في نهاية التكرار. مناقشة ما نجح وما لم ينجح. الهدف الأكثر أهمية هو استخلاص استنتاجات حول كيفية التغيير.
عميل المنتج - حول كيفية إظهار توقعات المستخدمين بشكل أفضل ، ومنهج المنهج - حول كيفية حث الحوار والوفاء باتفاقيات الأساليب المختارة ، والفريق - حول كيفية مراعاة العوامل الناشئة الجديدة في التقييمات. كقاعدة عامة ، تعتبر الأحداث الاسترجاعية ممتعة - لقد انتهى التكرار ، يمكنك الزفير ومناقشة النتائج. ممارسة جيدةشيء ليشربه أو يأكله أثناء فترات الراحة من هذه العملية.

4. الانطباعات المتكررة(81٪ من الفرق تستخدم)
هذا عرض توضيحي من الفريق مرة واحدة في عدة تكرارات لنتائج المشروع ، وعادة ما يكون في شكل خطاب. النقطة الأساسية هي أن يكون لديك "جلسة" ولا بأس إذا كان الأمر يشبه تقديم التقارير إلى الإدارة. تكمن الصعوبة الرئيسية في أن يجتمع شخص آخر غير الفريق ويفهم معنى ما يحدث. في ممارستنا ، تتجذر فقط مع قيادة رائعة جدًا.

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

كيف نفهم ما إذا كان المشروع قيد التنفيذ باستخدام منهجية Agile أم لا؟

يبدو الرسم البياني لعدد الشركات التي تقوم بتغيير Agile لأنفسهم كما يلي:

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

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

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

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