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

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

47 agile  development-methodologies  waterfall 

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

44 agile  programming-practices  waterfall 

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

23 agile  waterfall 

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

19 development-process  model  waterfall  engineering 

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

14 development-methodologies  waterfall 

เมื่อเร็ว ๆ นี้เรามีโครงการที่ลูกค้าไม่ว่างในการทัวร์ ทีมการต่อสู้ตามปกติก่อตั้งขึ้นฝ่ายบริหารจึงตัดสินใจแต่งตั้งนักวิเคราะห์ของเราในฐานะเจ้าของผลิตภัณฑ์เนื่องจากลูกค้าจะไม่สามารถเข้าร่วมได้ นักวิเคราะห์เป็นคนหนึ่งที่ทำงานอย่างใกล้ชิดกับลูกค้าในการวิเคราะห์ความต้องการและร่างข้อกำหนด ลูกค้าไม่มีเวลาที่จะตรวจสอบสองรุ่นแรก ทุกอย่างเป็นไปอย่างราบรื่นจนกระทั่งลูกค้าเห็นรุ่นที่สาม; เขาไม่พอใจกับฟังก์ชันการทำงานบางอย่างและสิ่งเหล่านั้นได้รับการแนะนำโดย make shift Product Owner (นักวิเคราะห์ของเรา) เราได้รับคำสั่งให้รอจนกระทั่งทีมออกแบบเสร็จการเยาะเย้ยหน้าทุกหน้าและลูกค้าตรวจสอบแต่ละรายการและอนุมัติให้ทำงานต่อไป ทีมต่อสู้แย่งกันอยู่ที่นั่น แต่ไม่มีการวิ่ง - เราทำงานเกือบเสร็จเหมือนวิธีน้ำตกแบบดั้งเดิม เป็นความคิดที่ดีไหมที่จะแต่งตั้งสมาชิกทีมหรืออาจารย์ในการเป็นเจ้าของผลิตภัณฑ์? เราจำเป็นต้องติดตามการทะเลาะวิวาทในกรณีที่ไม่มีลูกค้า / เจ้าของผลิตภัณฑ์มีส่วนร่วมหรือไม่?

13 agile  scrum  waterfall 

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

11 agile  methodology  waterfall  technique 

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

10 agile  refactoring  optimization  waterfall 

ประมาณหนึ่งปีครึ่งที่ผ่านมาฉันเข้าทำงานที่อ้างว่าทำแบบ Agile development สิ่งที่ฉันได้เรียนรู้คือสถานที่แห่งนี้มีการปฏิบัติที่คล่องแคล่วหลายอย่าง (เช่น standups รายวัน plannings plunings และ sprint review) แต่ไม่มีหลักการใด ๆ (ในเวลา / มีความคิดที่ดีพอ ตอนนี้ฉันได้รับมอบหมายให้ทำให้ทีมมีความคล่องตัวมากขึ้นและฉันมั่นใจว่าฉันมีการบายอินอย่างสมบูรณ์จากทีม dev และทีมธุรกิจ ในฐานะโปรแกรมนำร่องพวกเขาให้โครงการที่เพิ่งรวบรวมความต้องการครบ 15 เดือนมีเอกสารวิเคราะห์และออกแบบหน้า 110 (ถือว่าเป็น "หิน") และที่ฉันไม่สามารถเข้าถึงจุดสิ้นสุดได้ ผู้ใช้ (สำหรับคณะกรรมการที่ประกอบด้วยผู้จัดการของผู้ใช้ที่ไม่ได้ใช้ผลิตภัณฑ์) ฉันเริ่มเล็กให้พวกเขามีรายการสิ่งของที่คาดหวังสำหรับ 5 sprints แรก (ปล่อย sprints ในอนาคตที่ไม่ได้กำหนด) รายการเป้าหมายของ sprint แรกและฉันก็แยกเอกสาร A & D เพื่อให้เรื่องราวของผู้ใช้เพียงพอที่จะบรรลุเป้าหมายของ sprint แรก . ตั้งแต่นั้นมาพวกเขาถามว่าทำไมเราถึงไม่มีข้อกำหนดทั้งหมดสำหรับ sprints ทั้งหมดทำไมฉันไม่เริ่มทำงานกับสิ่งของสำหรับ sprint …

9 project-management  agile  waterfall 

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

9 design  development-process  coding  waterfall 

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

9 project-management  agile  waterfall 

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

9 project-management  waterfall