Redmine แนวทางปฏิบัติที่ดีที่สุด [ปิด]

คุณใช้เคล็ดลับและ "มาตรฐาน" อะไรในกระบวนการจัดการโครงการ Redmine ของคุณ

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

คุณปล่อยให้ปัญหาและการอัปเดตส่งอีเมลไปที่ Redmine หรือไม่? คุณใช้เว็บบอร์ดหรือไม่? คุณใช้ที่เก็บ SVN หรือไม่ คุณใช้ Mylyn ใน eclipse เพื่อทำงานรายการงานหรือไม่?

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

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

นี่คือวิธีที่ฉันใช้ Redmine เพื่อให้หัวของฉันตรง (เท่าที่เป็นไปได้) ผู้ใช้ของฉันไม่สบายใจและหวังว่าจะป้องกันไม่ให้พนักงานใหม่จับมือกันมากเกินไปในอนาคต

• ฉันจะใช้โค่นล้มสำหรับการควบคุมแหล่งที่มากับ TortoiseSVN และชื่อ aptly ปลั๊กอินเต่า-Redmine การรีเฟรชที่เก็บในโครงการ Redmine หลังจากการคอมมิตเชื่อมโยงปัญหาซึ่งแสดงการแก้ไขในปัญหาและอัปเดตผู้มีส่วนได้ส่วนเสียของฉันผ่านการแจ้งเตือนทางอีเมล
• ฉันถือว่าคำอธิบายโครงการเป็นวิธีการสื่อสารวัตถุประสงค์ขอบเขตและขั้นตอนของวงจรชีวิตของโครงการกับผู้ที่ไม่เกี่ยวข้อง ด้วยวิธีนี้ผู้ใช้ของฉันจะรู้ว่าฉันมีอะไรอยู่ในจานของฉันและยังมีอะไรอยู่ในบุฟเฟ่ต์ที่ฉันจ้องมองจากระยะไกล
• ฉันใช้ชื่อบทบาทเฉพาะสำหรับชุดสิทธิ์ของฉันที่ระบุมากกว่าชุดสิทธิ์ - อีกครั้งเป็นเอกสารประกอบ บทบาทของฉันมีดังต่อไปนี้: Project Manager, Project Team Member, Owner, Primary User, Secondary User, Observer, Overlord (สำหรับหัวหน้าของฉัน ... ทั้งสนุกและถูกต้องอย่างปฏิเสธไม่ได้)
• ฉันใช้วิกิพีเดียและเอกสารในการจัดทำเอกสารขึ้นอยู่กับว่าฉันคิดว่าเหมาะสม
• เวอร์ชันนั้นค่อนข้างไร้ประโยชน์สำหรับฉันดังนั้นแทนที่จะใช้เวอร์ชันนั้นสำหรับการเผยแพร่ที่วางแผนไว้ฉันใช้มันเพื่อจัดกลุ่มปัญหาที่เกี่ยวข้องเป็น sprints
• ฉันใช้ปลั๊กอิน Stuff-To-Do ที่ยอดเยี่ยมของ Eric Davis เพื่อจัดระเบียบ / จัดระเบียบ sprint ที่กล่าวมาข้างต้นอีกครั้งก่อนที่จะแก้ไขเวอร์ชันเป้าหมายจำนวนมากในปัญหาของฉัน นอกจากนี้ยังช่วยให้ผู้มีส่วนได้ส่วนเสียของฉันรู้ว่าฉันกำลังทำอะไรและฉันจัดลำดับความสำคัญของผลประโยชน์ของพวกเขาอย่างไร (ดีขึ้นหรือแย่ลง)
• เพื่อส่งเสริมการโต้ตอบกับผู้ใช้ฉันได้เพิ่มลิงก์ไปยังโครงการ Redmine ลงในเมนูวิธีใช้ของแอปพลิเคชันของฉัน ช่อง "เกี่ยวกับ" ยังมีลิงก์ไปยังโครงการ Redmine

แผนการในอนาคต

• ฉันหวังว่าเมื่อถึงจุดหนึ่งจะเสร็จสิ้นส่วนขยาย Visual Studio สำหรับการรวม Redmine
• สร้างไลบรารีโค้ดเพื่อจับคู่แอปพลิเคชันของฉันกับโครงการ Redmine โดยอัตโนมัติ: การส่งข้อผิดพลาดโดยอัตโนมัติแจ้งเตือนผู้มีส่วนได้ส่วนเสียที่สมัครสมาชิกจากถาดระบบเมนูวิธีใช้แบบโต้ตอบที่นำกลับมาใช้ใหม่ได้ซึ่งขับเคลื่อนโดย REST API ของ Redmine เป็นต้น (อาจทำเอกสารบางส่วนโดยอัตโนมัติด้วย Wiki?)

ฉันเป็นนักพัฒนาเว็บอิสระ Ruby และ Redmine ที่ทำธุรกิจพัฒนาของ (ฉัน) คนหนึ่ง ดังนั้น Redmine ของฉันจึงถูกตั้งค่าให้มีน้ำหนักเบาและเน้นลูกค้า Redmine ของฉันยังทำหน้าที่สองอย่างในการโฮสต์โครงการโอเพ่นซอร์สของฉัน

ฉันอนุญาตให้ส่งปัญหาและการอัปเดตใหม่ ๆ ทางอีเมลและใช้ได้ดีกับผู้ใช้ที่เชื่อมต่ออีเมล (หรือผู้ที่ใช้ iPhone เป็นประจำ)

ฉันใช้มุมมองที่เก็บกับที่เก็บ git และใช้งานได้ดี ทุกครั้งที่เช็คอินฉันอ้างถึงปัญหากับ #nnn ดังนั้นหน้าปัญหาจริงจะแสดงความมุ่งมั่นทั้งหมดที่จะใช้คุณลักษณะนี้

ฉันพบว่าฟอรัมไม่ได้ใช้งาน ฉันคิดว่าถ้ามีการรวมอีเมลเข้าด้วยกันก็จะมีประโยชน์มากกว่านี้

เราพบแนวทางปฏิบัติต่อไปนี้ที่มีประโยชน์:

1) ซ่อนตัวติดตาม "ปัญหา" และ "การสนับสนุน" และบันทึกทุกอย่างเป็นข้อบกพร่อง :

• ประหยัดเวลาสำหรับนักพัฒนาผู้ทดสอบการจัดการ
• หากมีการเรียกเก็บเงินกิจกรรมบางอย่างเป็น "พิเศษ" หรือ "คุณลักษณะใหม่" หรืออย่างอื่นจะมีการจัดการประชุมด่วนเพื่อประเมิน

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

3) ฟังก์ชั่น "บันทึก" ในแท็บ "ปัญหา": อีกหนึ่งตัวช่วยประหยัดเวลาได้มากฉันมีคำถามต่างๆที่บันทึกไว้สำหรับงานรายงานประจำวันจำนวนมากและนั่นคือทั้งหมดที่ฉันต้องการ

4) การรวมเวอร์ชันเช่นการใช้ "# 123" ในความคิดเห็นจะสร้างลิงก์ไปยังปัญหาที่เกี่ยวข้อง: ฉลาด!

เราใช้ Redmine อย่างกว้างขวางในระบบของเรา เราได้จัดตั้งโครงการ "การขาย" สำหรับทีมขายของเราเพื่อใช้เป็น CRM เรามีฟิลด์ที่กำหนดเองจำนวนมากในโปรเจ็กต์นี้และแทนที่ SugarCRM ที่เราเคยใช้มาก่อน

ภายในระบบของเราเรามีโครงการสำหรับซอฟต์แวร์เซิร์ฟเวอร์และไคลเอ็นต์ โปรเจ็กต์เซิร์ฟเวอร์แบ่งออกเป็นโมดูลย่อยตามวิธีที่ฉันจัดโครงสร้างระบบและที่เก็บย่อยเนื่องจาก Redmine ชอบ repo แยกต่อโปรเจ็กต์

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

เราเพิ่งเริ่มใช้เอกสารสำหรับวาระการประชุม / รายงานการประชุม เราใช้เวอร์ชันเพื่อจัดกลุ่มเป็นรุ่นต่างๆทั้งบนไคลเอนต์และเซิร์ฟเวอร์

เพื่อพยายามใช้ปลั๊กอิน Redmine Time Tracker เพื่อติดตามเวลา แต่ฉันมักจะลืมคลิกเริ่มหรือสิ้นสุด เราได้รับอีเมลรายวันเกี่ยวกับปัญหาที่ไม่ได้รับการติดต่อมาระยะหนึ่ง (ฉันคิดว่า Redmine Whining) และมีวันครบกำหนดในอดีตหรืออนาคตอันใกล้ (การแจ้งเตือนขั้นสูง)

อีเมลสนับสนุนจะส่งตรงไปยังโครงการสนับสนุนของเราและหากการนำเข้าอีเมลมีประสิทธิภาพมากขึ้นเล็กน้อย (บางครั้งก็ไม่ได้สร้างตั๋วใหม่อย่างถูกต้องหากรวม Project: line ไว้ในอีเมล) เราจะมีการสอบถามทางเว็บไซต์โดยอัตโนมัติเพื่อสร้างตั๋วการขาย . ตามที่เป็นอยู่เราต้องตรวจสอบตั๋ว Support และย้ายไปที่ Sales ถ้ามี

สิ่งที่ฉันอยากจะทำได้:

• มีความสัมพันธ์ระหว่างระบบของเราและ redmine เพื่อให้ตั๋วสามารถเชื่อมโยงกับผู้ใช้หรือ บริษัท ในระบบของเรา นอกจากนี้เพื่อให้เราสามารถสร้าง บริษัท ใหม่จากตั๋วขายในจุดที่เกี่ยวข้อง แค่นี้ฉันก็ต้องทำงานบางอย่าง
• มีความสัมพันธ์ระหว่างซอฟต์แวร์ติดตามข้อผิดพลาดของเรา (ทหารยาม) และ redmine เพื่อให้ข้อผิดพลาดของเซิร์ฟเวอร์สร้างตั๋ว redmine อีกครั้งแก้ไขได้ด้วยเทคโนโลยีปัจจุบัน
• มีไคลเอนต์เดสก์ท็อปเพื่อ redmine เซิร์ฟเวอร์อยู่ใน LAN ของเรา แต่การมีวิธีที่ยืดหยุ่นกว่าในการเข้าถึงข้อมูลนอกเหนือจากหน้าเว็บจะดีมาก ไม่ใช่ว่ามีอะไรที่ฉันทำไม่ได้ในอินเทอร์เฟซเว็บ redmine แต่บางอย่างเช่น Things.app นั้นดีกว่ามากในการทำงาน
• มีเอกสารสนับสนุนของเราทั้งหมดภายใน redmine จากนั้นสร้างขึ้นบนเซิร์ฟเวอร์สาธารณะ ด้วยวิธีนี้เจ้าหน้าที่ฝ่ายสนับสนุนของเราสามารถดูแลรักษาเอกสารแก้ไขได้อย่างดีและปรับใช้การเปลี่ยนแปลงกับ doc-server

Redmine เป็นสิ่งที่ยอดเยี่ยมสำหรับเราจนถึงตอนนี้ เราใช้เป็นคิวการจัดลำดับความสำคัญในการออกตั๋วแบบหลายผู้เช่า / แบบคล่องตัวและได้เชื่อมโยงกับ SVN ด้วย โดยเฉพาะอย่างยิ่ง:

• การติดตั้ง / บำรุงรักษาผ่าน SVN เป็นเรื่องง่าย (ฉันได้ย้ายเราจาก 1.1 เป็น 1.2 เป็น 1.3 เป็น 1.4 ผ่านการใช้svn switch https//.../branches/1.3-stable .คำสั่งตามด้วยrake migrateคำสั่งที่จำเป็นต้องติดตั้งอัญมณีเป็นครั้งคราวเท่านั้น)
• การสำรองฐานข้อมูลและไฟล์ที่จัดเก็บเป็นการเรียกใช้สคริปต์แบบบรรทัดเดียว
• เราชอบปลั๊กอินTime TrackerและSpent Time ฉันจะฆ่าเวลาในการติดตามไคลเอ็นต์ไขมันของ MacOS X สำหรับผู้ใช้สำนักงานของเรา แต่นั่นก็อยู่ข้างจุด :)
• เราไม่ได้ใช้ฟอรัมมากนัก แต่ใช้กิจกรรมและแผนงานอย่างมาก การผูกปัญหากับเวอร์ชันที่เฉพาะเจาะจงเป็นสิ่งที่มาจากสวรรค์
• นอกจากนี้เรายังมีความแตกต่างของไคลเอ็นต์ / เซิร์ฟเวอร์ แต่ใช้เวอร์ชันเป้าหมายเพื่อผูกตั๋วเพื่อระบุว่าจะไปที่ใด (และสิ้นสุดการเปิดตัวไคลเอ็นต์ถัดไป / การปล่อยเซิร์ฟเวอร์ถัดไป) เพื่อแยกความแตกต่างระหว่างในขณะที่ทำงานอยู่
• เราผสมคำเปรียบเปรยสำหรับสถานะ - เราใช้รายการของเราก่อนจัดกลุ่มตามสิ่งเหล่านี้ ("ทันที", "ถูกปฏิเสธ", "ถูกบล็อก", "กำลังทำงาน", "บนดาดฟ้า" "รายการ", "กำลังรอการสร้าง", "ออกเพื่อทดสอบ "," ตรวจสอบแล้ว "," เผยแพร่สู่การผลิต "," ปิด "," ยกเลิก)
• จากนั้นภายในแต่ละกลุ่มด้านบนเราจะมีรายการลำดับความสำคัญที่จัดเรียงไว้ดังนี้ ("ทันที" "จัดลำดับความสำคัญฉัน" "การออกแบบและขนาดฉัน" "P1" … "P5", "P-Watch List") สิ่งนี้รวมถึงข้างต้นช่วยให้ขั้นตอนการทำงานง่ายขึ้นจากประเด็นปัญหา
• สำหรับรายการปัญหาพื้นฐานเราจะจัดเรียงตาม "ลำดับความสำคัญ" "งานหลัก" จากนั้น "วันที่อัปเดต" - ต้องการรายการตรงกลางเพื่อให้การเยื้อง Redmine ควรมีงานย่อยในการจัดกลุ่มเดียวกัน
• เราใช้ checkin commits เพื่อผูกข้อผูกมัดกับปัญหา (เช่นsvn ci -m "This fixes #1733 @2.5, holy smoke what a weird foo bug. It is now bacon and unicorns.") - และย้ายปัญหานั้นไปที่ "Waiting For Build" (ซึ่งเคยเป็น "แก้ไขแล้ว" แต่ฉันเบื่อที่จะอธิบายว่า "แก้ไขแล้ว" ไม่ได้หมายความว่ามีคนทำได้ คาดว่าจะได้เห็นการเปิดตัวในตอนนี้)

ฉันคิดว่าฉันจะต้องไปตรวจสอบปลั๊กอิน Redmine-stuff-to-do +1 คำถาม

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

สถานะ - เมื่อฉันพบปัญหาซอฟต์แวร์หรือฮาร์ดแวร์สถานะจะเป็น "ใหม่" - เมื่อนักพัฒนาซอฟต์แวร์ / ฮาร์ดแวร์ของฉันเห็นปัญหานี้และกำลังดำเนินการแก้ไขอยู่พวกเขาจะเปลี่ยนสถานะเป็น "อยู่ระหว่างดำเนินการ" พวกเขาสามารถใช้% เสร็จถ้าพวกเขาต้องการตั้งแต่ 0-50 ฉันให้พวกเขาตั้งค่า% เสร็จเป็น 50 เมื่อพวกเขารู้สึกว่าพวกเขาได้รับการแก้ไขปัญหา - ฉันพิจารณาว่าปัญหาได้รับการแก้ไขหรือไม่และฉันเปลี่ยนสถานะเป็น "แก้ไขแล้ว" และ% เสร็จสิ้นเป็น 100% สิ่งนี้ช่วยให้ฉันกรองปัญหา <หรือเท่ากับ 50% เพื่อค้นหาปัญหาที่ยังคงเปิดอยู่

ลำดับความสำคัญ - ต่ำปกติสูงเร่งด่วนทันทีแปลเป็นภาษาจีนได้ดี

วันครบกำหนด - ฉันใช้สิ่งนี้เพื่อบอกว่าเมื่อใดที่นักพัฒนาซอฟต์แวร์ของฉันอัปโหลดการแก้ไขครั้งแรก ฉันอาจใช้เวลา 4-6 วันในการทดสอบบางอย่างและปิดปัญหา ฉันชอบแผนภูมิ Gannt ของฉันเพื่อสะท้อนการตอบสนองของทีมซอฟต์แวร์ของฉันไม่ใช่ว่าฉันใช้เวลานานแค่ไหนในการอนุมัติการแก้ไข

หมวดหมู่ - สิ่งนี้แสดงถึงเวอร์ชันของซอฟต์แวร์หรือฮาร์ดแวร์ที่ฉันพบปัญหาเสมอ ฉันใช้สิ่งนี้เพื่อดูว่าซอฟต์แวร์เวอร์ชันใดมีจุดบกพร่องมากที่สุดและเพื่อให้แน่ใจว่าซอฟต์แวร์เวอร์ชันใหม่จะไม่ประสบปัญหาการถดถอย

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

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

ตอนนี้เรากำลังใช้ Redmine กับส่วนเสริมที่ดี - Usersnap (Disclaimer: เราสร้างเครื่องมือเพื่อแก้ปัญหานี้ด้วยตัวเราเอง

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

QAs / ลูกค้าของเราสามารถป้อนจุดบกพร่องในเว็บแอปพลิเคชันได้โดยตรงและนักพัฒนาสามารถสร้างรายงานข้อบกพร่องลงใน Redmine ได้ง่ายขึ้น

เรากำลังใช้ส่วน Roadmap เป็นวิธีที่ชัดเจนในการแสดง:

• จุดบกพร่อง
• คุณสมบัติ (ซึ่งจะอ้างอิงไปยังเอกสารคำของคุณหรือลิงก์ไปยังหน้าข้อกำหนด html)
• การกระทบยอด (ความแตกต่างระหว่างมูลค่าการผลิตและค่าทดสอบ)
• และอื่น ๆ ...

นั่นคือประเด็นหลักของการรวมกลุ่มสำหรับเรา ส่วนที่เหลือจะใช้ในความสัมพันธ์กับสิ่งนั้น (ตัวอย่างเช่นส่วน 'ประกาศ' ใช้เพื่อกำหนดเป้าหมายหลัก / วันที่เผยแพร่ที่ใช้ในแผนงาน)

นอกจากความคิดเห็นอื่น ๆ แล้วฉันขอแนะนำให้ใช้ "สิ่งที่ต้องทำ" -Plugin (เขียนโดย Eric Davis ฉันคิดว่า :) การใช้ปลั๊กอินนั้นช่วยให้คุณสามารถลากและวางเรียงลำดับของปัญหาในหลาย ๆ โครงการได้

https://projects.littlestreamsoftware.com/projects/show/redmine-stuff-to-do

เราใช้ Versions เป็นวิธีกำหนด sprints ดังนั้นแต่ละ Version จึงเป็นการวิ่งที่มีมุมมอง Roadmap ที่ให้ภาพประกอบที่ชัดเจนเกี่ยวกับความคืบหน้า ปัญหาในการวิ่งจะถูกทำเครื่องหมายว่า "พร้อมสำหรับการตรวจสอบ" เมื่อดำเนินการเสร็จสิ้นและปิดลงเมื่อตรวจสอบ QA แล้ว

เราใช้เวอร์ชันเป็นงานในมือสำหรับปัญหาใด ๆ ที่อยู่นอกขอบเขตหรือสูญเสียลำดับความสำคัญเป็นต้น

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

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

เราชอบที่จะอัปเดตวิธีที่เราใช้ Redmine ดูเหมือนว่าจะมีปลั๊กอินที่ยอดเยี่ยมมากมาย แต่เราพบว่าปลั๊กอินจำนวนมากเสียหรือไม่สามารถติดตั้งได้

เราใช้วิกิอย่างครอบคลุมสำหรับเอกสารประกอบสำหรับนักพัฒนา