لوحات كانبان / سكروم [مغلقة]

Question

أشعر بالفضول لمعرفة ما يستخدمه الآخرون للوحات Kanban/Scrum الفعلية في شركاتهم.أقدر أنه بسبب معلومات العمل الحساسة، قد لا تتمكن من تقديم صورة للوحة.أنا أبحث لمعرفة ذلك كيف تبدو اللوحة الخاصة بك, ، و كيفية تنظيم قصص المستخدم والمهام أثناء تحركهم خلال سباق السرعة/التكرار النموذجي؟

عادةً ما عملت في أماكن تنظم اللوحة على النحو التالي مع كل منها

User Story   | Todo                   | In Progress  | Ready for QA     | Done   |
UC-001       | Domain Object, Service | DAO(Bob)     |                  |        |
UC-002       | Payment UI Screen      |              | Payment Srv (Don)|        |
UC-003       |                        |              | UC-003           |        |
             |                        |              |                  | UC-004 |
             |                        |              |                  | UC-005 |

لذلك لتلخيص:

• هناك مهمة لـ UC-001 قيد التنفيذ بواسطة أحد أعضاء الفريق (بوب).توجد قائمة بالمهام التي يتعين على الأشخاص الآخرين إنجازها في عمود "المهام"، ولكن يمكن التقاطها بواسطة عضو آخر في الفريق يقوم بالتنسيق مع بوب لإنجاز العمل.
• بالنسبة لـ UC-002، تم إكمال مهمة خدمة الدفع وتم إكمال أداة اختبار تلقائية لضمان الجودة مما يسمح لهم باختبار الخدمة بدون واجهة مستخدم.إذا فشل الاختبار، فسيتم ظهور خطأ ونقله مع مهمة خدمة الدفع مرة أخرى إلى مرحلة ضمان الجودة
• تم إكمال جميع المهام الخاصة بـ UC-003 وتم نقلها إلى جاهز لضمان الجودة.
• اكتملت جميع المهام الخاصة بـ Uc-004 وUC-005، لذا تم نقل قصة المستخدم إلى "تم".

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

Answer 1

نحن نستخدم شيئًا مستوحى من المشهور سكروم و XP من الخنادق من Henrik Kniberg، يتم تكييف الأعمدة وفقًا للسياق (غالبًا:المهام قيد التنفيذ، ليتم اختبارها، وإنجازها):

نص بديل http://blog.realcoderscoding.com/wp-content/uploads/2008/09/hk.png

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

تسمح هذه الممارسات باكتشاف الروائح بصريًا، على سبيل المثال:

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

يعمل بشكل رائع.

إذا كنت تبحث عن المزيد من الأشياء "الموجهة نحو كانبان"، فربما يمكنك إلقاء نظرة عليها كانبان مقابل سكروم, يوم واحد في كانبان لاند و كانبان وسكريم - دليل عملي من نفس هنريك كنيبرج.أشياء عظيمة جدا.

وللحصول على المزيد من الصور، قم بتجربة Google Images سكروم + مجلس, كانبان, سكرومبان, سكروم + كانبان.

Answer 2

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

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

تعرض اللوحة أيضًا تحميل المطورين والمختبرين وفئات الخدمات عبر الترميز اللوني.

محدث.لدينا الآن عدة فرق صغيرة ونستخدم لوحة واحدة لتتبع تقدم جميع الفرق http://www.targetprocess.com/3

Answer 3

سكروم / القصة المصورة للبرمجة المتطرفة.

http://www.flickr.com/photos/dafydd_ll_rees/4138686549/

يظهر العمل في العمود الثاني من اليسار، ويتقدم عبر اللوحة عبر مراحل مختلفة من الاكتمال.

أسماء الأعمدة: لم تبدأ، بدأت للتو، في منتصف الطريق، أوشكت على الانتهاء، جاهزة للعرض (تم اجتياز ضمان الجودة)

الصف الأول مخصص خصيصًا لإصلاح الأخطاء - مثل الأولوية الثابتة لإزالة الأخطاء.

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

Answer 4

أقترح عليك إلقاء نظرة على لوحة Eylean. http://www.eylean.com/?utm_source=geffort&utm_medium=content&utm_campaign=geffortيمكن أن يناسب جميع احتياجاتك بسبب الواجهة البديهية والإحصائيات ولوحة القيادة.كما أنه يناسب أي عملية والأهم من ذلك أنه سهل الاستخدام للغاية.تتيح لك هذه اللوحة تمثيل عدة مشاريع على لوحة واحدة باستخدام الصفوف.قد تكون كافة الصفوف مرئية في وقت واحد أو يمكنك إزالة الصفوف المحددة من النطاق. قد يكون الحل الآخر هو تجميع المهام وتصفيتها حسب الفئات - ثم يمكن تمثيل جميع المهام في لوحة وصف واحد، ولكن يتم إرفاقها بفئات مختلفة.

Answer 5

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

ومع ذلك، إليك ما فعلناه في فريقي السابق، وهو جزء من جهد مطور يزيد عن 300 مطور كان جديدًا نسبيًا على Agile وScum:

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

Not Started
Under Development
Dev Done 
In QA
Complete ("Done Done")

ومربع في الزاوية ل Blocked.

تمثل المذكرة اللاحقة كل قصة.

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

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

Answer 6

أنا مهتم جدًا بـ Lean/Kanban وقد قمنا بتكرار عمليتنا لفترة من الوقت، في البداية من خلال سير عمل مخصص في JIRA، ولكن هذا ليس سهلاً تمامًا نظرًا لتعقيد المسؤول في إصدار المؤسسة.لقد قمنا الآن بتوسيع استخدامنا للسبورة البيضاء وقررنا تكرار عمليتنا باستخدام السبورة البيضاء لفترة من الوقت قبل إعادة ترميزها في JIRA.فيما يلي مثال على تخطيطنا:

• نحن 6 مطورين
• عندما تكون القصة قيد التطوير، تكون على مكتب المطور.وبالمثل مع المراجعة، وQA'd، وما إلى ذلك.وهذا يعني أن كل بطاقة على اللوحة تمثل عنصرًا قابلاً للتنفيذ، وتوفر أيضًا لقطة دقيقة بشكل لائق لتقدم التكرار.القاعدة هي أنه في الظروف الاستثنائية فقط يكون لديك أكثر من بطاقة واحدة على مكتبك.
• لقد اتفقنا على عدم تجميع أكثر من بطاقتين في عمود "في انتظار المراجعة".وهذا يحافظ على درجة من "التدفق".

Backlog   | Awaiting Dev   | Awaiting Review   | Awaiting Design  | Awaiting Deployment | Awaiting QA | Done |
Story11   |    Story2      |    Story9         |     Story 6      |   Story1            |    Story9   |
Story3    |    Story7      |                   |                  |                     |    Story12  |
Story8    |    Story10     |                   |                  |                     |             |
          |                |                   |                  |                     |             |
          |                |                   |                  |                     |             |

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

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

امل ان يساعد!

Answer 7

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

| (Sprint) Backlog | In Progress | Done |

نحاول قدر الإمكان أن يكون لدينا ملصق واحد لتمثيل كل من أنشطة التطوير وضمان الجودة للقصة.

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

أدى ذلك إلى التكرار الثاني لهيكل مجلس الإدارة لمشروع آخر وهو:

| (Sprint) Backlog | In Progress | Ready for Test | Done |

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

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

| (Sprint) Backlog | Dev in Progress | Dev Done | QA in Progress | Done |

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

Answer 8

يتم تقسيم السبورة البيضاء لدينا إلى هذه الأعمدة:

القصة، لم تبدأ، Req/Des/Dev*، مراجعة الزملاء، ضمان الجودة، تم

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

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

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

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

* المتطلبات / التصميم / التطوير

Answer 9

تبدو صورتنا متشابهة إلى حد ما.كل مطور لديه عمود ولدينا صفوف لـ "تم"، و"قيد الاختبار"، و"العمل قيد التقدم"، و"Backlog".

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

أنا شخصياً أرى أن النظام ناقص..

• سيصبح تحريك الملصقات يدويًا أمرًا مؤلمًا بعد فترة.يقوم فريق ضمان الجودة لدينا في الغالب بإدارة عملية نقل التذاكر - وهو جهد مستمر لإبقائها متزامنة مع TFS.
• لا يمكن تحريك الملصقات اللاصقة إلا عدة مرات قبل أن تصبح غير لاصقة بعد الآن.إذا تم إرجاع تذكرة من الاختبار ووضعها في "قيد التقدم" ثم إعادتها مرة أخرى إلى الاختبار، وما إلى ذلك، وما إلى ذلك... فلن يستغرق الأمر الكثير حتى ينتهي بها الأمر على الأرض.
• في بعض الأحيان، يكون الحجم الهائل للملاحظات هائلاً.يجب أن تكون الملاحظات مكدسة حتى تكون مرئية عن بعد - فنحن نضعها في طبقات بحيث يمكننا رؤية المعرف الفريد لكل ملاحظة (بقدر ما نستطيع)... ولكن بعد ذلك يكون لديك مجموعة من 10 ملاحظات وتحتاج إلى الحصول على الخامس من المكدس وأنت تساهم بسرعة في تقليل الالتصاق الذي سينتهي بالملاحظات الموجودة على الأرض.
• عندما تنتهي التذاكر على الأرض، يكون من المزعج إلى حدٍ ما معرفة المكان الذي يجب أن تذهب إليه.هل كانت تلك تذكرة المطور أ؟أو ب؟وهل كان في الاختبار؟أم تم ذلك؟دعنا نعود إلى TFS، ونبحث عن تلك التذاكر ثم ننقل الملصقات وفقًا لذلك.

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

http://www.telerik.com/community/labs/tfs-work-item-manager-and-tfs-project-dashboard.aspx

Answer 10

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

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

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

Answer 11

لقد ذهبنا مع هيكل مجلس الإدارة التالي في شركتنا.

Backlog | Next sprint |      Current sprint         | Done
                         Buffer    |     Working

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

نحن نستخدم KanbanTool (Kanbantool.com) لتصور سير العمل لدينا وإدارة المشاريع.إنها حقًا بديهية وسهلة الاستخدام.لقد تحسنت اتصالات فريقنا بشكل كبير.