في الجزء الأول ، نظرنا في الأعراض المقلقة والطرق الممكنة لـ "معالجة" مالك المنتج في حالة سكر "ميكانيكية". نواصل تحليل الدور والخط التالي في الفريق.
ومع ذلك ، فإنهم يعرفون الشعار الذي يجب على الفريق أن يكون منظمًا ذاتيًا ومتعدد الوظائف ، ويبدو أن أبسط جزء من scrum: نأخذ الناس بالكفاءات اللازمة ، ونقول لهم: "أنت فريق" ، وطارنا! لكن في الواقع ، كل شيء معقد إلى حد ما.
التنظيم الذاتي
العَرَض : هناك تسلسل هرمي صريح (إرسال توجيهي) في الخارج ، أو ما هو أسوأ داخل الفريق. على سبيل المثال في الواقع ، قد يكون لمطور المنتج مهمة لا تتعلق مباشرة بأنشطة الفريق. أو ، داخل الفريق ، لا يتمتع الأشخاص بحرية اختيار وظيفة لتحقيق هدف العدو السريع ، ولكنهم يتلقون مهام من "القائد".
ما هو السيئ :
أي حدود - Limits @ CEP
عندما يتم الضغط على الشخص من خلال الوصف الوظيفي ، والتسلسل الهرمي ، وما إلى ذلك ، فهذا يمنعه من الكشف عنه. إن قوة فريق سكروم تكمن في فتح الفرص للناس. هناك مهمة ، والشجاعة وتكون مسؤولة عن تنفيذها. يجب على الشخص أن يقرر لنفسه ما سيفعله لتحقيق هدف العدو. إذا أخبروه بما يجب عليه فعله ، فهذا ليس تنظيمًا ذاتيًا وليس سكرومًا.
كيفية العلاج : بالنسبة للأشخاص في الفريق ، يتم إلغاء جميع الأوصاف الوظيفية والتسلسل الهرمي ، يميل الهيكل إلى أن يكون مسطحًا.
جميع من هم في الفريق هم
مطورو المنتج (
لا يسمح دليل scrum بأدوار أخرى ). هناك قيادة ظرفية فقط ، والناس يقررون مدى ارتياحهم للعمل من أجل أن يكونوا فعالين. بالطبع ، هناك قواعد عامة للعبة في الشركة ، ولا ينتهكها الفريق بأي شكل من الأشكال (
على الرغم من أنه يمكن أن يؤثر على التغيير على مستوى الشركة ) ، ولكنه مسؤول عن جميع الأمور الداخلية. إذا كانت هناك عقبات خطيرة لرفع القيود المفروضة على المطورين ، فمن الجدير تصعيد المشكلة لأولئك الذين قرروا تنفيذ سكروم والتحول رشيقة. يمكنك محاولة تشغيل هيكل مسطح ، مثل تجربة عدة سباقات ، ثم إجراء استعراضي واسع النطاق ، حيث تناقش جميع الأطراف المعنية نتائج التجربة.
العَرَض : يجب على الأشخاص ، بالإضافة إلى العمل كفريق ، أداء واجبات وظيفية أخرى في الشركة. على سبيل المثال: 50٪ من الوقت يؤدي مهام الفريق ، 50٪ - مهام القسم (التطوير ، الاختبار ، إلخ).
من السيء : التركيز على الصفن هو التركيز. يركز الفريق على هدف العدو ويتحرك نحوه. إذا كان على الشخص ، بالإضافة إلى العمل في فريق ، أن يفعل شيئًا آخر ، فسيتم فقد التركيز. ونتيجة لذلك ، ستكون النتيجة أسوأ. من الصعب الحفاظ على روح الفريق في مثل هذه الظروف.
كيفية العلاج : نحتاج إلى التأكد من أن الأشخاص في الفريق يعملون فقط في هذا الفريق. للقيام بذلك ، يجدر فهم طبيعة العمل الذي وقع على مطوري الفريق من الخارج ، وإيجاد طرق للقيام بذلك دون كسر. من المؤكد أن هذا العمل ضروري للشركة ، وبالتالي ، اعتمادًا على تفاصيل العمل ، يمكنك:
- إما وضع العمل في تراكم الفريق ، وبعد ذلك سيتم ذلك وفقًا لسير عمل واحد.
- أو نقلها إلى موظفين آخرين خارج الفريق. على سبيل المثال: لا تعمل جميع الشركات على سكروم ، وتحتاج إلى القيام ببعض الأعمال المنتظمة في وقت محدد ، فإن هذا العمل لم يعد مناسبًا لموظفي سكروم.
- أو يمكن إنشاء فريق خاص واختيار منتج يجمع كل الأعمال من هذا النوع.
- أو ، إذا كانت وظيفة فريدة يقوم بها شخص واحد لعدة فرق بسبب نقص المتخصصين. ثم يجدر إخراج الشخص من جميع الفرق وبناء عملية أخرى من أجله لا تكسر بقية الأسطوانة ( على سبيل المثال: قائمة انتظار مهمة ذات أولوية ) ، حتى يتم العثور على متخصصين في هذه الفرق.
الوظائف المشتركة
العَرَض : الأشخاص داخل الفريق يقومون بعمل معين فقط ، هناك تخصص واضح. والأسوأ من ذلك أنه لا تزال مغطاة بالواجبات واللوائح الرسمية والبيروقراطية الأخرى. إن غياب (إجازة ، إجازة مرضية ، إلخ) لأحد أعضاء الفريق يقلل من وظائف الفريق. مرحبًا ، عامل الباص .
ما هو السيئ : إذا كان الفريق يعتمد على كفاءات أحد أعضائه ، فهو فريق غير مستقر للتغييرات. من الصعب بناء التواصل معها ، لأن أنت بحاجة إلى فهم وظيفتها الحالية وتذكر المخاطر المرتبطة بهذا المستوى من التسامح مع الخطأ. إن التخصص الضيق للمطورين يعقد بشكل كبير العمل التنظيمي للفريق: عند التخطيط ، تحتاج إلى التفكير كثيرًا في من سيفعل ماذا ؛ لا تحتاج كل مهمة إلى نسب محددة سلفًا من كفاءات الفريق ، وبالتالي من الصعب تجميع سباق سريع متوازن ؛ في مثل هذا المخطط ، تنشأ بالضرورة "رقبة ضيقة" ، مما يقلل من السرعة الإجمالية للفريق.
ما يجب القيام به : من الضروري تعزيز ودعم المهارات على شكل حرف T. للحفاظ على مرونة الفريق ، من المهم ألا تتركز وظيفة أو معرفة معينة في شخص واحد. من الضروري تحفيز وتشجيع التطوير المستمر. من المهم التأكد من أن الفريق يتحسن ، ويبحث عن طرق لتحسين العمليات. كخيارات تطوير على شكل حرف T: إجراء ندوات داخلية ، حيث يتبادل أعضاء الفريق المعرفة مع بعضهم البعض ؛ اعتماد قاعدة تنفيذ المهام غير الأساسية كل سباق من قبل كل عضو في الفريق ؛ إقران العمل في المهام ، إلخ. يمكنك تحفيز فريق بشكل مصطنع من خلال "إيقاف" أعضائه لبعض الوقت: العطلات والندوات والدورات التدريبية ورحلات العمل وما إلى ذلك.
العَرَض : في سلسلة القيمة ، يكون الفريق مسؤولاً (التأثيرات) عن جزء صغير منه فقط ، ونتيجة لذلك ، لا يستطيع الفريق إصدار علاوات من تلقاء نفسه.
من السيء : إذا كان للفريق تأثير ضئيل على تقديم الزيادة ( إصدار المنتج ) ، يفقد سكروم جوهره أيضًا: تحدث الإطلاقات بتأخير ، تحدث الملاحظات بتأخير أكبر. بشكل عام ، لا يوجد إيقاع ، وبالتالي السرعة. لا سرعة - لا مرونة. مثل هذا الفريق لا يشعر بملكيته ، إنه مجرد برغي وظيفي في سيارة كبيرة. يجب أن تكون وظائف الفريق كافية لإغلاق معظم سلسلة القيمة ، وإلا لن يقوم الفريق ببساطة بتقديم القيمة ، ولكن ببساطة سيعالج نوعًا واحدًا من "قطعة العمل" إلى نوع آخر وينقله أكثر.
نوضح ذلك بمثال من الويب. حيث تم تبسيط إنشاء ميزة جديدة يتضمن الخطوات التالية:
- تطوير النموذج الأولي لواجهة المستخدم / UX
- تطوير التصميم
- إنشاء RESTful API
- إنشاء SPA
- كتابة اختبارات التكامل
- التجمع والصب على البيئة القتالية
لهذه الأعمال ، مطلوب الكفاءات المختلفة. مثال على تقسيم غير ناجح إلى فرق: لفصل
الفريق A من UI / UX ، والمصممين وتطوير الواجهة الأمامية ، يعدون الزيادة في شكل SPA ؛ لكنهم يعتمدون على الوقت الذي ستجهز فيه الواجهة الخلفية واجهة برمجة التطبيقات للعمل الجديد ؛ انتظر تأكيد الجودة للتحقق من كل شيء بشكل متكامل وكتابة الاختبارات ؛ ومن ثم ما زالوا يتوقعون من DevOps أن يدير كل شيء في المعركة من الصعب أن يكون مثل هذا
الفريق "أ" مسؤولاً عن الإفراج عن القيمة وتقديمها ، فهو يقطع "الفراغ" فقط - SPA.
كيفية العلاج : نحدد الكفاءات التي يفتقر إليها الفريق من أجل تقديم الزيادة. نحن نمنح الفريق هذه الكفاءات من خلال تدريب أعضاء الفريق الحاليين ، أو عن طريق إضافة لاعبين جدد إلى الفريق. لأن إن العثور على / تعليم الناس ليس أسهل وأسرع مهمة ، ثم يمكنك إقامة التواصل مع الفرق / الأقسام المجاورة ، وشرح قيم سكروم لهم والاتفاق معهم حول قواعد / قواعد التفاعل الخاصة التي لن يكسروا فيها فريقك. يجدر تسليط الضوء على عملية توسيع وظائف الفريق: بعد الاستعادة الأولى وتحديد الكفاءات المفقودة ، يمكنك طباعتها ووضعها أمام الفريق. عندما يتعامل الفريق مع نقص في الكفاءة (
علم ؛ عضو جديد في الفريق ؛ أقام اتصالًا فعالًا مع فريق آخر ، وما إلى ذلك ) ، فإننا نعلق حلًا فوق الكفاءة المفقودة سابقًا. بمرور الوقت ، يجب أن يسعى الفريق لتوسيع وظائفه لتغطية سلسلة القيمة بالكامل.
الفريق والمنتج
العَرَض : يوجد فريق ، ولكن لا يوجد منتج. لا PO ، لا تراكم. إنه فقط يقوم الناس بمهام تأتي من اتجاهات مختلفة.
من السيئ : هذا ليس سكروم. عندما لا يتم تعيين منتج إلى فريق ، فمن غير المحتمل أن "يحرق" الفريق بالعمل. عندما يكون هناك هدف عالمي ( رؤية / استراتيجية / خارطة طريق لتطوير المنتج ) ، فأنت تريد أن تذهب إليه. يمكنك القيام بالعمل والحصول على التعليقات والتفكير واتخاذ الخطوة التالية. بدون الإحساس بالملكية ، فإنك تخاطر بأن تكون في روتين: أنت لا تحتاج حقًا إلى التعليقات ، يصبح الفريق مجرد أداة لمعالجة المعارف التقليدية إلى وظائف.
كيفية العلاج : يجب أن يكون لدى الفريق منتج خاص به مع تراكم و PO ، مما يمكن أن يشعل الفريق مع المنتج ويحمله معه - هذا هو الجوهر. هل تريد أن تفهم لماذا تحتاج إلى سكروم؟ هل تفهم من أين يأتي الفريق؟ هل تفهم ما إذا كان هناك "منتج" بين هذا التدفق؟ اختر واحدًا من فرق "العملاء" واجعله مالك المنتج ، مما يمنحه الحق الوحيد في الرد على الأعمال المتراكمة. قد يكون من الضروري تقسيم الفريق إلى فريق سكروم يعمل مع صندوق بريد واحد ( يمكن أن يكون هذا فريق سكروم "تجريبي" ) وفريق ثانٍ ، بينما يعمل بنفس الطريقة مع بقية "العملاء". من خلال توفير أقصى قدر من الشفافية للعمليات والنتائج التي تحدث في فريق سكروم الجديد ، يمكنك إرساء الأساس لمزيد من توزيع سكروم ورشيقة في المنظمة.
العَرَض : لا يؤثر الفريق على مكون المنتج: فهو لا يقرر "كيف نفعل؟" ، يقول الفريق فقط "ماذا تفعل؟" يأتي TK إلى المدخلات ، ويعتبر الفريق كوحدة وظيفية.
من السيء : يعد هذا خيارًا خطيرًا للغاية إذا أعلنت الشركة حقًا عن قيم الرشيقة والصفراء. عادة ما يعني هذا أن جميع الموظفين مهنيون رائعون يمكنهم حل أي مشاكل لا تخاف من اتخاذ القرارات وتحمل المسؤولية. ولكن إذا لم يُسمح لهم باتخاذ قرارات بشأن المنتج ، فعادةً ما تنتشر كل الحرية الإبداعية للفريق من المنتج إلى التكنولوجيا. نظرًا لأنه لا يُسمح للفريق بتحديد كيفية جعل حياة المستخدم أسهل ، فإن العالم أفضل والمنتج أكثر فائدة ؛ ثم يبدأ الفريق في تطوير قاعدة الكود ، وتجربة التقنيات / الأدوات / الأطر الجديدة ، إلخ. هناك تضارب في المصالح بين صندوق البريد والفريق ، يبدأ الفريق في بيع "إعادة البيع" و "التحسين" و "الرصاص الفضي" في شكل كومة جديدة ، إلخ. وهذا يتأثر في المقام الأول بالمستخدم والمنتج. في عملية الانتقال من نماذج الإدارة التوجيهية إلى رشيقة ، هناك خطر من الوقوع في فهم الفريق كوحدة وظيفية ( لم يتخذ الفريق قرارًا من قبل ). هذا أمر محفوف بحقيقة أننا إما نقتل مبادرة الفريق ، أو نأتي إلى موقف يكون فيه الفريق أكثر اهتمامًا بالتكنولوجيا من المنتج.
كيفية العلاج : تحتاج إلى تحديد سبب عدم الثقة في الفريق أو تردده: لماذا لا يبحث الفريق عن حل ، ولكنه يعمل فقط مع مهمة تقنية مفصلة؟ بعد العثور على السبب ، يمكنك التخلص منه تدريجيًا. على سبيل المثال:
- الفريق يفتقر إلى الكفاءات أو الخبرة. : يعمل شخص ما على حلول وكتابة المعارف التقليدية ، يمكنك إما إضافة هذا الشخص إلى الفريق ، أو السماح له بالعمل في بعض المهام جنبًا إلى جنب مع الفريق ، وبالتالي نقل جزء من مهاراته وخبرته إلى الفريق. لذا سيتعلم الفريق تدريجياً وسيعتاد على حل مشاكل المنتج.
- الإدارة لديها خوف من أن يرتكب الفريق خطأ. : هذا هو الخوف الأساسي في الانتقال إلى رشيقة ، ولكن بدون التغلب عليه ، لن تتمكن من اكتساب القوة الكاملة لفريق سكروم. لا بد أن يرتكب الفريق خطأً ، لأن الجميع مخطئون. لكن الخطأ هو مصدر الخبرة والمهارة. وهي أكثر فائدة عندما يرتكب الفريق خطأً ، لأنه قرر ذلك ، وليس بسبب المعارف التقليدية الخارجية غير الصحيحة. الإيقاع هو الإيقاع: اتخذ بسرعة قرارًا لاختبار الفرضية ؛ التعليقات الواردة أدركوا أنهم سلكوا الطريق الخطأ ؛ رمى القرار. يتم تقليل تكلفة الخطأ بشكل حاد ( قضاء فترة ركض ، وليس ربع / سنة / فترة الإصدار الخاصة بك ) ، مما يسمح لك بالتغلب على الخوف من الخطأ.
العَرَض : ليس لدى أعضاء الفريق وصول مجاني إلى عناصر الفريق. على سبيل المثال ، لا يرى الجميع سباقًا سريعًا أو تراكمًا عامًا ، أو توجد صعوبات في إمكانية تحديث حالته.
ما هو السيئ : يعتمد Scrum على الشفافية ، وتساعد الأدوات على زيادة الشفافية. إذا كان أعضاء الفريق يجدون صعوبة في العمل مع هذه القطع الأثرية ، فإن أعضاء الفريق أنفسهم ليس لديهم شفافية في عمل الفريق ، وبالنسبة للأطراف الأخرى المهتمة ، فإن الوضع سيكون أسوأ: ليس من الواضح من يفعل ماذا ولماذا. ليس من الواضح أين الفريق في طريقه إلى المرمى.
كيفية العلاج : من الضروري تحديد تنسيقات القطع الأثرية في الفريق وجعلها ( يمكنك تكريس هذا بأثر رجعي ) ، ثم وضعها بحيث يكون الفريق مرتاحًا للعمل معها. من الرائع أن تتمكن من إنشاء مساحة منفصلة للفريق ، وهي الظروف التي سيعمل فيها الفريق جنبًا إلى جنب (جنبًا إلى جنب) في نفس الوقت. سيؤدي هذا إلى تقليل النفقات العامة للاتصالات. وفي المساحة المشتركة ، من السهل تصور كل شيء ( اللوحات الورقية والملصقات والعلامات هي أدوات رشيقة مفضلة ) ، والشيء الرئيسي هو أنها مريحة وليست مرهقة للفريق. يجب أن تساعد القطع الأثرية ، ولا تتداخل مع عمل الفريق ، وليس البيروقراطية. التفاعل اللفظي جيد للعمل الجماعي. إذا كانت هناك صعوبات في تنظيم العمل المحلي للفريق ( على سبيل المثال ، الموزع أو البعيد ) ، فأنت بحاجة إلى زيادة تأثير العمل الجماعي والوحدة. على سبيل المثال ، قنوات التواجد بالفيديو واللوحات التفاعلية التفاعلية في عرض مباشر لكل عضو في الفريق ، إلخ.
الخلاصة
في الجزء التالي ، نواصل النظر في أدوار scrum ، وأخيرًا نصل إلى سيد scrum. أذكر بإيجاز ما يجب القيام به مع الأعراض:
- حدد الأعراض التي تنطبق على حالتك.
- من بينها ، اختر الحاد.
- كن على علم بهذا الألم.
- يمكنك التوصل إلى حل جماعي ( يمكنك أخذ الحالات من المقالة كنقطة بداية ).
- نفذ قرارك.
- انتقل إلى الخطوة 1.
شكرا للقراءة ، أود أن أرى "الأعراض" المعروفة لك في التعليقات.
بفضل Sai Kin للتوضيح.
الجزء التالي حول معالج Scrum