การผลิตกับการพัฒนาซอฟต์แวร์ [ปิด]


10

มีการกล่าวบ่อยครั้งว่าอุตสาหกรรมซอฟต์แวร์ยังไม่บรรลุนิติภาวะเมื่อเทียบกับอุตสาหกรรมการผลิต โดยเฉพาะอย่างยิ่งเกี่ยวกับการขับเคลื่อนกระบวนการ

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

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

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

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

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

ทุกคนที่ฉันคุยด้วยดูเหมือนจะเห็นด้วยกับความคิดการผลิต ฉันอยู่คนเดียวในความคิดของฉัน


1
FYI: อะไรที่กระตุ้นให้ฉันถามคำถามนี้คือหนังสือ CMMI มันเปรียบเทียบการสร้างซอฟต์แวร์กับการผลิตและสรุป Soft.Ind ยังไม่บรรลุนิติภาวะ
Lord Tydus

3
ฉันจะบอกว่าการเปรียบเทียบที่แม่นยำมากขึ้นในสาขาเดียวกันนั้นเป็นวิศวกรรมที่เกี่ยวข้องกับการออกแบบและการตั้งโรงงานของคุณ นั่นคือสิ่งที่บิตสร้างสรรค์ / ยากเกิดขึ้น ส่วนที่เหลือเป็นเพียงถั่วและสลักเกลียวเช่นเดียวกับเราส่วนที่เหลือเป็นเพียง 1 และ 0
Benjol

1
วิศวกรรมซอฟต์แวร์ไม่ได้เปรียบเทียบกับการผลิต มันเปรียบเทียบกับงานฝีมือ สิ่งนี้ไม่สามารถลดลงเป็นกระบวนการทางอุตสาหกรรมได้
mouviciel

1
ไม่มีเหตุผลใดที่จะเรียกว่าซอฟต์แวร์ที่เป็นการพัฒนา ไม่ได้ซอฟแวร์การผลิต คิดว่าการพัฒนาผลิตภัณฑ์กับการผลิตผลิตภัณฑ์
tehnyit

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

คำตอบ:


36

ความแตกต่างพื้นฐานระหว่างการพัฒนาซอฟต์แวร์และการผลิตคือสำหรับซอฟต์แวร์ขั้นตอนการออกแบบนั้นแท้จริงแล้วทั้งหมด การผลิตจริง (ส่วนสายการประกอบในการผลิตแบบดั้งเดิม) เป็นเรื่องของการคัดลอกไฟล์ไม่กี่ไฟล์ ในซอฟต์แวร์การออกแบบผลิตภัณฑ์เป็นผลิตภัณฑ์

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

ตัวอย่างหนึ่งของแบบจำลองกระบวนการที่ทำงานได้ดีมากในซอฟต์แวร์ แต่มักจะล้มเหลวอย่างน่ากลัวในการออกแบบผลิตภัณฑ์คือการออกแบบซ้ำ - คุณเริ่มต้นด้วยต้นแบบที่น้อยที่สุดและเพิ่มคุณสมบัติด้วยการทำซ้ำแต่ละครั้ง การสร้างรถต้นแบบเพื่อดูว่าการออกแบบลูกบิดหน้าต่างด้านหลังใหม่ดูเหมือนไร้สาระ แต่ในซอฟต์แวร์มันสมเหตุสมผลแล้ว (แค่กด F5 แล้วรอสักครู่ - voilàพร้อมทดสอบไดรฟ์)

หากเราพิจารณากระบวนการออกแบบผลิตภัณฑ์อุตสาหกรรมที่ดีที่สุดในการพิจารณาแบ่งออกเป็นสองประเภท:

  • ผู้ที่สามารถรับรู้การผลิตในอัตราสินค้าโภคภัณฑ์; เช่นอุตสาหกรรมแผ่นเสียง (1% หรือน้อยกว่าราคาของซีดีคือการอบและการพิมพ์) สื่อกราฟิกเป็นต้น
  • ผู้ที่มีปริมาณน้อยจนขั้นตอนการออกแบบเป็นปัจจัยด้านต้นทุนที่โดดเด่นที่สุด (บทความหรูหราผลิตภัณฑ์ที่ปรับแต่งได้สูงตลาดเฉพาะกลุ่ม ... )

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


2
คำตอบที่ดี ในการพัฒนาซอฟต์แวร์ทุกอย่างเป็นต้นแบบ!
James Anderson

1
มันเป็นจุดที่ดี แต่ฉันคิดว่าด้านการออกแบบนั้นเกินความจริง คุณได้ยินตัวเลขที่ถูกโยนทิ้งไปเช่น "60% ของต้นทุนซอฟต์แวร์คือการบำรุงรักษา" และ "10% สุดท้ายของโครงการซอฟต์แวร์นั้นใช้เวลามากกว่า 10% ของกำหนดการ" ตัวเลขไม่สำคัญเท่าความคิดที่นี่และการบำรุงรักษาและการขัดเกิดขึ้นได้ดีหลังจากการออกแบบได้สิ้นสุดลงแล้ว การออกแบบนั้นไม่ต้องสงสัยเลยว่าเป็นส่วนสำคัญของผลิตภัณฑ์ แต่ก็เป็นส่วนที่ง่ายและราคาถูกที่สุด
Caleb

3
@Caleb: ยกเว้นการบำรุงรักษาโดยเฉพาะอย่างยิ่งสำหรับผลิตภัณฑ์ที่ออกแบบมาอย่างดีส่วนใหญ่ไม่ได้เกี่ยวกับการแก้ไขข้อบกพร่องในผลิตภัณฑ์ปัจจุบัน แต่เกี่ยวกับการเพิ่มคุณสมบัติในคำอื่น ๆ การเพิ่มและเปลี่ยนการออกแบบ
Marjan Venema

@Caleb - นี่อาจเป็นจริงในการตั้งค่าสายการผลิตและกระบวนการผลิตเช่นกัน การตั้งค่าสายการผลิตเป็นหนึ่งในด้านที่แพงที่สุดและใช้เวลานานของกระบวนการผลิต
James Anderson

2
@Caleb: ฉันคิดว่าคุณเข้าใจผิดอุปมาของฉันที่นี่ เมื่อฉันพูดถึง 'การออกแบบ' ฉันกำลังพูดถึงการออกแบบผลิตภัณฑ์นั่นคือกระบวนการที่เริ่มต้นก่อนการประกอบสายการผลิต ทั้งขั้นตอนการออกแบบและการนำไปใช้งานของผลิตภัณฑ์ซอฟต์แวร์นั้นเป็น 'การออกแบบ' ในแง่นี้ในขณะที่ชิ้นส่วนการผลิตจะถูกลดการอัพโหลดไบนารีไปยังเซิร์ฟเวอร์หรืออบ DVD-ROM สำหรับการจัดส่ง ในฐานะโปรแกรมเมอร์ทุกสิ่งที่คุณมอบให้คือต้นแบบ ดังนั้นทุกสิ่งที่คุณทำรวมถึงงานบำรุงรักษาคือ 'การออกแบบ' ในการเปรียบเทียบแบบดั้งเดิมของห่วงโซ่การผลิต
tdammers

10

หากคุณต้องการเขียนซอฟต์แวร์ที่แน่นอนซ้ำแล้วซ้ำอีก (ซึ่งต่างจากการคัดลอก) คุณสามารถทำได้อย่างมีประสิทธิภาพผ่านสายการประกอบ

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


การเรียนจากการผลิตไม่ได้หมายถึงการสร้างสายการประกอบซอฟต์แวร์ ฝ่ายผลิตมีหลายสิ่งที่จะพูดถึงเกี่ยวกับการปรับปรุงกระบวนการและมีกระบวนการพัฒนาซอฟต์แวร์มากมายที่สามารถปรับปรุงได้
Caleb

@Caleb: คุณหมายถึงบทเรียนอะไร? นั่นคือสิ่งที่ฉันคิดว่าคุณหมายถึง
sevenseacat

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

2

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

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

  • การตรวจสอบโค้ดนั้นยอดเยี่ยมและแสดงให้เห็นถึงข้อบกพร่องส่วนใหญ่ แต่ประสิทธิภาพของการรีวิวลดลงอย่างรวดเร็วหลังจากการทบทวนในชั่วโมงแรก เนื่องจากบุคคลทั่วไปสามารถอ่านโค้ดได้เพียงไม่กี่ร้อยบรรทัดต่อชั่วโมงเท่านั้นแสดงว่าผู้พัฒนาควรแบ่งการเปลี่ยนแปลงเป็นชิ้นเล็ก ๆ
  • ยิ่งใช้เวลานานในการหาบั๊กที่มีราคาแพงมากขึ้น (เวลาและเงิน) มันก็จะทำการแก้ไข ดังนั้นหากนักพัฒนาค้นพบมันในขณะที่เขียนรหัสเราบอกว่าค่าใช้จ่ายคือ 1 ถ้าผู้ที่ไม่รู้จักพบมันในภายหลังค่าใช้จ่ายคือ 10 ถ้า EVT พบว่ามันมีค่าเท่ากับ 100 เป็นต้น
  • มีหลักฐานบางอย่างที่แสดงให้เห็นว่าข้อกำหนดที่ซับซ้อนยิ่งมีความซับซ้อนมากขึ้นการแก้ปัญหาคือและการแก้ปัญหาที่ซับซ้อนมากขึ้นมีแนวโน้มที่จะมีข้อบกพร่องมากขึ้น

มีชายคนหนึ่งชื่อเกร็กวิลสันผู้บรรยายอย่างยอดเยี่ยมเกี่ยวกับเรื่องนี้เมื่อไม่กี่ปีที่ผ่านมา นี่คือลิงค์สำหรับพูดคุย: Greg Wilson Talk

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

  • ฉันจำไม่ได้บ่อยครั้งที่สร้างสิ่งต่าง ๆ ทั้งหมดที่ทำให้ฉันทำลายงานสร้าง
  • หลายครั้งที่ฉันไม่ได้คิดถึงสิ่งต่อไปนี้สำหรับการเปลี่ยนแปลงแต่ละครั้ง กรณีที่ดีกรณีที่ไม่ดีและกรณีพิเศษ
  • สถานการณ์ที่เป็นไปได้ทั้งหมดที่อาจเกิดขึ้น โปรดทราบว่านี่เป็นเรื่องยากเพราะมีจำนวนมาก

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


2

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

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

ดังนั้นไม่กระบวนการพัฒนาซอฟต์แวร์ไม่สามารถเปรียบกับการผลิตสายการประกอบและเช่น "กระบวนการของพวกเขา" จะไม่ตกลง แต่ขั้นตอนการออกแบบการผลิต / การออกแบบผลิตภัณฑ์ของผลิตภัณฑ์ในอุตสาหกรรมการผลิตสามารถเป็นแรงบันดาลใจจาก


1

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

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

  • การติดตามข้อบกพร่อง:เมื่อพบข้อบกพร่องหรือรายงานสิ่งที่เกิดขึ้นกับมัน คุณเขียนมันลงบนเศษกระดาษแล้วแปะไว้ที่เข็ม 'สอบสวน'? คุณจะลบสิ่งที่สนใจเหล่านั้นทีละหนึ่งครั้งตรวจสอบพวกเขาและในที่สุดก็ย้ายพวกมันไปที่เข็ม 'ที่ได้รับการแก้ไขแล้ว' หรือไม่? หากคุณทำเช่นนั้นโดยไม่ล้มเหลวทุกครั้งที่คุณได้รับรายงานข้อผิดพลาดคุณจะได้รับกระบวนการที่ชัดเจนและสามารถวัดได้และคุณอาจจะดีกว่าคนที่มีระบบติดตามข้อบกพร่องที่ล้ำสมัยและมีเทคโนโลยีสูง สมาชิกในทีมบางคนติดตามบั๊กในแบบอื่นหรือไม่เลย

  • การควบคุมเวอร์ชัน:มีโอกาสดีที่คุณจะใช้การควบคุมเวอร์ชันที่คุณใช้งานอยู่และการควบคุมเวอร์ชันนั้นมีประโยชน์มากกว่าเมื่อทุกคนใช้แบบเดียวกัน

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

  • การตรวจสอบรหัส:การตรวจสอบรหัสจะมีประโยชน์หรือไม่หากกระบวนการตรวจสอบและเกณฑ์การเข้ารหัสเปลี่ยนไปสำหรับการตรวจสอบแต่ละครั้ง ไม่แน่นอน

  • วงจรการพัฒนาซอฟต์แวร์:การวิเคราะห์ทั้งหมด-> การออกแบบ -> การติดตั้ง -> การทดสอบ ->วงจรการบำรุงรักษาเป็นกระบวนการที่ควรกำหนดไว้อย่างชัดเจน

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

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

การพัฒนาซอฟต์แวร์ได้นำแนวคิดการผลิตจำนวนมากมาใช้แล้ว:

  • มันยากที่จะไม่เห็นอิทธิพลของชิ้นส่วนกันอีไลวิทนีย์ของทั้งตัวผู้ป่วยเองและพัฒนา component-based

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

  • วิธีการจัดการคุณภาพเช่น Six Sigma ที่พัฒนาขึ้นเพื่อการผลิตได้รับการปรับให้เข้ากับการพัฒนาซอฟต์แวร์

แม้จะมีสภาพแวดล้อมที่ขับเคลื่อนด้วยกระบวนการที่หนักหน่วงผู้พัฒนาจะต้องมีส่วนร่วมในการสร้างสรรค์สิ่งต่าง ๆ "ในทันที"

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

การทำสิ่งต่าง ๆ เป็นสิ่งที่ขัดต่อจิตวิญญาณของการผลิต

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


+1 ความคิดของฉัน แต่ฉันกลัวว่านี่อาจไม่ใช่คำตอบยอดนิยมเพราะในรัฐวิศวกรรมซอฟต์แวร์ที่ยังไม่บรรลุนิติภาวะ แม้แต่ภายใน CMMI ที่ L1 วีรบุรุษก็ยังได้รับการเคารพสักการะในฐานะเทพเจ้า
Vaibhav Garg

@ Vaibhav Garg: ฉันเชื่อว่าในระยะยาวกระบวนการที่ดีที่สุดในแง่ธุรกิจชนะ หากการควบคุม "กระบวนการวิศวกรรมซอฟต์แวร์" ส่งผลให้มีอัตราส่วนของความเร็ว / ต้นทุนที่มีคุณภาพสูงกว่า บางครั้งรหัสคาวบอยดูเหมือนว่าจะสร้างผลลัพธ์ที่ดีอย่างน่ารำคาญ
Joonas Pulakka

1
@JoonasPulakka ฉันยอมรับว่าบางครั้งการเข้ารหัสคาวบอยดูเหมือนว่าจะให้ผลลัพธ์ที่ดี แต่ที่สำคัญคือ "บางครั้ง" ถ้าคุณตั้งเป้าหมายว่าจะทำซ้ำได้คุณต้องทำซ้ำในสิ่งที่คุณทำ คิดว่า P ใน SIPOC!
Vaibhav Garg

1
@ JoonasPulakka- การอ้างอิงคำต่อคำจากมาตรฐาน CMMI สำหรับองค์กรระดับ 1: ความสำเร็จในองค์กรเหล่านี้ขึ้นอยู่กับความสามารถและความกล้าหาญของผู้คนในองค์กรและไม่ได้ใช้กระบวนการที่พิสูจน์แล้ว ถึงแม้จะมีความสับสนวุ่นวายองค์กรระดับ 1 ที่ครบกำหนดมักจะผลิตสินค้าและบริการที่ทำงาน อย่างไรก็ตามพวกเขามักจะเกินงบประมาณของพวกเขาและไม่ตรงตามกำหนดเวลาของพวกเขา
Vaibhav Garg

2
"ความสำเร็จในองค์กรเหล่านี้ขึ้นอยู่กับความสามารถ ... ของคน" ฉันไม่คิดว่ากระบวนการใด ๆ สามารถเปลี่ยนแปลงสิ่งนั้นได้
วินไคลน์
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.