ผลิตภัณฑ์ซอฟต์แวร์ควรกำหนดไว้อย่างไรก่อนเริ่มรหัส?


13

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

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

คำถามที่เฉพาะเจาะจงอื่น ๆ อาจจะเป็น:

  1. ปกติใช้เวลาร้อยละของโครงการในขั้นตอนการวางแผนก่อนการพัฒนา

  2. คุณมีเกณฑ์ที่วัดได้บางอย่างที่คุณพยายามทำก่อนเริ่มรหัสหรือมากกว่านั้นคืออะไร?

  3. คุณทำแผนภาพคลาสทั้งหมดก่อนเริ่มรหัสหรือเป็นส่วนใหญ่พยายามสร้างการออกแบบแบบไดนามิกจากจุดเริ่มต้นคาดว่าสิ่งต่าง ๆ จะเปลี่ยนแปลงหรือไม่

ประสบการณ์ใด ๆ ที่คุณยินดีแบ่งปันจะยอดเยี่ยม!

คำตอบ:


10

คำตอบที่แท้จริงของ "คำนิยามที่ดีแค่ไหน" คือ

มีคำจำกัดความเพียงพอที่คุณสามารถเริ่มต้นได้

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

กำหนดไว้อย่างดีพอที่คุณสามารถจัดลำดับความสำคัญการวิ่ง

ฉันหมายถึงการกำหนดกรณีการใช้งาน

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

การวิเคราะห์ความเสี่ยง

โดยทั่วไปแล้วเสียเวลา

การวาดไดอะแกรมของชั้นเรียนเป็นต้น

ถ้ามันช่วย

ปกติใช้เวลาร้อยละของโครงการในขั้นตอนการวางแผนก่อนการพัฒนา

มันแตกต่างกันมาก ซื้อหนังสือดีๆเช่นเศรษฐศาสตร์วิศวกรรมซอฟต์แวร์เพื่อรับหมายเลข "มีอำนาจ"

คุณมีเกณฑ์ที่วัดได้บางอย่างที่คุณพยายามทำก่อนเริ่มรหัสหรือมากกว่านั้นคืออะไร?

"พอประมาณ" แทบจะเป็นไปไม่ได้ที่จะนิยาม

"ไส้" นโยบายไม่ดี

ปัญหาคือ "คุณเข้าใจสิ่งที่คุณทำหรือไม่"

มันไม่ใช่เรื่องทางเดินอาหาร มันเป็นคำถามใช่ / ไม่ใช่

ไม่ใช่ "สามารถวัดได้" เนื่องจากเป็นเพียงคำถามใช่ / ไม่ใช่

และยิ่งไปกว่านั้นคุณต้องจัดลำดับความสำคัญ คุณไม่ทำทุกอย่าง เพียงพอที่จะรับมือกับการวิ่งสองสามครั้งแรก

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

คุณไม่สามารถรู้ทุกสิ่งล่วงหน้า

อย่าลอง


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

ฉันยอมรับว่าคุณไม่สามารถรู้ทุกสิ่งล่วงหน้า แต่อย่างน้อยเอกสารการออกแบบที่ดีจะช่วยคุณระบุขอบเขตและฟีเจอร์คืบเมื่อมันเกิดขึ้น
Tim Post

@Tim Post: คำแนะนำที่ดี นั่นเป็นวิธีในการกำหนด "วิธีที่กำหนดไว้ดี" ในคำถาม มันจะ "ช่วยคุณระบุขอบเขตและคุณสมบัติการคืบ" ไม่มากใช่ไหม
S.Lott

@Tim Post: "ระบุขอบเขต" ทำให้เข้าใจผิด หมายความว่ามีความรู้ที่แน่นอนเกี่ยวกับ "ขอบเขต" ที่มีให้คุณในช่วงเริ่มต้นของโครงการซึ่งไม่เป็นความจริง ขอบเขตจะเปลี่ยนแปลงตลอดวงจรชีวิตของโครงการเนื่องจากความต้องการทางธุรกิจเปลี่ยนแปลงเนื่องจากไม่มีตลาดที่นิ่ง
Rein Henrichs

@ Rein Henrichs: ฉันปรับแต่งคำตอบเล็กน้อยเพื่อรวมประเด็นของคุณ คำจำกัดความของขอบเขตเพียงพอที่จะเริ่มต้น ฉันถูกล่อลวงให้เพิ่ม "และไม่เกินนี้"
S.Lott

2

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

หากลูกค้าของคุณอยู่ไกลและไม่สามารถให้ข้อเสนอแนะได้ในระยะเวลานานข้อมูลจำเพาะของคุณควรมีรายละเอียดมาก

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


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

นั่นคือจุดที่ดีขอบคุณ! ฉันไม่ได้พิจารณาว่าการมีส่วนร่วมของลูกค้าสามารถเปลี่ยนแปลงสิ่งที่ดีที่สุดสำหรับโครงการที่กำหนดได้อย่างไร สิ่งที่ฉันควรทราบ นอกจากนี้ฉันไม่เคยได้ยิน "Planning Poker" และดูเหมือนว่ามันจะมีค่าจริงๆ
drewag

2

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

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

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

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

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

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

As a user, I may manage the Customers;
As a system, I persist changes to the underlying data store;
As a user, I need to enter my credentials to be able to manage customers;
As a system, I have to authenticate the user against the Active Directory;

ร่างแรกของคุณอาจง่ายเหมือนที่! จากนั้นเราจะเห็นได้ว่าความปลอดภัยเป็นส่วนสำคัญในระบบของเรามันสำคัญหรือไม่ที่จะสร้างความสำคัญสูงสุด (Y / N)? สิ่งนี้จะขึ้นอยู่กับข้อกำหนดที่คุณต้องปฏิบัติตาม สมมติว่าการจัดการลูกค้าเป็นสิ่งสำคัญที่สุดที่นี่ ดังนั้นใน Sprint ต่อไปเราต้องสามารถจัดการลูกค้าด้วยวิธีพื้นฐาน แต่เป็นที่ยอมรับ การจัดการลูกค้าคืออะไร

As a user, I may manage Customers;
    -> As a user, I add a customer to the system;
    -> As a user, I change a customer details;
    -> As a user, I delete a customer;
    -> As a system, I flag a deleted customer as being inactive instead of deleting it;
    -> As a user, I need to list the customers;
    -> As a user, I search the customers data bank for a given customer;
    -> ...

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

ฉันหวังว่านี่จะช่วยได้! =)


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

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

1

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

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

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

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


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

1

คุณใช้ภาษาและวิธีการใด

บางภาษาเช่น Java และ C ++ ต้องการโครงสร้างเริ่มต้นมากกว่าภาษาเช่น Common Lisp หรือ Python (C ++ มากกว่า Java เนื่องจากการปรับโครงสร้างใหม่ทำได้ง่ายกว่าใน Java) Leo Brodie (ฉันคิดว่า "Thinking Forth") ให้คำแนะนำสองชิ้นเกี่ยวกับเวลาที่จะเริ่มเขียนโค้ด: เร็วกว่าที่คุณรู้สึกสบายใจใน Forth หลังจากที่คุณต้องการในภาษาอื่น

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

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


ขอบคุณสำหรับมุมมอง ฉันไม่ได้พิจารณาว่าภาษาและแพลตฟอร์มอาจมีผลต่อแนวปฏิบัติที่ดีที่สุดเมื่อพูดถึงการจัดการโครงการ ฉันมักจะพูดถึง Objective-C, UIKit และ AppKit เป็นส่วนใหญ่ อย่างไรก็ตามฉันยังทำงานในภาษาอื่น ๆ (C, C ++, C #, Java, Python, ฯลฯ ) นั่นหมายความว่าฉันควรระวังไม่ให้สันนิษฐานว่าวิธีใดวิธีหนึ่งจะดีที่สุดสำหรับทุกโครงการฉันควรปรับวิธีการของฉันตามแพลตฟอร์มเป้าหมายและภาษา
drewag

1

สองคำศัพท์ที่เป็นประโยชน์ที่นี่คือ MVP (ผลิตภัณฑ์ที่มีศักยภาพขั้นต่ำ) และ MMF (คุณสมบัติที่มีตลาดขั้นต่ำ) MMF เป็นรุ่นที่เล็กที่สุดของฟีเจอร์ที่ให้คุณค่าทางธุรกิจ MVP เป็น MMF ที่น้อยที่สุดที่สามารถใช้งานได้ในฐานะผลิตภัณฑ์ เมื่อเริ่มต้นโครงการสิ่งที่ดีที่สุดที่ต้องทำคือระบุ MMFs และ MVP และเริ่มจากที่นั่น

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


นั่นเป็นคำศัพท์ที่ยอดเยี่ยมจริงๆขอบคุณ! นั่นคือสิ่งที่ดีที่สุดที่นี่ในการหาสิ่งที่สามารถวัดได้ แน่นอนว่ามันไม่สมบูรณ์แบบ แต่ดูเหมือนว่ามันจะสมเหตุสมผลในการตัดสินใจว่าคุณลักษณะนั้นเป็นที่ต้องการของตลาดและ / หรือเพิ่มมูลค่าให้กับผลิตภัณฑ์หรือไม่
drewag
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.