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

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

19 project-management  agile  scrum 

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

18 agile  scrum  requirements 

ฉันเพิ่งเข้าร่วมแฮกเกอร์สเปซอายุน้อยยังอยู่ในขั้นตอนการตั้งค่า เราโชคดีเพราะพื้นที่มีโครงการภายในไม่กี่แห่งที่ต้องทำงานและไม่มีอาสาสมัครทำงานให้ มีการหารือเกี่ยวกับวิธีการจัดระเบียบโครงการเหล่านี้ ประสบการณ์ระดับมืออาชีพล่าสุดของฉันอยู่กับ Scrum ดังนั้นฉันจึงพิจารณาการขว้างแนวทาง Scrum สำหรับโครงการซอฟต์แวร์ของเรา แต่ฉันไม่แน่ใจว่ามันจะเหมาะสม แม้ว่าฉันจะเห็นว่าการต่อสู้แบบ Scrum ทำงานได้ดีสำหรับทีมเต็มเวลาขนาดเล็ก แต่ลักษณะขององค์กรนี้แตกต่างกัน: สมาชิกที่มีอาสาสมัคร บางคนเป็นนักเรียนเต็มเวลา คนอื่น ๆ ทำงานเต็มเวลา เราไม่สามารถคาดหวังได้ว่าการมีส่วนร่วมอย่างสม่ำเสมอจากทุกคนในขณะที่ชีวิตจริงของพวกเขาให้ความสำคัญ ในขณะที่ทุกคนมีประสบการณ์เขียนซอฟต์แวร์มานานหลายปีมีสมาชิกไม่มากนักที่ทำอย่างมืออาชีพหรือในทีม นอกจากนี้ไม่มีเจ้าของผลิตภัณฑ์ ข้อกำหนดสำหรับโครงการเหล่านี้จะถูกกำหนดโดยคณะกรรมการ สมาชิกของคณะกรรมการนี้จะทำงานในการดำเนินการ ซึ่งหมายความว่าเราจะไม่มีเจ้าของผลิตภัณฑ์ที่อุทิศตน เราไม่มีกำหนดเวลา (อ่อนหรือแข็ง) โครงการจะเสร็จสิ้นเมื่อดำเนินการเสร็จ สิ่งเหล่านี้มีความแตกต่างอย่างมีนัยสำคัญ แต่ฉันไม่เชื่อว่าพวกเขาจะเป็นบล็อคให้ใช้ Scrum ฉันคิดว่าการปรับแต่งเล็กน้อยสามารถทำให้เราผ่านอุปสรรค์นี้ได้: หากเราเปลี่ยน Sprints ให้มีขนาดเรื่องจุดคงที่ แต่ระยะเวลาของเหลว (เวลา) เรายังสามารถได้รับประโยชน์จากการเผยแพร่ซ้ำโดยไม่กดดันต่อการส่งที่ไม่สมจริงใน devs ของอาสาสมัคร เราสามารถทิ้งแผนภูมิการเผาไหม้และการคำนวณความเร็ว หากฉันเข้าใจถูกต้องสิ่งเหล่านี้เป็นเครื่องมือและตัวชี้วัดที่ทำงานเป็นสะพานเชื่อมระหว่างทีม dev และฝ่ายจัดการ พวกเขาทำหน้าที่รายงานความคืบหน้าในรูปแบบที่มีความหมายต่อทั้งนักพัฒนาและผู้มีส่วนได้เสีย พิจารณาว่าเราไม่มีใครรายงาน (ไม่มีผู้จัดการโครงการไม่มีเจ้าของผลิตภัณฑ์และไม่มีผู้มีส่วนได้เสียภายนอก) ฉันเชื่อว่าเราสามารถทำสิ่งนี้ได้ทั้งหมด สิ่งที่ฉันคิดว่าเราจะได้รับจากการที่ไม่ต้องใช้การปรับแต่ง: การรวบรวมความต้องการประชุม (s) …

18 scrum  extreme-programming 

ในโครงการของเราเราทำงานในวิธีการ zero-bug (aka ศูนย์บกพร่อง) แนวคิดพื้นฐานคือข้อบกพร่องมักจะมีความสำคัญสูงกว่าคุณสมบัติ หากคุณกำลังทำงานกับเรื่องราวและมีข้อบกพร่องจะต้องได้รับการแก้ไขเพื่อให้เรื่องราวได้รับการยอมรับ หากพบข้อผิดพลาดในระหว่างการวิ่งเพื่อเล่าเรื่องราวที่เก่ากว่าเราต้องใส่มันไว้ใน Backlog ของเราและแก้ไขมัน - ลำดับความสำคัญสูงสุด เหตุผลที่ฉันพูดแก้ไขคือเราไม่ได้แก้ไขข้อผิดพลาด บางครั้งเราเพิ่งประกาศว่า "จะไม่แก้ไข" เนื่องจากไม่ใช่สิ่งสำคัญ ทั้งหมดมันฟังดูดี เรากำลังจัดส่งผลิตภัณฑ์คุณภาพสูงและอย่าพก "a hump" ในรูปของ backlog ขนาดใหญ่ แต่ฉันไม่แน่ใจว่าวิธีนี้ถูกต้อง ฉันมักจะเห็นด้วยว่าเราต้องแก้ไขข้อผิดพลาดที่ร้ายแรงโดยเร็วและเราจำเป็นต้องทิ้งข้อบกพร่องที่ไม่น่าสนใจออกไป แต่สิ่งที่เกี่ยวกับข้อบกพร่องที่มีความสำคัญ แต่ไม่สำคัญเท่ากับคุณลักษณะใหม่ ฉันมักจะคิดว่าพวกเขาควรจะยื่นใน backlog ด้วยความสำคัญที่เหมาะสม ฉันจะยกตัวอย่างเพื่อให้ชัดเจน - ในโครงการของฉันเราทำงานกับ UI ที่เขียนด้วยเฟล็ก เรามีหน้าจอตัวช่วยสร้างที่เปิดขนาดเดียวกันสำหรับทุกความละเอียดหน้าจอ ปรากฎว่าเมื่อเราขยายหน้าต่างตัวช่วยสร้างหน้าใดหน้าหนึ่งดูไม่ดี (มีแถบเลื่อนแนวตั้งที่ไม่หายไปแม้ว่าตัวช่วยสร้างจะสามารถแสดงทุกอย่างได้ในขณะนี้และไม่ต้องการแถบเลื่อน) ฉันคิดว่าข้อผิดพลาดนี้น่าเกลียด ฉันแน่ใจว่าจะต้องแก้ไข แต่เราอยู่ในช่วงเวลาที่ จำกัด และเรามีฟีเจอร์มากมายที่เรากลัวว่าจะไม่ทำให้ถูกตัดและเข้าสู่รุ่น ฉันรู้สึกว่าเราสามารถมีชีวิตอยู่กับข้อผิดพลาดดังกล่าว จำเป็นต้องได้รับการแก้ไข แต่มีลำดับความสำคัญต่ำกว่าคุณลักษณะอื่น ๆ (ดังนั้นในกรณีที่เราไม่สามารถดำเนินการให้เสร็จได้อย่างน้อยเราก็ไม่ได้ทิ้งคุณลักษณะที่สำคัญอื่น ๆ ไว้) แต่, …

18 agile  scrum  bug  backlog 

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

18 agile  scrum  management  extreme-programming 

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

18 agile  scrum  definition  product-backlog 

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

18 productivity  management  scrum  meetings  reporting 

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

18 scrum  planning 

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

18 scrum 

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

18 scrum  sprint 

ฉันต้องการปรับปรุงวิธีการพัฒนาซอฟต์แวร์ ฉันต้องการที่จะพัฒนาเร็วขึ้นและเป็นรหัสที่ยอดเยี่ยม! วันนี้ฉันใช้วิธีน้ำตกเป็นอิสระเขียนเนื้อหาเว็บ (เว็บไซต์ระบบ ฯลฯ ) มีวิธีใช้การพัฒนาแบบว่องไว (XP, SCRUM และอื่น ๆ ) ทำงานด้วยวิธีนี้หรือไม่? ฉันไม่รู้อะไรเลยเกี่ยวกับการพัฒนาที่คล่องตัวฉันควรเริ่มจากที่ไหน ขอบคุณมาก.

18 agile  freelancing  scrum  web 

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

17 agile  scrum  estimation  qa 

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

17 project-management  agile  scrum 

การพัฒนาซอฟต์แวร์ Agile กลายเป็นคำศัพท์ที่สนุกมากในทุกวันนี้ ในฐานะนักพัฒนาฉันเข้าใจถึงคุณค่าในทางปฏิบัติของการพัฒนาซ้ำ ๆ แต่บ่อยครั้งที่มันไม่ใช่ตัวเลือกของนักพัฒนาที่จะยอมรับแนวทาง Agile ในการพัฒนาซอฟต์แวร์ มันเป็นตัวเลือกการจัดการจากบนลงล่าง! ไม่ว่าจะเป็นคริสตัลวิธีการว่องไว dsdm, rup, xp, scrum, fdd, tdd คุณตั้งชื่อมัน มันไม่ใช่ตัวเลือกสำหรับนักพัฒนา สำหรับผู้จัดการทุกคนที่นั่นอะไรคือเหตุผลที่ดีที่สุดสำหรับการเลือกที่จะพัฒนา Agileเมื่อผู้จัดการของฉันส่วนใหญ่ไม่ได้สัมผัสกับรหัสในชีวิตของพวกเขา (ในประสบการณ์ของฉัน)

17 project-management  agile  management  project  scrum 

ฉันสงสัยอยู่เสมอว่าจะใช้วิธีการแบบเปรียวได้อย่างไรในซอฟต์แวร์ระบบสมองกลฝังตัวที่ซับซ้อนขนาดใหญ่ (วิศวกรมากกว่า 100 คน) การพัฒนาเฟิร์มแวร์มีลักษณะเฉพาะบางอย่างที่ทำให้ยากต่อการใช้งาน (เช่นฮาร์ดแวร์ไม่สามารถใช้งานได้จนถึงช่วงท้ายของรอบการพัฒนาเมื่อผลิตภัณฑ์ออกวางจำหน่ายแล้วจะไม่สามารถอัปเดตเฟิร์มแวร์ได้ง่าย ฯลฯ ) บรรทัดฐานในการพัฒนาประเภทนี้คือเอกสารที่มีความหนาและความคิดเห็นที่โหดเหี้ยม คุณไม่สามารถแก้ไขรหัสอย่างง่ายได้เช่นเปลี่ยนชื่อตัวแปรโดยไม่มีลายเซ็น 2-3 รายการ (ฉันพูดเกินจริงไปเล็กน้อย แต่นี่เป็นเรื่องปกตินอกจากนี้ผู้คนจำนวนมากใช้ทางลัดและผู้จัดการโครงการจะอนุมัติพวกเขาโดยเฉพาะอย่างยิ่งเมื่อต้องเผชิญกับเส้นตายของตลาดที่ยากลำบาก) ฉันอยากจะฟังเคล็ดลับหรือแนวทางใด ๆ เกี่ยวกับวิธีการใช้ระเบียบวิธีแบบเปรียวสำหรับโครงการพัฒนาเฟิร์มแวร์

17 agile  scrum  embedded-systems