คำถามติดแท็ก jira

4
วิธีการปิดบั๊กที่ไม่เกี่ยวข้องอีกต่อไป
ขณะนี้ฉันอยู่ในทีมนักพัฒนาเว็บขนาดกลาง เรากำลังใช้Jiraสำหรับการติดตามข้อผิดพลาด เรากำลังทำงานกับผลิตภัณฑ์ที่มีการเปลี่ยนแปลงเค้าโครงบ่อยครั้ง หลายครั้งที่มีการยื่นข้อผิดพลาดเกี่ยวกับข้อผิดพลาดในรูปแบบในเบราว์เซอร์บางส่วน บางครั้งตามเวลาที่เราจัดการกับบั๊กที่มีลำดับความสำคัญต่ำเลย์เอาต์ก็เปลี่ยนไปแล้วและมันก็ไม่เกี่ยวข้องกันอีกต่อไป เราควรปิดมันอย่างไร สิ่งที่ฉันหมายถึงคือวิธีที่เราควรปฏิบัติต่อปัญหาเหล่านี้? ในขณะที่จิราเป็นซอฟต์แวร์ติดตามข้อผิดพลาดที่เราใช้ แต่ฉันสนใจวิธีจัดการกับปัญหาเหล่านี้โดยทั่วไป มันสำคัญหรือไม่ (เราอาจกลับไปที่เค้าโครงในภายหลัง แต่มันไม่น่าเป็นไปได้มาก)

4
นักพัฒนาถูกบล็อกโดยรอรหัสเพื่อรวมจากสาขาอื่นโดยใช้ GitFlow
ทีมของเราเพิ่งเปลี่ยนจาก FogBugz & Kiln / Mercurial เป็น Jira & Stash / Git เรากำลังใช้โมเดล Git Flow สำหรับการแยกสาขาเพิ่มสาขาย่อยย่อยออกจากสาขาคุณลักษณะ (เกี่ยวข้องกับงานย่อย Jira ของคุณสมบัติ Jira) เรากำลังใช้ Stash เพื่อกำหนดผู้ตรวจสอบเมื่อเราสร้างคำขอดึงเพื่อรวมกลับเข้าไปในสาขาหลัก (โดยปกติจะพัฒนา แต่สำหรับงานย่อยกลับเข้าไปในสาขาคุณลักษณะ) ปัญหาที่เราพบคือแม้ว่าจะมีการวางแผนที่ดีที่สุดและพังทลายของกรณีคุณสมบัติเมื่อนักพัฒนาหลายคนทำงานร่วมกันในคุณสมบัติเดียวกันพูดบน front-end และ back-end หากพวกเขากำลังทำงานบนรหัสพึ่งพาซึ่งกันและกัน ในสาขาแยกต่างหากผู้พัฒนารายหนึ่งจะปิดกั้นอีกฝ่าย เราพยายามดึงระหว่างสาขาของกันและกันขณะที่เราพัฒนา นอกจากนี้เรายังพยายามสร้างการรวมสาขาในพื้นที่นักพัฒนาซอฟต์แวร์แต่ละคนสามารถดึงจากหลาย ๆ สาขาเพื่อทดสอบการรวมระบบที่พัฒนาขึ้น ในที่สุดและสิ่งนี้ดูเหมือนว่าจะทำงานได้ดีที่สุดสำหรับเราถึงแม้ว่าจะมีค่าใช้จ่ายเพิ่มขึ้นอีกเล็กน้อยเราได้ลองสร้างสาขาการรวมออกจากสาขาคุณลักษณะทันทีที่ค้างคาว เมื่อสาขาย่อยของภารกิจย่อย (ไม่อยู่ในสาขาฟีเจอร์) พร้อมสำหรับการร้องขอการดึงและการตรวจสอบโค้ดเรายังรวมการเปลี่ยนแปลงที่กำหนดไว้ในสาขาการรวมคุณลักษณะนี้ด้วยตนเอง จากนั้นผู้พัฒนาที่สนใจทุกคนสามารถดึงจากสาขาการรวมเข้ากับสาขาย่อยย่อยอื่น ๆ นี่เป็นการป้องกันไม่ให้ใครก็ตามที่รอสาขาที่พวกเขาต้องพึ่งพาเพื่อตรวจสอบรหัส ฉันรู้ว่านี่ไม่จำเป็นต้องเป็นปัญหา Git - มันเกี่ยวกับการทำงานกับการพึ่งพาซึ่งกันและกันของรหัสในหลายสาขาผสมผสานกับกระบวนการทำงานและวัฒนธรรมของเราเอง หากเราไม่มีนโยบายการตรวจสอบรหัสที่เข้มงวดสำหรับการพัฒนา (สาขาการรวมที่แท้จริง) นักพัฒนา 1 …

3
จัดประเภทงาน / ข้อบกพร่องตามความเสี่ยงของการเปลี่ยนแปลง
โครงการที่ฉันกำลังดำเนินการอยู่ในขณะนี้มีปัญหา: ข้อบกพร่องและงานมักได้รับมอบหมายให้กับผู้ที่ยังใหม่หรือไม่มีประสบการณ์มากเกินไปและงานของพวกเขาก็จบลง ปัญหาคือส่วนต่าง ๆ ของซอฟต์แวร์ของเรานั้นมี "อันตราย" มากกว่าการทำงานอื่น ๆ เนื่องจากปัญหาคุณภาพของรหัส ฉันพยายามต่อสู้กับปัญหานี้โดยการประเมินความเสี่ยงที่เกี่ยวข้องกับงานและใส่ใจกับนักพัฒนาคนใดที่ได้รับมอบหมายงานใด เราใช้ JIRA ดังนั้นฉันจึงเริ่มติดฉลากปัญหาเพื่อติดตามการประมาณนี้ ฉันสังเกตเห็นว่าฉันลงเอยด้วยการใช้หลายเมตริกเพื่อจัดหมวดหมู่ข้อบกพร่อง / งาน: ชัดเจนแค่ไหน / ตรงไปตรงมา เช่นไม่ว่าจะเป็นสิ่งที่จะต้องใช้งานออกแบบจำนวนมากหรือเพียงแค่แก้ไขข้อบกพร่อง UI ที่เรียบง่าย วิธีบำรุงรักษาพื้นที่ได้รับผลกระทบของรหัสคือ มันเป็นพื้นที่ที่ออกแบบมาอย่างดีหรือเป็นก้อนโคลนขนาดใหญ่ ฉันคิดว่าโปรแกรมเท่าไหร่ที่จะได้รับผลกระทบจากการเปลี่ยนแปลงที่จำเป็น ป้ายกำกับของฉันยุ่งเหยิงตั้งแต่ฉันไม่มีความคิดที่ชัดเจนเมื่อฉันเริ่มสิ่งที่หมวดหมู่ที่เป็นไปได้และฉันยังไม่ทำ ฉันกำลังคิดที่จะขอเพิ่มเขตข้อมูลใหม่ (เช่น "ความเสี่ยง") เพื่อให้เราสามารถต้องการการประเมินก่อนที่จะมอบหมายงานให้ใครบางคน มีใครเคยจัดการกับเรื่องแบบนี้มาก่อนหรือไม่?

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

3
คำนวณค่าใช้จ่ายของรหัสที่ไม่ดี
ฉันกำลังมองหาข้อโต้แย้งเพื่อโน้มน้าวให้ฝ่ายบริหารลงทุนในความพยายามในการปรับโครงสร้างใหม่ เราบันทึกการทำงานโดยใช้ Jira และเชื่อมโยงทุก svn-commit กับการเรียก jira ความคิดของฉันคือการทำต่อไปนี้: ตรวจดูพื้นที่ของรหัสด้วยตนเองซึ่งมีการใช้งานที่แย่มาก แต่มักจะใช้: ทั้งจาก User-POV และ Developer-POV (แก้ไขข้อผิดพลาด) รับ svn-commits ซึ่งมี JIRA-Issues กรองปัญหาตามเกณฑ์บางอย่าง (ประเภทปัญหารุ่น prio ฯลฯ ... ) คำนวณเวลา / ความพยายามที่ใช้กับข้อบกพร่องเหล่านี้ ประเมินความพยายามและความเสี่ยงของการปรับโครงสร้างใหม่ แสดงตัวเลขและขอความพยายามแก้ไข คุณคิดยังไงกับสิ่งนี้? การวัดเช่นนี้จะมีประโยชน์และ / หรือน่าเชื่อถือไหม ข้อดีข้อเสียคืออะไร

3
วิธีสร้างแบบจำลองการเตรียมเนื้อเรื่องสำหรับปัญหาที่ถูกแก้ไขในหลายโครงการ
ใน บริษัท ของเราหลายทีมจะทำงานกับส่วนประกอบต่าง ๆ ของหลายโครงการในเวลาเดียวกัน ตัวอย่างเช่นทีมหนึ่งอาจสร้างซอฟต์แวร์เฉพาะประเภท (หรือฮาร์ดแวร์) สำหรับโครงการบางโครงการทีมอื่นซอฟต์แวร์ประเภทอื่นที่เฉพาะเจาะจง เราใช้โครงการจิราเพื่อโฮสต์ปัญหาสำหรับโครงการเฉพาะและบอร์ดจิราสำหรับการวิ่งสำหรับทีมที่แตกต่างกัน เราประสบปัญหาในการหลีกเลี่ยงการทำสำเนารหัสในโครงการต่างๆและได้พัฒนาชุดของไลบรารีหลักที่เราใช้ในโครงการเหล่านั้น ในขณะที่ทำงานในโครงการผู้พัฒนาบางคนจะรู้ว่าชิ้นส่วนของรหัสที่พวกเขาเขียนนั้นมีความน่าสนใจมากขึ้นและควรถูกแยกออกเป็นไลบรารีหลักหรือว่ารหัสหลักที่พวกเขาใช้มีข้อบกพร่องต้องการพารามิเตอร์เพิ่มเติมหรือ คุณสมบัติใหม่ ... คุณตั้งชื่อมัน ดังนั้นพวกเขาจึงสร้างปัญหาไลบรารีหลักที่เข้าสู่ Backlog ของโครงการหลัก ปัญหาทั้งหมดเหล่านี้จะได้รับการทบทวนจัดลำดับความสำคัญและประเมินในการประชุมห้องสมุดหลัก (สัปดาห์ละครั้ง) และจะได้รับการจัดการตามลำดับความสำคัญของพวกเขา (ควบคู่กับปัญหาเฉพาะโครงการ) ในการวิ่งในอนาคต การจัดลำดับความสำคัญทำได้โดยการเรียงลำดับปัญหาและเราวางsortedเลเบลในปัญหาที่เรียงลำดับแล้ว (เพื่อให้เราสามารถค้นหาสิ่งที่ไม่เรียงลำดับได้) จากนั้นเราวางปัญหาหนึ่งรายการต่อองค์ประกอบหลักด้วยตนเองที่ด้านบนสุดของ backlog เพื่อให้พวกเขาได้รับการจัดการก่อน เมื่อบางทีมนำปัญหาดังกล่าวไปสู่การวิ่งพวกเขาต้องลากรายการอื่นไปที่ด้านบนสุดของงานค้างแทน นี่เป็นข้อผิดพลาดค่อนข้างง่าย โดยทั่วไปสิ่งที่เรามีคือสถานะปัญหาเพิ่มเติม "เรียงลำดับ" และ "ประเมิน" ระหว่าง "เปิด" และ "อยู่ระหว่างดำเนินการ" การสะท้อนสิ่งนี้ผ่านsortedฉลากและตำแหน่งของพวกเขาในบอร์ดค่อนข้างยุ่งยากและเกิดข้อผิดพลาดได้ง่าย (ตัวอย่างเช่นหากมีใครบางคนย้ายปัญหาในการวิ่งขึ้นและลงสิ่งนี้จะสะท้อนให้เห็นในกระดานหลักเงียบ ๆ เพื่อตรวจสอบลำดับของปัญหาที่ทีมอาจได้ตัดสินใจในการอภิปรายในสัปดาห์ที่ผ่านมา) ดังนั้นจะเป็นวิธีที่ดีกว่าในการใช้สิ่งนี้
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.