คำถามติดแท็ก development-methodologies

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

25
ตรงไปตรงมาคุณชอบรหัสคาวบอยหรือไม่ [ปิด]
โปรแกรมเมอร์ส่วนใหญ่ปกป้องวิธีการทางการเมืองที่ถูกต้องเช่น Agile, Waterfall, RUP และอื่น ๆ บางคนทำตามวิธีการ แต่ไม่ทั้งหมด ตรงไปตรงมาถ้าคุณสามารถเลือกวิธีการที่แน่นอนคุณจะไปที่วิธีการ "ถูกต้อง" ที่สำคัญหรือคุณต้องการวิธีการ "ง่ายขึ้น" เช่นการเขียนโปรแกรมคาวบอย? ทำไม? ฉันรู้ว่ามันขึ้นอยู่กับ กรุณาอธิบายว่าคุณจะใช้อย่างใดอย่างหนึ่ง กรุณาพูดว่าคุณเห็นข้อได้เปรียบอะไรในการเข้ารหัสคาวบอย ดูเกี่ยวกับการเข้ารหัสคาวบอยใน Wikipedia

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

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

7
วิธีการวัดมูลค่าที่อาจเกิดขึ้นจากการปรับสภาพ
ในโครงการขนาดใหญ่ที่มีหนี้สินทางเทคนิคคุณสามารถประมาณการหรือวัดผลประโยชน์ของการเปลี่ยนรหัสได้อย่างน่าเชื่อถือได้อย่างไร ตัวอย่างเช่นสมมติว่าคุณมีส่วนประกอบบางอย่างภายในโซลูชันซอฟต์แวร์สแต็กที่เขียนด้วยภาษาที่เก่ากว่าและบางส่วนประกอบในภายหลังจะเขียนด้วยภาษาที่ใหม่กว่า มีการเพิ่มฟีเจอร์และการแก้ไขข้อผิดพลาดใหม่ ๆ ให้กับโซลูชันนี้โดยทีมพัฒนา นักพัฒนาแนะนำให้แทนที่องค์ประกอบภาษาเก่าที่มีอยู่ด้วยเวอร์ชันใหม่จะเป็น 'สิ่งที่ดี' อย่างไรก็ตามงานนี้จะไม่มีการเพิ่มคุณสมบัติพิเศษและจะเสียค่าใช้จ่าย x dev-days พนักงานขายแนะนำให้เพิ่ม 'คุณสมบัติใหม่ที่ยอดเยี่ยม' บริษัท วัดมูลค่าของข้อเสนอแนะของเขาโดยใช้สูตร กล่าวคือ มันจะสร้างรายได้ให้กับ บริษัท F ล้านปอนด์ในช่วงเวลา t ปีที่ทำงาน x dev-days บริษัท จะเสียค่าใช้จ่ายของข้อเสนอการเปลี่ยนโครงสร้างในวิธีที่มีความหมายได้อย่างไร และภายใต้สถานการณ์ใดเป็นตัวเลือกที่ทำกำไรได้มากที่สุดสำหรับ บริษัท ?

17
Standups รายวันใช่หรือเปล่า? [ปิด]
คุณคิดว่าการประชุมสแตนด์อะโลนแต่ละวันมีค่ามากน้อยเพียงใด หากคุณไม่คุ้นเคยกับสิ่งนี้สิ่งนี้หมายถึงการประชุมประจำวันที่เป็นส่วนหนึ่งของสมัครพรรคพวกของ Scrum (และวิธีการอื่น ๆ ที่คล่องตัว) แนวคิดคือคุณมีการประชุมรายวันกำหนดเวลา 15 นาทีและทุกคนต้องยืน (เพื่อส่งเสริมให้ผู้คนอยู่ในจุด) ในการประชุมคุณไปรอบ ๆ ห้องและแต่ละคนพูดว่า: - สิ่งที่คุณทำเมื่อวานนี้ - สิ่งที่คุณวางแผนจะทำในวันนี้ - บล็อคหรืออุปสรรคใด ๆ ต่อความก้าวหน้าของคุณ คุณคิดว่าการปฏิบัตินี้มีค่าหรือไม่? มีใครทำงานในที่ที่ทำไปแล้วคุณคิดว่าไง?

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

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

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

9
ฉันมีความคิดที่ผิดเกี่ยวกับวิศวกรรมซอฟต์แวร์หรือไม่? [ปิด]
ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังคำตอบที่จะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้จะเรียกร้องให้มีการอภิปรายโต้แย้งโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน7 ปีที่ผ่านมา ฉันมีคำถามที่ถูกยกขึ้นโดยงานล่าสุดของฉัน (ค่อนข้างฝึกงาน) เพียงแค่นำสิ่งต่าง ๆ เข้าสู่บริบท - ฉันอายุ 21 ปีและฉันเรียนจบมหาวิทยาลัยปีที่ 2 ก่อนหน้านี้ว่าฉันมีประสบการณ์ในการทำงานกับผู้ดูแลระบบ / QA ประมาณ 2 ปีและโดยทั่วไปฉันสามารถพูดได้ว่าฉันเห็นความแตกต่าง ดำเนินการภาคไอที ส่งต่อให้เวลาและนี่คือฉันเชื่อมโยงไปถึงงานฝึกงานที่หนึ่งในสถาบันการวิจัยชั้นนำในสหราชอาณาจักร สิ่งที่ฉันต้องทำคือสร้างเครื่องมือภายในบางอย่างโดยใช้การผสมผสานของเทคโนโลยี - ส่วนใหญ่คือ AWS / Java / Bash - คุณจะได้ภาพ ทุกอย่างโอเคฉันทำงานของฉัน แต่ฉันไม่มีความสุข ทำไม - เพราะฉันคาดว่าจะทำงานในเรื่องโฆษณา นั่นคือการสร้างสิ่งต่าง ๆ ได้อย่างรวดเร็วโดยไม่ต้องใช้เวลาในการออกแบบ ผู้จัดการของฉันบอกอย่างชัดเจนว่ามันคาดว่าจะ "เร่งด่วน" ผ่านปัญหาที่เกิดขึ้นและพวกเราก็สำคัญ ผลก็คือปรากฎว่าสิ่งที่จะต้องทำใหม่และวิศวกรอีกครั้งและพวกเขายังไม่สมบูรณ์ เท่าที่เกี่ยวข้องกับการทดสอบ - …

1
อนาธิปไตยนักพัฒนาคืออะไร
ฉันได้อ่านเกี่ยวกับผู้พัฒนา (หรือโปรแกรมเมอร์) อนาธิปไตยซึ่งดูเหมือนว่าจะเรียกเก็บเงินเป็นวิธีการพัฒนาโพสต์เปรียว ฉันพบทรัพยากรน้อย ( 1 , 2 ) แต่ดูเหมือนจะไม่ค่อยมีอะไรมากมาย ฉันสงสัยว่าใครมีทรัพยากรที่ดีที่ฉันสามารถหาข้อมูลเพิ่มเติมเกี่ยวกับมัน _ วิธีการใช้มันข้อดีข้อเสียเปรียบเทียบกับวิธีการอื่น ๆ เป็นต้น

11
เป็นไปได้หรือไม่ที่จะเขียนซอฟต์แวร์ที่ไม่จำเป็นต้องแก้ไขอย่างต่อเนื่อง?
ฉันเขียนซอฟต์แวร์เป็นจำนวนมากในหลายภาษาและฉันยังได้เขียนฮาร์ดแวร์สำหรับใช้กับ FPGA โดยใช้ Verilog และ VHDL ฉันมักจะสนุกกับการเขียนฮาร์ดแวร์มากกว่าซอฟต์แวร์และฉันคิดว่าหนึ่งในเหตุผลหลักคือมันเป็นไปได้ที่จะเขียนฮาร์ดแวร์ที่ "เสร็จสิ้น" และไม่จำเป็นต้องแก้ไข: คุณกำหนดอินเทอร์เฟซและฟังก์ชันการทำงานเขียนตารางทดสอบ ใช้โมดูลฮาร์ดแวร์จากนั้นทดสอบ heck จากมันโดยใช้ตัวจำลอง จากนั้นคุณสามารถพึ่งพาโมดูลฮาร์ดแวร์นั้นเป็นแบบเอกสารสำเร็จรูปเพื่อสร้างสิ่งที่ใหญ่กว่าและดีกว่า: หากคุณต้องการเพิ่มคุณสมบัติให้กับโมดูลนั้นคุณจะสร้างโมดูลที่สองและเพิ่มฟังก์ชันการทำงานที่นั่น คุณไม่เคยทิ้งโมดูลดั้งเดิมเพราะมันใช้งานได้ดีและยังคงมีประโยชน์ หนึ่งในความผิดหวังหลักของฉันกับซอฟต์แวร์คือมันไม่เคย "ทำ" มีคุณสมบัติเพิ่มอยู่เสมอ บ่อยครั้งเมื่อเพิ่มคุณสมบัติมันจะแนะนำบั๊กที่อื่นซึ่งใช้งานได้ดีมาก่อน สิ่งนี้ไม่ได้เกิดขึ้นในฮาร์ดแวร์ตราบใดที่อินเทอร์เฟซไม่ได้ถูกละเมิด เพื่อความชัดเจนฉันไม่ได้เรียกร้องให้สร้างบางสิ่งบางอย่างในรุ่นเดียวกับรายการคุณลักษณะและมันจะคงอยู่ตลอดไป: ฉันชอบการทำซ้ำและเผยแพร่หลายครั้งเมื่อเวลาผ่านไปเพื่อเพิ่มคุณลักษณะใหม่ ฉันไม่ต้องการที่จะกระตุ้นรหัสทางด้านซ้ายและค้นหาข้อผิดพลาดทางด้านขวาและสิ่งนี้ดูเหมือนว่าจะเกิดขึ้นหลังจากการเพิ่มคุณสมบัติใหม่ เป็นไปได้ไหมที่จะเขียนซอฟต์แวร์ในลักษณะเดียวกันกับที่ "เขียน" ฮาร์ดแวร์อยู่? มีวิธีการพัฒนาซอฟต์แวร์ที่ดีที่อนุญาตให้มีความก้าวหน้าไปข้างหน้าเสมอและอนุญาตให้เพิ่มฟังก์ชันการทำงานใหม่โดยไม่จำเป็นต้องเขียนโค้ดที่มีอยู่และแนะนำบั๊กใหม่หรือไม่

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

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

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

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