فرق سكروم مقابل فرق المنظمة تقليديا [مغلقة]

Question

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

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

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

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