วิธีการใช้วิธีการแบบว่องไวสำหรับการพัฒนาเฟิร์มแวร์ / ระบบสมองกลฝังตัวซอฟต์แวร์?

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

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

ฉันอยากจะฟังเคล็ดลับหรือแนวทางใด ๆ เกี่ยวกับวิธีการใช้ระเบียบวิธีแบบเปรียวสำหรับโครงการพัฒนาเฟิร์มแวร์

ฉันคิดว่าสองเทคนิคเป็นกุญแจสำคัญ:

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

• เขียนจำนวนมากของการทดสอบหน่วยต่อต้านการจำลอง

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

ผลกระทบของ Agile ต่อกระบวนการพัฒนาที่เกี่ยวข้องกับซัพพลายเออร์หลายรายสามารถนำมาเปรียบเทียบกับสิ่งที่เกิดขึ้นเมื่อ บริษัท ไปสู่ ​​JIT

ในการส่งมอบ JIT ซัพพลายเออร์ของ บริษัท แต่ละรายจะต้องส่งมอบ JIT

function deliversJIT( company ) { 
    return company.isJIT() && map( deliversJIT, company.suppliers() );
}

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

ในแง่ของการพัฒนา 'เพิ่มขึ้น' (อาคาTracer Bullets เมื่อ 15 ปีที่แล้ว) นี่จะแปลว่า 'แกนกลาง' จะถูกปล่อยออกมาในไม่ช้ากับคนขับและคนขับพื้นฐานจะพร้อมใช้งานกับอินทิเกรตและ GUI จะ ได้รับการพัฒนาเลนด้วยปุ่มเดียวและกล่องแก้ไขในเวลาเดียวกัน

ส่วนที่ยากคือการโน้มน้าวใจนักออกแบบฮาร์ดแวร์ที่มาจากวินัยทางวิศวกรรมที่คิดอย่างตรงไปตรงมาเพื่อเข้าร่วมสังคมคนจรจัดของเรา

ส่วนที่ยากที่สุดที่สองคือการหาวิธีที่จะช่วยให้การพัฒนาที่เพิ่มขึ้นในโลกที่มีการสั่งพิมพ์ฮาร์ดแวร์ล่วงหน้า 3 สัปดาห์ ฉันคิดว่า emulators fpga อยู่ที่นี่ ฉันไม่ใช่คนที่แต่งตัวประหลาดฮาร์ดแวร์

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

อย่ามัว แต่ตาบอด: Agile ต้องจัดการกับกระบวนการที่มีน้ำหนักมากเช่นกัน! อย่าขอให้ทีม Agile ทำการ 'refactor' ฐานรหัส Java ให้กับ Python ในการวิ่งครั้งต่อไป มันเป็นเพียงเพราะบางส่วนมีความเสถียรจริงๆที่เราสามารถเต้นท่า Agile ของเราได้

ประกาศ Agile: http://agilemanifesto.org/

"บุคคลและการมีปฏิสัมพันธ์กับกระบวนการและเครื่องมือ"

• พบมากขึ้น ดันกระดาษให้น้อยลง

"ซอฟต์แวร์ที่ทำงานได้บนเอกสารที่ครอบคลุม"

• ต้นแบบและสร้างเทคโนโลยีแหลมเร็วและบ่อยครั้ง

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

"ความร่วมมือกับลูกค้าในการเจรจาต่อรองสัญญา"

• กระบวนการควบคุมการเปลี่ยนแปลงที่สลับซับซ้อนมากเกินไปเป็นเพียงวิธีการพูดว่า "ไม่" กับลูกค้า

• การล็อคความต้องการทั้งหมดไว้ด้านหน้าจากนั้นการควบคุมการเปลี่ยนแปลงที่น่าประทับใจเป็นอีกวิธีหนึ่งในการพูดว่า "ไม่"

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

"การตอบสนองต่อการเปลี่ยนแปลงมากกว่าการทำตามแผน"

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

ระเบียบวิธีแบบว่องไวทั้งหมด (เช่นการต่อสู้) อาจไม่สมเหตุสมผลสำหรับระบบฝังตัว

อย่างไรก็ตาม Agile manifesto จัดเตรียมวิธีในการอนุญาตให้มีการเปลี่ยนแปลงที่เป็นไปได้โดยไม่ทำให้เกิดความสับสนวุ่นวายง่าย ๆ

ปัญหาของฉันเกี่ยวกับการทะเลาะกันในระบบฝังตัวคือมีหลายงานที่ต้องทำโดยเฉพาะในช่วงแรกซึ่งไม่สามารถพิสูจน์ได้ เราเริ่มต้นด้วยบอร์ด dev ไม่มีระบบปฏิบัติการไม่มีจอแสดงผลไม่มีการสื่อสารแบบอนุกรม ฯลฯ เราไม่ได้มีจอแสดงผลสำหรับ 6 sprints

การวิ่ง 4 ครั้งแรกคือการทำให้ RTOS ทำงานและกำลังสร้างงานการเขียนเครือข่ายและไดรเวอร์อนุกรมการเขียนอินเตอร์รัปต์สำหรับปุ่ม comms และอื่น ๆ การเขียนคลาสฐานข้อมูลหลักและวิธีการเขียนเมนูดีบักอนุกรม

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

แน่นอนว่าแต่ละชั้นเรียนที่เราเขียนมีการทดสอบหน่วยที่เกี่ยวข้องและเราใช้กรอบการทดสอบหน่วยเพื่อดำเนินการทดสอบทั้งหมดโดยอัตโนมัติ

เราลงเอยด้วยการเขียนวลี "เรื่องราวของผู้ใช้" เช่น "ในฐานะนักพัฒนา ... " ซึ่งฉันไม่พอใจ แต่ในการใช้ Target Process (www.targetprocess.com) ไม่มีแนวคิดของรายการค้างซึ่งเป็น งานหรืองานบ้าน

ฉันชอบที่จะได้ยินว่าคนอื่นจัดการกับสถานการณ์เหล่านี้อย่างไร