المقدمة: شركة تستخدم إطار عمل متدرج الحجم (SAFe) لتوسيع نطاق تطوير Agile عبر المؤسسة ؛ 10 فرق تطوير مدمجة في فريق واحد كبير (Agile Release Train ، وفقًا لمصطلحات SAFe) لتقديم منتج مشترك ؛ الحاجة إلى تخطيط فصلي لمدة يومين (تخطيط PI) لتحديد خطة عمل فرق تكنولوجيا المعلومات للأشهر الثلاثة القادمة * ؛ ثلاثة مكاتب تطوير بمسافة بين أكثر المكاتب البعيدة التي تتجاوز 6 آلاف كيلومتر وفارق وقت العمل المقابل 5 ساعات ؛ تجربة تخطيط سابقة تتضمن استخدام الألواح التماثلية / ألواح الكتابة / الأضواء / الملاحظات اللاصقة والوجود المادي لكل الموظفين الرئيسيين في نفس الغرفة.
* هذا الوزن الثقيل "خطة عمل فرق تكنولوجيا المعلومات للأشهر الثلاثة القادمة" يهدد بزيادة حجم النص بشكل كبير ، لذلك فيما يلي سأحل محله "الالتزام". وفقًا لذلك ، فإن إعداد واعتماد خطة عمل سيكون "الالتزام".
لماذا نحتاج هذا؟
1) التعب مع أساليب العمل التناظرية. بينما تحرّك سفن الفضاء الفضاء ، بينما يملأ إيلون موسك أنفاقه ، فإننا ، نحن رجال تكنولوجيا المعلومات ، نواصل بإصرار الكتابة على الأعمدة اللاصقة ونلصقها على الألواح - هناك نوع من التنافر في هذا الأمر ، أليس كذلك هناك ؟ هذا ما بدا عليه التزامنا منذ فترة:

نعم ، هذه ورقة بحجم 2 × 5 أمتار ، مع تحويل كل ورقة لاصقة إلى مهمة JIRA بعد التخطيط ...
2) التعب من زملائنا الرحل. على الرغم من أن مكتبنا الرئيسي يقع في بلد لطيف ودافئ إلى حد ما ، فقد فوجئت عندما اكتشفت في العام الماضي أنهم بعيدون عن السعادة في جميع الرحلات ذهابًا وإيابًا. حججتي "حسنًا ، يمكنك الاستمتاع ببعض الاسترخاء في الشمس على شاطئ البحر" لم يتم تلقيها بحرارة شديدة. كما اتضح أن الجميع ليسوا مستعدين لرحلات العمل المتكررة ، والتي غالباً ما تكون غير مرحب بها من قبل عائلاتهم ، فإن بعض الزملاء لم يتمكنوا من تحمل طول الوقت في الهواء بالنظر إلى المسافات بين المكاتب وتواتر الاجتماعات.
3) إشراك المزيد من زملاء تكنولوجيا المعلومات في عملية التخطيط. كما هو واضح من الفقرة أعلاه ، لا يمكننا أن نتحمل جميع موظفي تكنولوجيا المعلومات من المكاتب الثلاثة القادمة للتخطيط ، لذلك تم اختيار فقط المختارين ، وهو ما استبعد الآخرين من هذه العملية. كان هذا بالكاد مفيدًا لروح الفريق بشكل عام.
4) تحسين التكاليف. نعم ، هذه لحظة حساسة - فهناك الكثير من الأشخاص الرئيسيين وجعلهم يطيرون ذهابًا وإيابًا أربع مرات في السنة ليسوا بأي حال من الأحوال مكلفين.
الجزء صفر: العمل مع تراكم الحافظة
كل شيء يبدأ قبل ذلك بكثير من التخطيط الفعلي. من أجل العمل بشكل مثمر على الالتزام أثناء التخطيط ، يجب أن يكون لديك شيء تلتزم به. لضمان ذلك ، يجب عليّ "تحميل" أصحاب الأعمال من خلال العمل على مبادرات محتملة (أو في مصطلحات SAFe ، Epics ، لكن فيما يلي سأستخدم مصطلحنا المعتاد) في أقرب وقت ممكن. من الناحية المثالية ، ينبغي فصل هذه العملية تمامًا عن الطبيعة التكرارية للتخطيط الفصلي وأن تسير في طريقها إلى كانبان. اتخذنا SAFe Portfolio Kanban كأساس:

لدينا مشروع JIRA منفصل مع ثلاثة أنواع من القضايا: الملاحم والمبادرات التجارية والمبادرات المعمارية ؛ وكذلك المقابلة كانبان المجلس. إن الخوارزمية الخاصة بمالك الأعمال في المبادرة بسيطة: فهو يضيف مشكلة إلى هذا المشروع ، وينتقل إلى Backlog افتراضيًا ، وهو الحالة الأولى لتدفق Kanban -
Funnel:
هنا يتم تخزين المبادرات ليست جاهزة بعد للمراجعة. يعمل صاحب العمل على محتوى المبادرة حتى يشعر بأنه مستعد للخطوة التالية. الحد الأدنى المطلوب في هذه المرحلة هو ملء مجالات بيان المشكلة والنتيجة المرجوة وقياس النجاح ، بالإضافة إلى عرض تقديمي أكثر تفصيلاً ولكنه بسيط وواضح. في هذه المرحلة ، من المهم ترك الحلول التقنية جانبا والتركيز على معايير العمل. عندما يتم جمع كل البيانات ، ينقل صاحب العمل المهمة إلى الحالة التالية -
المراجعة.نقوم بإجراء المراجعات على أساس أسبوعي لكل من المبادرات التجارية والمعمارية. من الناحية المثالية ، هذا عرض تقديمي مدته خمس دقائق مع أسئلة وأجوبة تالية. نتيجة للمراجعة ، يتم اتخاذ قرار بشأن ما سيحدث للمبادرة بعد ذلك. يمكن أن:
- أن تعاد إلى القمع للمراجعة ،
- ألغيت دون أي فرصة لمزيد من الحياة (في هذه الحالة يمكنني استخدام حالة خاصة قديمة مخفية على لوحة كانبان) ،
- أن تتم الموافقة عليها وانتقلت إلى المرحلة التالية - تحليل.
في هذه المرحلة نحن - Yippee! - يمكن في النهاية إشراك شباب تكنولوجيا المعلومات: محللون ، مهندسون معماريون ، عملاء متوقعون ، أي شخص. بكلمة "نحن" أعني نفسي كمهندس قطار إطلاق. ولكن من الناحية المثالية ، يجب أن يكون أصحاب الأعمال هم أيضًا الذين اكتسبوا بالفعل بعض الخبرة والاستقلالية اللازمة لإشراك الفرق المناسبة وإطلاق التحليلات بشكل مستقل. مرة أخرى ، أنا أكتب عن الحالة المثالية هنا. في الواقع ، يتحرك مستوى التنظيم الذاتي لزملائنا ، وفي بعض الحالات يطلبون المساعدة من أحد الميسرين المعينين خصيصًا ، لكنني أحاول التراجع عن هذه الممارسة.
الغرض من هذه المرحلة هو التحليلات الأولية ، أو ، كما نسميها ، ما قبل الاكتشاف. نتيجة لذلك ، يجب أن نحصل على الحد الأدنى الذي يسمح لنا بالالتزام: الحلول المقترحة والمخاطر والتبعيات والمتطلبات غير الوظيفية ومتطلبات البنية التحتية وخرائط المستخدم والمخططات المعمارية. بالإضافة إلى ذلك ، نطلب من الفرق تقديم تقييم أولي في نقاط القصة على مستوى الميزة - وهذا سيتيح لنا تحديد الأولويات في نهاية الربع.
يتم إنشاء لوحة Kanban الشخصية في هذه المرحلة لكل مبادرة ، حيث يمكن رؤية الميزات والقصص ، مع وجود رابط أولي لتكرار محدد ، يتم توفيره بواسطة سير عمل منفصل JIRA. لذلك من خلال تغيير الحالة ، يمكننا تخصيص المشكلة لبعض التكرار. يتم تكوين Swimlanes في مجالس Kanban بواسطة فرق التطوير. نظرًا لأن نظامنا JIRA الإيكولوجي معقد إلى حد ما ، خلال فترة ما قبل الاكتشاف والاكتشاف ، نقوم بإنشاء مهام في مشاريع منفصلة حتى لا تتناثر في تراكم الفرق:

أيضًا في مرحلة ما قبل الاكتشاف ، نشرك المهندسين المعماريين أو ، كما كان يتم ممارسته مؤخرًا ، الأشخاص الموثوق بهم - "سفراء EA". تتمثل مهمتهم في نقل رؤية القسم المعماري إلى جميع المشاركين ، للمساعدة في العثور على أفضل الحلول ، وفي النهاية الموافقة على هذا الحل مع رئيس قسم هندسة المشاريع.
عندما يعتقد جميع الأشخاص المعنيين أن المبادرة قد تم تحليلها بما فيه الكفاية وأنها جاهزة للخطوة التالية ، يتم نقلها إلى الحالة التالية -
Portlogio Backlog.في هذه المرحلة ، من المهم إجراء تحديد أولويات WSJF (
الوظيفة المرجحة الأقصر أولاً ). للقيام بذلك ، لدينا اجتماع كبير قبل 3 أسابيع من التخطيط ، والذي ، لسوء الحظ ، استمر حتى الآن عدة ساعات. خلال هذا الاجتماع ، يقوم أعضاء مجلس الإدارة بتقييم قيمة الأعمال ، وأهمية الوقت ، وتقليل المخاطر ، وتمكين الفرص بمساعدة بوكر التخطيط المتوافق مع Fibonacci:

لتكون قادرًا على تتبع تاريخ المبادرات ، أضيف لكل علامة تصنيف في JIRA مع بيانات الربع: 2018Q4 ، 2019Q1 ، إلخ.
في المستقبل ، اسمحوا لي أن أصف جميع الحالات الممكنة. بعد الالتزام النهائي في تخطيط PI ، يتم نقل المبادرات التي تم تنفيذها بنجاح إلى حالة
التنفيذ ، في حين أن تلك "غير المجهزة" تحصل على حالة
متوقفة ويمكن اعتبارها في الفصول التالية. يتم نقل المبادرات التي تم تسليمها إلى حالة
تم .
نتيجة لذلك ، لدينا الصورة التالية على لوحة كانبان:

بالطبع ، نحن لسنا في منتصف طريقنا حتى الآن ، ولكن في الوقت الحالي يمكنني أن أشير بالفعل إلى أنه بفضل تطبيق Backfolio Backlog
- بدأ أصحاب الأعمال في العمل من خلال مبادراتهم بالتفصيل والتحضير الكامل للمراجعة.
- أصبحت المراجعات أكثر دقة بطريقة جيدة.
- الفرق لديها المزيد من الوقت للاستكشاف المسبق.
- لا أفقد المبادرات القديمة - يمكنني دائمًا العودة إلى المبادرات ، أو عدم تسليمها أو نسيانها والعمل عليها.
الأدوات المستخدمة في هذه المرحلة:
- خادم البرمجيات الأطلسية جيرا
- البرنامج المساعد الألوان لجيرا - لتسليط الضوء على الأعمال والمبادرات المعمارية
- المكوّن الإضافي "الهيكل - إدارة المشاريع على النطاق" - لتصور الهيكل المصنوع من المبادرات والميزات التي تخصهم ، وتحديد أولويات WSJF الخاصة بهم
- التقاء الأطلسي - مصدر التوثيق الداخلي
- Lucidchart وملحقاته لـ Jira و Confluence - لرسم المخططات
الجزء الأول. التحضير لتخطيط PI
قبل شهر من التخطيط PI هو عندما يأتي وقت ازدحاما. يجب أخذ العديد من الأشياء في الاعتبار ، ولكي لا أترك أي شيء ، يجب أن أقوم بإنشاء نموذج Google متعدد "لوجستي". اسمحوا لي أن أصف أهم علامات التبويب من هذا النموذج والأنشطة من حولهم.
ردود الفعل. بعد بضعة أيام من كل PI Planning ، نقوم بإجراء استعادي ، مما يساعدنا على عدم نسيان الاستنتاجات التي توصلنا إليها وكيف نحتاج إلى ضبط الدورة التدريبية. هذا جزء مهم من حيث التحسين المستمر.
الإعداد الفني. مع الانتقال إلى التخطيط عن بعد ، ظهرت طلبات محددة ، مثل جودة الاتصال بالإنترنت (تحديد الأولويات وتحسين طرق JIRA و Confluence) والتواجد المرئي والمسموع (نستخدم مجموعات Logitec Group ، ميكروفونات Jabbra وسماعات الرأس الشخصية في مجموعات مختلفة ، كاميرات الويب ، برنامج التكبير لمؤتمرات الفيديو).
الميسرين. إنها قائمة بالموظفين المسؤولين عن التيسير في كل مجموعة من مجموعات العمل ، مع الإشارة إلى موقعهم ورابط إلى قناة الزوم الدائمة لمجموعة العمل.
جمهور. القائمة الكاملة لجميع المدعوين.
المرجعية. قائمة كاملة من المهام الهامة مع المواعيد النهائية والأشخاص المسؤولين. لإعطائك نظرة ثاقبة أدناه ، يمكنك العثور على العديد من الأمثلة لأكثر المهام نموذجية وحيوية ذات الصلة بكل تخطيط PI: تدريب الميسرين (تم إعداد دليل تدريبي مع جميع الخطوات اللازمة مثل تنظيم فريق عمل وتوقيت الاجتماعات و تحليل المبادرة إلى قائمة الميزات) ؛ تحديث خطط مواقع مجموعات العمل لكل مكتب ؛ التحكم في تحديث السرعة لجميع فرق التطوير ؛ طلب وجبات الطعام ؛ إنشاء تقارير من الفصول السابقة ؛ المطبوعات من قوائم المبادرات والجداول.
الجزء الثاني. التخطيط PI وعملية الالتزام
بعد كل التحضير للركض ، تأتي هذه اللحظة أخيرًا - بداية تخطيط PI. في غضون يومين ، يتعين علينا اكتشاف جميع المبادرات ، وتأكد من أن المعلومات كافية وملتزمة. بعد بضع محادثات بيب ، تذهب مجموعات العمل إلى أماكنها وتذهب إلى العمل. في الوقت الحالي ، يتم توزيع عدد المجموعات بين المكاتب الثلاثة على أنها 4x4 × 2 ، ويتم توصيل المستخدمين عن بعد بالمجموعة المطلوبة عبر قناة Zoom مخصصة.
عند الانتهاء من الاكتشاف في كل من هذه المبادرات ، يتأكد الميسر من أن جميع البيانات اللازمة ، مثل معايير القبول ، والحل الفني ، والمخاطر ، والتبعيات ، وضرورة وجود بنية تحتية جديدة ، متاحة وتضع المبادرة مع "تقنية المعلومات" مربع الاختيار انتهى الجلسة "لتتبع التقدم المحرز بسهولة". بعد ذلك ، يمكن للفريق العامل الانتقال إلى المبادرة التالية.
بعد عشرات من مخططات PI ، تلاشى الشعور بأنك تحت الضغط المستمر والضغط الزمني ، الذي كان معنا منذ البداية ، إلى حد كبير ، والآن أصبح الأمر أشبه بالعمل كالمعتاد. في فترة ما بعد الظهر في اليومين الأول والثاني من التخطيط ، حان الوقت لالتزام غير مستعجل وفقًا للأولويات. لأداء التزام ، لدي عدة هياكل منفصلة. الأول هو هيكل يحتوي على قائمة من الميزات والقصص المجدولة للالتزام:

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

نتيجةً لذلك ، ستختفي المشكلة من هذا الهيكل وستظهر بشكل جديد ، مما يعكس الالتزام المتزايد:

كما ترون في لقطة الشاشة ، تندرج القصص في هذا الهيكل في مجلد فريق التطوير الذي ينتمون إليه ويتم تجميعهم بالتكرار. هنا ، أرى إجمالي سرعة الفريق في اسم المجلد ، بالإضافة إلى عمود الالتزام ، يتم تحديد الالتزام الزائد تلقائيًا وتمييزه لكل فريق ، باستخدام صيغة مخصصة.
بطبيعة الحال ، إذا تم إدراج المبادرات ذات الأولوية الأولى والأعلى في التزام في الغالب بسهولة ، في وقت قريب ، حيث يقوم عدد أكبر من الفرق بملء الأعمال المتأخرة حتى النهاية ، فقد تكون هناك مشكلات متعلقة ببعض المبادرات ، بعد بعض الحجج والمناقشات ، تأجيل (متوقفة) نتيجة لذلك.
في نهاية هذه العملية البسيطة إلى حد ما ، أقسمت الفرق بالوفاء بالتزامها بعلم الشركة (حسنًا ، ليس حقًا) والعجلة إلى منازلهم (جيدًا ، مرة أخرى ، وليس حقًا ، يفرون في الغالب إلى مكان ما للاحتفال).
الأدوات المستخدمة في هذه المرحلة:
- خادم البرمجيات الأطلسية جيرا
- المكوّن الإضافي "الهيكل - إدارة المشاريع في النطاق" - لمراقبة عملية الاستكشاف وأثناء تنفيذ الالتزام.
الجزء الثالث. استنساخ القضايا في النظام البيئي JIRA العمل للشركة
بينما يشرب الجميع ، تعمل RTE على إنشاء التزامات بالشكل الذي يمكن به توزيعه على تراكم فرق التطوير ومراقبته طوال الربع. للقيام بذلك ، أستخدم المكوّن الإضافي "Bulk Clone Professional for Jira" - يضيف عنصرًا يقوم بالاستنساخ الجماعي إلى قائمة تغيير الجملة ولديه ميزات ضرورية مثل استنساخ الروابط وتحديث الروابط بين الحيوانات المستنسخة التي تم إنشاؤها حديثًا وتحديث روابط Epic وإضافة ملخص بادئة ووضع العلامات التلقائي:

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

بشكل عام ، تتمثل مزايا هذا النهج فيما يلي:
- من الأسهل على أي شخص في تكنولوجيا المعلومات كتابة ميزات وقصص جديدة بدلاً من كتابتها باستخدام أداة تمييز على ورقة لاصقة.
- يتم احتساب العديد من الأشياء ، مثل السعة المتبقية وتحديث WSJF وفقًا لتقديرات المجموعات النصية ، تلقائيًا باستخدام صيغ مخصصة.
- بفضل الاستنساخ ، يتم الحفاظ على الالتزام الأصلي للتاريخ ويمكننا دائمًا الرجوع إليه.
- يوفر لنا الوقت والطاقة في مرحلة إعداد التخطيط - معالجة الورق تستهلك الطاقة.
- بالطبع ، من الرائع أننا لم نعد بحاجة إلى إضافة مشكلات إلى JIRA عن طريق كتابة ملاحظات لاصقة.
الأدوات المستخدمة في هذه المرحلة:
- خادم البرمجيات الأطلسية جيرا
- البرنامج المساعد "Bulk Clone Professional لـ Jira" - لاستنساخ الميزات والقصص في مشاريع JIRA العاملة.
- المكوّن الإضافي "الهيكل - إدارة المشاريع على النطاق" - لإنشاء هيكل الالتزام النهائي.
خاتمة
أصدقائي الأعزاء ، بالطبع أفهم أن النظرة العامة المذكورة أعلاه سطحية إلى حد ما ، ويمكن الكشف عن الكثير من الأشياء بطريقة أكثر تفصيلاً - مراقبة توزيع القدرات بين مبادرات الأعمال والهندسة المعمارية والمهام التشغيلية ، وحساب الصيغ المخصصة في الهياكل ، وإدارة المخاطر وأكثر من ذلك بكثير. لكن ما زلت لا أعرف ما إذا كان هذا الموضوع مثيرًا للاهتمام للجمهور ، وإذا كان الرد بالإيجاب ، فما هو بالضبط. إذا رأيت أي اهتمام ، سأكون سعيدًا بمشاركة رؤيتي حول الموضوعات ذات الصلة.
وهناك شيء آخر - من الصعب تصديق أن ذلك سيكون ممكنًا ، لكنني ما زلت أود حقًا تجنب الإصغاء المرتبط بـ Agile ، والأطر ، والمديرين الفعالين و "الفعالين" في التعليقات. يرجى تذكر أنني قد وصفت الجزء الفني من العملية برمتها على أمل الحصول على اهتمام الأشخاص القريبين من الموضوع ، وأتطلع إلى إجراء مناقشات ذات صلة.
نراكم في التعليقات!