มีการศึกษาเกี่ยวกับข้อเสียของการใช้ระบบติดตามปัญหาหรือไม่ [ปิด]

ฉันไม่ชอบระบบติดตามปัญหาเนื่องจาก:

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

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

ฉันอยู่คนเดียวที่นี่ไหม มีการศึกษา (หนังสือ / บทความ / อะไรก็ตาม) เกี่ยวกับข้อเสียของการใช้ระบบติดตามปัญหาหรือไม่

ใช้เวลานานเกินไปในการอธิบายปัญหาที่เกิดขึ้น สิ่งนี้ไม่สนับสนุนการใช้งาน

หากคุณไม่สามารถอธิบายจุดบกพร่องได้คุณจะเริ่มแก้ไขได้อย่างไร

คุณสร้างสถานที่เก็บข้อบกพร่องของคุณ และหากมีสถานที่สำหรับพวกเขาคนมักจะไม่สนใจมากเกินไปเกี่ยวกับการแก้ไขข้อผิดพลาดทำให้พวกเขาสามารถวางไว้ที่นั่นเพื่อสักวันหนึ่งบางคนสามารถแก้ไขได้ (หรือไม่)

นั่นเป็นปัญหากับทีมของคุณไม่ใช่กับซอฟต์แวร์

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

อีกครั้งที่คุณอธิบายปัญหากับทีมของคุณ

จุดของซอฟต์แวร์การติดตามข้อผิดพลาดไม่ได้ช่วยให้คุณกระตุ้นทีมของคุณในการแก้ไขข้อบกพร่อง แต่ก็เพื่อเก็บบันทึกเพื่อให้คุณสามารถติดตามสาเหตุของข้อบกพร่องและหยุดพวกเขาเกิดขึ้นอีกครั้ง ไม่มีซอฟต์แวร์ใดที่สามารถทดแทนการจัดการที่ดีได้

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

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

1. ควรแก้ไขข้อบกพร่องแบบเปิดข้อใดก่อน (หมายเหตุ: ในโครงการที่มีเหตุผลควรได้รับการตัดสินโดยเจ้าของผลิตภัณฑ์และ / หรือการจัดการไม่ใช่โดยนักพัฒนาซึ่งพวกเขาจะต้องตระหนักถึงข้อผิดพลาดที่เปิดอยู่ทั้งหมดก่อน!)
2. เรามีแมลงเปิดกี่ตัวและมีความรุนแรงเท่าใด
3. ข้อใดควรแก้ไขก่อนที่เราจะพร้อมปล่อย
4. เวลาในการวางแผนสำหรับการแก้ไขเหล่านี้มักนำไปสู่: ใช้เวลานานเท่าใดในการแก้ไขข้อบกพร่องโดยเฉลี่ย
5. มีการรายงานข้อบกพร่องจำนวนเท่าใดโดยไคลเอนต์ในรุ่นล่าสุด?
6. ใครเป็นผู้แก้ไขข้อผิดพลาดนี้และเมื่อใดและการเปลี่ยนแปลง (รหัส / การกำหนดค่า / ข้อมูล) การแก้ไขเกี่ยวข้องกับอะไรบ้าง
7. มีการแก้ไขข้อผิดพลาดใดบ้างในรุ่นที่เราเพิ่งจะเผยแพร่
8. ...

คุณสามารถตอบคำถามดังกล่าว[อัพเดต] ซ้ำ ๆ ได้อย่างน่าเชื่อถือและมีประสิทธิภาพ [/ อัปเดต]ตามบันทึกย่อของคุณหรือไม่

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

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

บทความ / การศึกษาบางอย่างที่คุณอาจสนใจรวมถึงบทความนี้ที่กล่าวถึงการใช้งาน Jira ของ Zend และการศึกษาภาษาฝรั่งเศสนี้เกี่ยวกับการใช้ระบบติดตามบั๊ก

อาจมีการศึกษา แต่ยิ่งดีกว่าเป็นประสบการณ์ที่ได้รับยากของคนในสาขา ระบบติดตามปัญหาส่วนใหญ่ประสบจากกระบวนการที่ผลักดันการออกแบบ ตัวติดตามปัญหามักจะต้องสนับสนุนผู้ใช้ 2 ระดับที่แตกต่างกัน:

1. ทีมพัฒนา
2. ผู้ใช้ของระบบ

Cal Henderson (ชื่อเดิมของ Flickr) มีการโพสต์ที่ยอดเยี่ยมในการออกแบบตัวติดตามปัญหาจำนวนมากและสาเหตุที่เขาชอบ GitHub tracker tracker (เช่นเดียวกับฉัน) นอกจากนี้ Garrett Dimon ยังครอบคลุมการออกแบบSifterและแสดงวิธีที่จะทำให้กระบวนการง่ายขึ้นสำหรับการติดตามปัญหาที่มีประสิทธิภาพมากขึ้นติดตามประเด็นปัญหาที่มีประสิทธิภาพฉันได้นำแนวคิดบางประการจากทั้งสองระบบมาปรับใช้เพื่อช่วยให้ขั้นตอนการติดตามปัญหาของทีมของฉันง่ายขึ้น

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

เราไม่ค่อยต้องการประวัติข้อผิดพลาด บางครั้งบางคนอาจพูดถึงอาการของข้อบกพร่องและเราอาจทำการค้นหาเพื่อดูว่ามันเกี่ยวข้องกับปัญหาที่เราจัดการอยู่แล้วหรือไม่ แต่นั่นหายาก

TL; DRมุ่งเน้นไปที่กระบวนการของคุณเลือกเครื่องมือง่าย ๆ และแก้ไขปัญหาเมื่อเกิดขึ้น

ฆ่าแมลงที่สำคัญทันทีที่ปรากฏ

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

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

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

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

• จริง ๆ แล้วเมื่อคุณถามเกี่ยวกับ f2f มันรู้สึกเหมือนคุณ (ผิด) ใช้ติดตามเพื่อหารือเกี่ยวกับสิ่งต่าง ๆ - นี่ไม่ใช่จุดประสงค์ของมัน ที่จะคิดใช้งานที่ต้องการเพียงแค่การสะกดชื่อของมันช้าและชัดเจน: ระบบการติดตามปัญหา

รายการข้อผิดพลาดได้รับนาน

จากประสบการณ์ของฉันข้างต้นเป็นข้อได้เปรียบไม่ใช่ปัญหา

ด้วยนักพัฒนารายการบั๊กที่มีความยาวสามารถตั้งค่าคิวและวางแผนแก้ไขได้ล่วงหน้า นี่คือผลผลิตที่ได้รับ สำหรับฉันแล้วนี่คือนิพพานเมื่อฉันมีคิวที่จะทำงานด้วย ข้อผิดพลาดครั้งแรก - แก้ไข - ทำข้อผิดพลาดที่สอง - แก้ไข - ทำข้อผิดพลาดต่อไป - แก้ไข - ทำ ฯลฯ เป็นต้นไม่มีการหยุดชะงักโง่ไม่มีการรบกวนเจ็บปวดกับโอ้ดังที่มีประสิทธิภาพการสนทนา F2F, การไหลบริสุทธิ์

• ฉันจำได้เพียงกรณีเดียวเมื่อรายการบั๊กที่ยาวนานเป็นปัญหา มันเกิดขึ้นเมื่อคนงี่เง่าบางคนที่ผู้บริหารระดับสูงตัดสินใจนโยบายที่บังคับให้นักพัฒนาเลือกข้อผิดพลาดต่อไปจากกอง 50-100 เกือบทุกวัน เสียอะไร เราใช้เวลาสองสามเดือนในการเจ็บปวดจนกว่าเราจะรู้วิธีที่จะขยายเรื่องนี้บนหัวของเขาและทำให้มันคงที่
  บางเวลาหลังจากที่เราจัดการเพื่อสร้างกระบวนการทำงานที่สะดวกสบายเราค้นพบว่า "ค้างที่ไม่มีที่สิ้นสุด" ของเราว่างเปล่าอย่างน่าอัศจรรย์