วิธีสร้างแบบจำลองการเตรียมเนื้อเรื่องสำหรับปัญหาที่ถูกแก้ไขในหลายโครงการ

ใน บริษัท ของเราหลายทีมจะทำงานกับส่วนประกอบต่าง ๆ ของหลายโครงการในเวลาเดียวกัน ตัวอย่างเช่นทีมหนึ่งอาจสร้างซอฟต์แวร์เฉพาะประเภท (หรือฮาร์ดแวร์) สำหรับโครงการบางโครงการทีมอื่นซอฟต์แวร์ประเภทอื่นที่เฉพาะเจาะจง เราใช้โครงการจิราเพื่อโฮสต์ปัญหาสำหรับโครงการเฉพาะและบอร์ดจิราสำหรับการวิ่งสำหรับทีมที่แตกต่างกัน

เราประสบปัญหาในการหลีกเลี่ยงการทำสำเนารหัสในโครงการต่างๆและได้พัฒนาชุดของไลบรารีหลักที่เราใช้ในโครงการเหล่านั้น ในขณะที่ทำงานในโครงการผู้พัฒนาบางคนจะรู้ว่าชิ้นส่วนของรหัสที่พวกเขาเขียนนั้นมีความน่าสนใจมากขึ้นและควรถูกแยกออกเป็นไลบรารีหลักหรือว่ารหัสหลักที่พวกเขาใช้มีข้อบกพร่องต้องการพารามิเตอร์เพิ่มเติมหรือ คุณสมบัติใหม่ ... คุณตั้งชื่อมัน

ดังนั้นพวกเขาจึงสร้างปัญหาไลบรารีหลักที่เข้าสู่ Backlog ของโครงการหลัก ปัญหาทั้งหมดเหล่านี้จะได้รับการทบทวนจัดลำดับความสำคัญและประเมินในการประชุมห้องสมุดหลัก (สัปดาห์ละครั้ง) และจะได้รับการจัดการตามลำดับความสำคัญของพวกเขา (ควบคู่กับปัญหาเฉพาะโครงการ) ในการวิ่งในอนาคต

การจัดลำดับความสำคัญทำได้โดยการเรียงลำดับปัญหาและเราวางsortedเลเบลในปัญหาที่เรียงลำดับแล้ว (เพื่อให้เราสามารถค้นหาสิ่งที่ไม่เรียงลำดับได้) จากนั้นเราวางปัญหาหนึ่งรายการต่อองค์ประกอบหลักด้วยตนเองที่ด้านบนสุดของ backlog เพื่อให้พวกเขาได้รับการจัดการก่อน เมื่อบางทีมนำปัญหาดังกล่าวไปสู่การวิ่งพวกเขาต้องลากรายการอื่นไปที่ด้านบนสุดของงานค้างแทน

นี่เป็นข้อผิดพลาดค่อนข้างง่าย โดยทั่วไปสิ่งที่เรามีคือสถานะปัญหาเพิ่มเติม "เรียงลำดับ" และ "ประเมิน" ระหว่าง "เปิด" และ "อยู่ระหว่างดำเนินการ" การสะท้อนสิ่งนี้ผ่านsortedฉลากและตำแหน่งของพวกเขาในบอร์ดค่อนข้างยุ่งยากและเกิดข้อผิดพลาดได้ง่าย (ตัวอย่างเช่นหากมีใครบางคนย้ายปัญหาในการวิ่งขึ้นและลงสิ่งนี้จะสะท้อนให้เห็นในกระดานหลักเงียบ ๆ เพื่อตรวจสอบลำดับของปัญหาที่ทีมอาจได้ตัดสินใจในการอภิปรายในสัปดาห์ที่ผ่านมา)

ดังนั้นจะเป็นวิธีที่ดีกว่าในการใช้สิ่งนี้

ถ้าคุณต้องการติดตามสิ่งนี้ในจิระฉันจะติดตามมันราวกับว่ามันเป็นงานใหม่

ตัวอย่างเช่น:

สมมติว่าคุณมีเรื่องCORE-75: Foo บาร์

เมื่อมีการตัดสินใจว่าทีมใดจะงานที่พวกเขาจะสามารถสร้างงานใหม่: สนับสนุน-123: Foo บาร์ในหลัก

จากนั้นคุณสามารถป้องกัน CORE-75กับฝ่ายสนับสนุน-123 เมื่อฝ่ายสนับสนุน-123เสร็จแล้วคุณสามารถกลับไปCORE-75 คุณสามารถรวมบทวิจารณ์หรือตรวจสอบรหัสสองครั้ง (โดยทีมที่กำหนดหนึ่งครั้งโดยทีมหลักที่เฉพาะเจาะจงมากขึ้น)

นี่คือสิ่งที่คุณกำลังทำจริง ๆ : พิจารณาไลบรารีหลักเป็นผลิตภัณฑ์ / ลูกค้าของตัวเองอย่าไปครึ่งทาง

วิธีการหนึ่งสำหรับทีมในการสร้างปัญหาใหม่สำหรับการวิ่งของพวกเขาที่เชื่อมโยงกลับไปที่ปัญหาห้องสมุดหลัก มันเหมือนกับว่าคุณกำลังทำภารกิจย่อยสำหรับงาน แต่อยู่บนกระดาน / แบ็คล็อก

อีกวิธีคือการติดตามสิ่งนี้แยกจากภายนอก JIRA ส่งออกงานในมือที่มีอยู่เป็น CSV หรือสเปรดชีตและจัดระเบียบสิ่งนั้น

ด้วยการแยกปัญหาจาก JIRA คุณมีความยืดหยุ่นในการกำหนดลำดับความสำคัญในการประชุมวางแผนและไม่ต้องกังวลกับอัลกอริทึมการเรียงลำดับของ JIRA บนกระดานและคุณไม่ต้องใช้ป้ายกำกับ

ในการประชุมวางแผนการจัดลำดับความสำคัญสำหรับไลบรารีหลักคุณสามารถสร้างรายการสั้น ๆ ของงานให้เสร็จสมบูรณ์สำหรับไลบรารีหลักและใครก็ตามที่รับผิดชอบ / รับผิดชอบไลบรารีหลักสามารถตรวจสอบให้แน่ใจว่างานเหล่านี้เริ่มต้นโดยทีมโครงการที่แตกต่างกันและเสร็จสมบูรณ์

มีมุมมองว่า Core Library ซึ่งมีแค็ปซูลทั่วไปจำนวนมาก แต่ฟังก์ชั่นที่ไม่เกี่ยวข้องเป็น 'สิ่งที่ไม่ดี' (tm)

มีเหตุผลบางประการสำหรับเรื่องนี้

• พวกเขาดึงการอ้างอิงและรหัสที่คุณไม่ต้องการ
• การเปลี่ยนแปลงเหล่านั้นทำให้เกิดการเปลี่ยนแปลงกับแอปพลิเคชันทั้งหมด
• ไม่มี 'เจ้าของ' เดียว

ในกรณีของคุณฉันคิดว่าการแบ่งงานของคุณโดยแอปพลิเคชันการเปลี่ยนแปลงที่เกิดขึ้นเป็นสาเหตุของปัญหา กฎของคอนเวย์ที่ตรงกันข้าม

ฉันคิดว่าทางออกที่ดีที่สุดสำหรับคุณคือการย้ายออกจากการมีไลบรารี 'Core Libraries' ควรมีฟังก์ชั่นที่จัดกลุ่มตามหลักเหตุผล (ขนาดเล็ก) มันควรจะเป็นไปได้ที่จะทำให้พวกเขา เช่น JsonParser, LogWriter เป็นต้นมันไม่ค่อยเหมาะสมที่จะเพิ่มคุณสมบัติใหม่

อย่างไรก็ตามสมมติว่านี่เป็นงานที่ยาวนานและยากลำบากในฐานะที่เป็นวิธีแก้ปัญหารอง กล่าวคือ

ภารกิจ: เพิ่มคุณสมบัติ X เข้ากับผลิตภัณฑ์ Y

Dev: อืมรหัสบางอย่างสำหรับฟีเจอร์ X น่าจะอยู่ใน corelibrary .. ฉันจะวางมันไว้ที่นั่นเป็นส่วนหนึ่งของภารกิจนี้