อะไรคือบทบาทของตัวติดตามปัญหาแบบดั้งเดิมเมื่อใช้บอร์ด Scrum / Kanban?

จากมุมมองระดับสูงมากสำหรับฉันดูเหมือนว่ามีเครื่องมือการจัดการโครงการ 2 ประเภท:

1. ตัวติดตามปัญหาแบบดั้งเดิมเช่น Fogbugz, JIRA, BugZilla, Trac, Redmine เป็นต้น
2. บอร์ดเสมือนจริง / เครื่องมือการจัดการโครงการที่คล่องตัวเช่น Pivotal Tracker, GreenHopper, AgileZen, Trello เป็นต้น

แน่นอนว่าพวกเขาทับซ้อนกันไม่ทางใดก็ทางหนึ่งเช่นงาน Pivotal Tracker สามารถนำเข้าสู่ JIRA ได้ GreenHopper นั้นถูกนำไปใช้กับฐานปัญหา JIRA เป็นต้น แต่ฉันคิดว่ายังคงเห็นความแตกต่างของการวางแนวระหว่างเครื่องมือทั้งสองประเภทนี้

ดูเหมือนว่าปัญหาการติดตามแบบดั้งเดิมจะถูกนำมาใช้แม้ใน บริษัท อื่น ๆ ที่ดำเนินการจัดการโครงการแบบว่องไว คำถามของฉันคือทำไมพวกเขาทำอย่างนั้น? ฉันรู้สึกว่าเราควรใช้ตัวติดตามปัญหาใน บริษัท ของฉันด้วย แต่เมื่อฉันคิดถึงมันฉันไม่แน่ใจว่าทำไมเราถึงต้องการมัน

ตัวอย่างเช่นการพัฒนา Trello ดูเหมือนว่าจะได้รับการจัดการโดยใช้ Trello เอง (ดูกำแพงเสมือนจริง ) แม้ว่าพวกเขาจะสามารถเข้าถึง Fogbugz ซึ่งเป็นหนึ่งในตัวติดตามปัญหาที่ดีที่สุด ดังนั้นบางทีเราไม่ต้องการเครื่องมือติดตามปัญหาแบบดั้งเดิมเมื่อเราทำงาน 100% อย่างคล่องแคล่วโดยใช้หนึ่งในเครื่องมือ PM ที่คล่องตัว?

มีอย่างน้อยสามวิธีที่ทีมสามารถทำงานได้ เลือกอันที่เหมาะกับทีมของคุณ

1. รายละเอียดกับภาพรวมระดับสูง

ใช้ตัวติดตามปัญหาเพื่อติดตามงานแต่ละงาน ใช้บอร์ดการ์ดเพื่อรักษาภาพรวมของคุณสมบัติหลัก ๆ ไว้เป็นบทสรุปของงานในตัวติดตามปัญหา

2. ข้อบกพร่องกับคุณสมบัติ

ใช้ตัวติดตามปัญหาเพื่อติดตามข้อบกพร่องส่วนบุคคลและการร้องขอการบริการลูกค้า ใช้บอร์ดการ์ดเพื่อติดตามคุณสมบัติใหม่ที่กำลังพัฒนา

3. การจัดส่งซอฟต์แวร์ขั้นสูงเทียบกับการส่งมอบซอฟต์แวร์อย่างต่อเนื่อง

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

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

ฉันคิดว่าคำตอบง่ายๆคือซอฟต์แวร์ติดตามปัญหาแบบดั้งเดิมช่วยให้คุณจัดการงานในมือในขณะที่บอร์ดต่อสู้ช่วยให้คุณติดตามการวิ่งและการเปิดตัวในปัจจุบัน

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

การเปิดเผยอย่างเต็มรูปแบบ: ฉันลำเอียงเล็กน้อยเพราะฉันเป็นผู้จัดการผลิตภัณฑ์ GreenHopper ที่ Atlassian แต่ฉันก็มีส่วนเกี่ยวข้องกับการพัฒนา Agile นอก Atlassian มาเป็นเวลานาน

การมีเพียงเครื่องมือการวางแผนแบบว่องไวหรือเพียงตัวติดตามปัญหาก็เป็นไปได้อย่างแน่นอน ปัญหาคือว่ามันย่อยที่ดีที่สุด จากประสบการณ์ของฉันมันย่อยดีที่สุดเพราะ:

• การวางแผนผลิตภัณฑ์มักจะเกิดขึ้นในระดับมหากาพย์และเรื่องราวในงานในมือ เครื่องมือการวางแผนที่คล่องตัวนั้นยอดเยี่ยมที่นี่
• แต่เมื่อคำพูดเดิมออกไปไม่มีแผนใดที่จะมีชีวิตรอดจากการสัมผัสกับศัตรูเป็นครั้งแรก ในกรณีนี้หลังจากเปิดตัวครั้งแรกของคุณคุณจะต้องจบลงด้วยข้อบกพร่อง (และข้อเสนอแนะอื่น ๆ ) ที่บันทึกโดย QA, ลูกค้า, การสนับสนุน ฯลฯ สิ่งเหล่านี้จำเป็นต้องย้อนกลับไปสู่การวางแผนของคุณ

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

ฉันจะบอกว่าคุณต้องการเครื่องมือทั้งสอง คุณต้องรวมพวกเขาไว้ด้วยไม่เช่นนั้นคุณจะใช้เวลาทั้งหมดในการพยายามทำให้ทั้งสองซิงค์กันอยู่เสมอ

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

เราเรียกใช้ตัวติดตามปัญหาที่ชื่อว่าDoneDoneซึ่งตรงกับ # 3 ในคำตอบของ Joel - บทบาทดั้งเดิมของตัวติดตามบั๊ก อันที่จริงเราสร้างมันขึ้นมาเพราะที่ปรึกษาของเราส่งมอบโค้ดจำนวนมาก (ในรูปแบบของเว็บไซต์) ในช่วงเวลาที่ไม่สม่ำเสมอ

เราได้เผยแพร่ไปยังฐานผู้ใช้ DoneDone ของเราเมื่อเดือนที่แล้วและมีเพียงไม่กี่คนที่ร้องขอ front-end ที่คล้ายกับ Trello และ Sprint.ly สำหรับรหัส / รีลีสต่อเนื่อง ข้อมูลเชิงลึกที่มีประโยชน์อีกอย่างหนึ่งคือผู้คนจำนวนมากใช้ DoneDone ก่อนที่จะเริ่ม QA เพื่อให้พวกเขาต้องการข้อมูลทั้งหมดในที่เดียวเมื่อโครงการของพวกเขา (หรือฟีเจอร์) เคลื่อนที่ระหว่างรอบ

สองเซ็นต์ของฉันคือข้อมูลทั้งหมดที่มีขั้นตอนการทำงานเล็กน้อย ความแตกต่างคือ UI จริงๆและวิธีที่จะช่วยทีมและวิธีการและ / หรือขั้นตอนโครงการพวกเขาอยู่ในเวลา

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

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

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

ฉันไม่รู้ว่ามีคำตอบที่ชัดเจนหรือเปล่าดังนั้นฉันแค่รายงานประสบการณ์ของฉัน ...

เป็นเวลาหลายปีที่ฉันถูกขายในระบบติดตามบั๊กที่แท้จริงเช่น FogBugz, Jira, Trac และอื่น ๆ อย่างไรก็ตามเมื่อเร็ว ๆ นี้ฉันทำงานที่เราเป็น Agile (คล่องแคล่วจริงๆไม่ใช่แค่ทำ Agile) เราไม่มีรายการข้อผิดพลาดในประวัติศาสตร์ที่ยาวนานหรือรายการที่น่าอยู่

ไม่มีประโยชน์สำหรับเครื่องมือเช่นนี้ อะไรก็ตามที่สำคัญที่เราจะต้องได้รับอย่างรวดเร็ว อะไรที่ไม่สำคัญเอาล่ะประเด็นคืออะไร?

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