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

จากมุมมองระดับสูงมากสำหรับฉันดูเหมือนว่ามีเครื่องมือการจัดการโครงการ 2 ประเภท: ตัวติดตามปัญหาแบบดั้งเดิมเช่น Fogbugz, JIRA, BugZilla, Trac, Redmine เป็นต้น บอร์ดเสมือนจริง / เครื่องมือการจัดการโครงการที่คล่องตัวเช่น Pivotal Tracker, GreenHopper, AgileZen, Trello เป็นต้น แน่นอนว่าพวกเขาทับซ้อนกันไม่ทางใดก็ทางหนึ่งเช่นงาน Pivotal Tracker สามารถนำเข้าสู่ JIRA ได้ GreenHopper นั้นถูกนำไปใช้กับฐานปัญหา JIRA เป็นต้น แต่ฉันคิดว่ายังคงเห็นความแตกต่างของการวางแนวระหว่างเครื่องมือทั้งสองประเภทนี้ ดูเหมือนว่าปัญหาการติดตามแบบดั้งเดิมจะถูกนำมาใช้แม้ใน บริษัท อื่น ๆ ที่ดำเนินการจัดการโครงการแบบว่องไว คำถามของฉันคือทำไมพวกเขาทำอย่างนั้น? ฉันรู้สึกว่าเราควรใช้ตัวติดตามปัญหาใน บริษัท ของฉันด้วย แต่เมื่อฉันคิดถึงมันฉันไม่แน่ใจว่าทำไมเราถึงต้องการมัน ตัวอย่างเช่นการพัฒนา Trello ดูเหมือนว่าจะได้รับการจัดการโดยใช้ Trello เอง (ดูกำแพงเสมือนจริง ) แม้ว่าพวกเขาจะสามารถเข้าถึง Fogbugz ซึ่งเป็นหนึ่งในตัวติดตามปัญหาที่ดีที่สุด …

35 project-management  issue-tracking  kanban 

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

19 project-management  agile  technical-debt  kanban 

ฉันชอบ XP (การเขียนโปรแกรมขั้นสูง) โดยเฉพาะอย่างยิ่งส่วนที่มีโปรแกรมเมอร์ 2 คนที่หน้าจอเดียวกันเนื่องจากวิธีแก้ปัญหามักจะพบได้เร็วขึ้นหากคุณเพียงอธิบายว่าคุณกำลังทำอะไรและจับคู่การเขียนโปรแกรมบังคับให้คุณอธิบายสิ่งที่คุณ การทำ ในช่วง 10 ปีที่ผ่านมารูปแบบการทำงานของ XP ดูเหมือนจะล้าสมัยไปแล้วเนื่องจากวิธีการทำงาน: Agile และ / หรือ Kanban ทำไม? ตั้งแต่ XP ดูเหมือนว่าฉันจะเป็นวิธีที่ดีมากในการทำงานและเป็นจำนวนมากเกี่ยวกับการเขียนโปรแกรมในขณะที่ Agile และ Kanban เป็นมากกว่าเกี่ยวกับกระบวนการ

15 agile  extreme-programming  kanban 

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

13 agile  tracking  architecture  kanban  quality-attributes 

เริ่มต้นด้วย Kanban ฉันไม่แน่ใจเกี่ยวกับวิธีการทำงานของฉันอย่างละเอียด ในขณะที่คุณพบคำแนะนำที่เป็นรูปธรรมมากมายเกี่ยวกับวิธีเลือก WIP แต่บทเรียน Kanban ส่วนใหญ่ที่ฉันได้อ่านค่อนข้างคลุมเครือเกี่ยวกับขนาดของรายการงาน (= การ์ดบนกระดาน) สำหรับการวางแผนและการประมาณค่าที่คนมักจะแนะนำเพื่อให้ขนาดของขนาดเล็กรายการบอก 2-16 ชั่วโมง เช่นเดียวกันกับ Kanban หรือไม่ มีการแมป 1: 1 จากแผนของฉันไปยังกระดานเสมอหรือไม่? หากไม่มีแนวปฏิบัติที่ดีที่สุดหรือคำแนะนำทั่วไปปัจจัยใดบ้างที่จะมีผลต่อการเลือกรายการงานที่ละเอียด

11 kanban 

พิจารณาบอร์ด Kanban ทั่วไป: อินพุต, การวิเคราะห์, การเตรียมพร้อม, การพัฒนา, การสร้างพร้อม, การทดสอบ, พร้อมเผยแพร่ จะระบุขีด จำกัด WIP สำหรับแต่ละคอลัมน์ได้อย่างไร สูตรใด

10 kanban