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

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

ทักษะไม่ใช่การเขียนซอฟต์แวร์โดยไม่มีข้อกำหนด แทนที่จะเป็นการดึงความต้องการจากเจ้าของโครงการโดยไม่คำนึงว่ามีเอกสารข้อกำหนดอย่างเป็นทางการหรือไม่

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

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

นี่มันคลุมเครือมาก ...

สองสิ่งที่ฉันสามารถพูดได้:

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

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

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

ความต้องการเป็นขั้นตอนในการเดินทางวิสัยทัศน์คือทิศทาง

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

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

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

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

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

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

สเปคนั้นดี แต่ก็ไม่สมบูรณ์แบบ มีทฤษฎีบทเกี่ยวกับเรื่องนั้นอยู่ คุณไม่สามารถพิสูจน์ได้ว่าข้อมูลจำเพาะเสร็จสมบูรณ์และคุณไม่สามารถพิสูจน์ได้ว่าเครื่องมือไม่มีข้อบกพร่องหรือจะหยุด :)

กระนั้น บริษัท ซอฟต์แวร์ก็ทำการจัดส่งซอฟต์แวร์อยู่ตลอดเวลาแม้จะมีข้อบกพร่องเหล่านี้ในกระบวนการก็ตาม ข้อมูลจำเพาะจะไม่สมบูรณ์แบบ สเป็คยังเป็น UNNATURAL และล้าสมัย สเป็คต่อต้นแบบนั้นเหมือนกับตารางลอการิทึมคือกราฟเดี่ยวสเป็คคือโบรชัวร์ที่น่าเบื่อที่ต้องการพิมพ์ในขณะที่คุณสามารถโต้ตอบกับเครื่องมือ / กราฟแทน ตรวจสอบhttp://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.htmlเพื่อหาแรงบันดาลใจ

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

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

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

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

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

หากคุณต้องการทำงานเป็นนักพัฒนาซอฟต์แวร์ตั้งแต่เริ่มต้นมันเป็นทักษะที่มี

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

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

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

ดังนั้นคุณต้องการหลีกเลี่ยงสถานการณ์ที่คุณไม่ทราบว่าลูกค้าต้องการอะไร แต่คุณจะต้องหลบเลี่ยงสถานการณ์ที่มีความต้องการที่ 'ดีที่สุด' และหลีกเลี่ยงสถานการณ์ที่เลวร้ายที่สุด โปรแกรมเมอร์ที่ดีในโลกแห่งความเป็นจริงต้องมีการปรับตัว

ไม่สามารถเขียนโปรแกรมโดยไม่มีข้อกำหนดได้ แม้แต่ 'Hello World' ก็มีข้อกำหนด: เพื่อสร้างผลผลิต ดังนั้นฉันคิดว่าคุณกำลังถามเกี่ยวกับข้อกำหนดที่เป็นทางการในรูปแบบของกองซ้อนขนาดใหญ่ของสิ่งที่คล้ายกับ UML และเกี่ยวกับสิ่งเหล่านั้นฉันได้พบผู้คน 2 ชนิด:

1) คนที่ต้องการความต้องการอย่างเป็นทางการ พวกเขาจำเป็นต้องได้รับการบอกกล่าวว่าจะต้องทำอะไรและจะทำอย่างไรให้ดีที่สุด พวกเขารักประโยคเช่นขั้นตอนการสละอาร์กิวเมนต์ B ออกจะ Cและพวกเขาเกลียดชังเหล่านั้นโปรแกรมที่ควรจะทำให้การทำงานของห้างสรรพสินค้าของเรามีประสิทธิภาพมากขึ้น พวกมันมักเป็นสัตว์เลี้ยง

2) คนที่ตรงข้ามกับ 1 พวกเขาเกลียดที่จะได้รับการบอกว่าต้องทำอะไรและทำอย่างไรพวกเขาชอบที่จะได้รับการบอกว่าควรทำอะไร พวกเขาชอบพูดคุยกับลูกค้าวิเคราะห์สิ่งที่พวกเขาพูดแล้วพัฒนาโซลูชันของตนเอง พวกเขามักจะเป็นอิสระและไม่เหมาะสมกับ บริษัท

ฉันจะไม่พูดว่าอันไหนดีกว่ากัน ทั้งสองมีข้อดีและข้อเสียของพวกเขา มันง่ายพอสำหรับเงื่อนไขอื่น ๆ

คุณไม่สามารถพัฒนาซอฟต์แวร์ปฏิบัติการโดยไม่ทราบข้อกำหนด แต่คุณสามารถมีแทงดีครึกครื้นที่จะพัฒนาสิ่งที่ประสบการณ์ของคุณบอกคุณต้องการที่มีแนวโน้มเป็น. การพัฒนาแบบ Agile ใช้การผสมผสานของ 'สัญชาตญาณ' รวมถึงกฎ 80:20 และ 'การค้นพบ' ข้อกำหนดโดยการสร้างต้นแบบ กล่าวอีกนัยหนึ่งทีมพัฒนาที่มีประสบการณ์ทำให้คาดเดาสิ่งที่ต้องการได้ดีที่สุดและสร้างต้นแบบของซอฟต์แวร์ กฎ 80:20 บอกว่าพวกเขาจะถูกต้อง 80% ผู้มีส่วนได้ส่วนเสียของโครงการจะทบทวนต้นแบบที่มีตัวตน ข้อเสนอแนะของพวกเขาเริ่มเติมช่องว่าง 20% ในการทำความเข้าใจข้อกำหนด ดังนั้นโดยทั่วไปแล้ว Agile ไม่ได้เกี่ยวกับการเขียนซอฟต์แวร์โดยไม่มีข้อกำหนดใด ๆ แต่มันเกี่ยวกับการใช้ประสบการณ์ก่อนหน้าของคุณในการพูดว่า "คุณต้องการสิ่งนี้หรือไม่?" ซึ่งใน 80% ของกรณีนี้จะช่วยให้คุณกระโดดไปข้างหน้าและยืนยันสิ่งที่จำเป็นจริงๆได้เร็วกว่าการพุ่งผ่านกระบวนการความต้องการแบบดั้งเดิม

ใครบอกว่า Agile เขียนโค้ดโดยไม่ต้องมีข้อกำหนด? ฉันรู้ว่า Manifesto ตีความบางอย่างด้วยวิธีนี้ ... แต่มันก็ไม่ถูกต้อง