Agile Data Science - العمل مع التقارير Agile Data Science - Working With Reports

 Agile Data Science - العمل مع التقارير Agile Data Science - Working With Reports

Agile Data Science - العمل مع التقارير

Agile Data Science - العمل مع التقارير     Working With Reports

Agile reporting methods for project managers  طرق إعداد التقارير الرشيقة لمديري المشاريع? 

التقارير الأربعة التي ينشئها مديرو المشاريع عادةً في نهاية كل تكرار لمشاريع Scrum Agile.

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

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

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

تقنيات التقرير Scrum Agile

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

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

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

• Product Backlog ، التي تسرد جميع الميزات التي يتكون منها المنتج بأكمله

• Sprint Backlog ، والتي تتضمن الميزات التي التزمنا بتقديمها في التكرار التالي

• تقرير التغييرات ، الذي يوضح الاختلافات بين Product Backlog و Sprint Backlog

تقرير أو مخطط Burndown ، الذي يوضح (عادة في شكل رسم بياني للاتجاه) العمل الذي "استنفدناه" بالفعل ، مما يمنحنا رؤية واقعية لتقدم الفريق

Product Backlog المنتج المتراكم

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

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

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

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

سباق المتراكم sprint backlog

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

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

تقرير التغييرات

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

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

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

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

على الرغم من عدم تضمينه في كل تنفيذ لـ Scrum ، فإنني أفضل تقرير التغييرات من التجربة المريرة للاختلاف و "الذاكرة الملائمة" عندما تؤثر التغييرات المطلوبة من قبل العملاء على الجدول الزمني أو التزامات الميزانية.

مخطط حرق burn down chart

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

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

إنشاء التقارير التطوير الرشيق Agile scrum 

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

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

import csv
#----------------------------------------------------------------------
def csv_writer(data, path):
   """
      Write data to a CSV file path
   """
   with open(path, "wb") as csv_file:
   writer = csv.writer(csv_file, delimiter=',')
   for line in data:
   writer.writerow(line)
#----------------------------------------------------------------------
if __name__ == "__main__":
   data = ["first_name,last_name,city".split(","),
      "Tyrese,Hirthe,Strackeport".split(","),
      "Jules,Dicki,Lake Nickolasville".split(","),
      "Dedric,Medhurst,Stiedemannberg".split(",")
   ]
	
   path = "output.csv"
   csv_writer(data, path)

سيساعدك الكود أعلاه في إنشاء "ملف csv" كما هو موضح أدناه -

دعونا نفكر في الفوائد التالية لتقارير csv (قيم مفصولة بفواصل) -

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