ฉันจะเขียนข้อกำหนดการทำงานได้อย่างรวดเร็วและมีประสิทธิภาพได้อย่างไร


17

ดังนั้นฉันเพิ่งอ่านบทความนิยายโดยโจเอลในรายละเอียดที่นี่ (เขียนในปี 2000 !!) ฉันอ่านทั้งหมด 4 ส่วน แต่ฉันกำลังมองหาวิธีการบางอย่างในการเขียนสเป็คของฉัน

ฉันเป็นคนโดดเดี่ยวคนเดียวที่ทำงานกับแอพที่ค่อนข้างซับซ้อน (หรือตระกูลแอพ) สำหรับ บริษัท ทางการเงินที่รู้จักกันดี

ฉันไม่เคยทำอะไรที่ร้ายแรงขนาดนี้มาก่อนฉันเริ่มเขียนบางอย่างเช่นสเป็คที่ไม่ดีภาพรวมของบางอย่างและมันเสียเวลาไปมาก

ฉันได้สร้าง 3 mockup-kinda-thingies ให้กับลูกค้าของฉันดังนั้นฉันจึงมีความเข้าใจในสิ่งที่พวกเขาต้องการ (ตัวอย่างแอพพลิเคชั่นที่ใช้งานไม่ได้กับเวิร์กโฟลว์พื้นฐานที่สุด) และฉันเพิ่งเขียนและทดสอบระบบหลัก / ฐานบางส่วนเท่านั้น

ฉันคิดว่าความผิดพลาดที่ฉันทำไปแล้วไม่ได้เขียนสเป็คอย่างละเอียดดังนั้นตอนนี้ฉันไปถึงแล้ว

ดังนั้นสิ่งทั้งหมดจึงประกอบด้วย

  • เว็บไซต์ MVC (สำหรับผู้ดูแลระบบ & การดูข้อมูล)
  • โมดูล Silverlight 2 โมดูล (สำหรับงานเฉพาะ 2 งาน)
  • 1 แอปพลิเคชันเดสก์ท็อป

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

  • ดังนั้นวิธีการที่ฉันจะไปเกี่ยวกับเรื่องนี้ฉันกำลังมองหาเคล็ดลับใด ๆ สิ่งที่โลกจริงใด ๆ วิธีการที่พวกคุณมักจะทำมันได้หรือไม่
  • คุณสร้างหน้าจอจำลองของทุกบทสนทนา / แบบฟอร์ม / หน้า?

ฉันกำลังคิดที่จะสร้างโครงการ ASP.NET Web Forms จากนั้นเติมไฟล์HTMLในโฟลเดอร์และทำให้ดูเหมือนโครงสร้าง MVC URL ของฉัน

จากนั้นให้มีส่วนในข้อมูลจำเพาะของเว็บไซต์และเขียนหน้าสำหรับ URL ทุกอันที่ฉันมีพร้อมกับหน้าจอ

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


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

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

ถ้าฉันได้รับการออกแบบเบื้องต้นฉันจะมีธุรกิจที่ยอดเยี่ยมกับ บริษัท นี้อยู่แล้วมีหลายอย่างที่คิดเกี่ยวกับฟีเจอร์ "สุดยอด" ใหม่ที่พวกเขาพร้อมที่จะจ่าย


นี่สำหรับคุณหรือเปล่า ลูกค้าร้องขอหรือไม่ คุณคาดหวังว่านักพัฒนาซอฟต์แวร์เพิ่มเติมจะเข้าร่วมทีมหรือไม่
JeffO

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

คำตอบ:


22

คุณอ่านส่วนที่ 2ของบทความหรือตัวอย่างสเปคของเขาหรือไม่? พวกเขารวบรวมหลักการสำคัญสองสามข้อเมื่อเขียนสเปค

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

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

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


เกี่ยวกับการเขียน

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

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

+1 ขอบคุณสำหรับคำตอบของคุณ อ๋อ ฉันอ่านบทความของ Joels ทั้งสี่ส่วนแล้ว แล้วกระบวนการ screenie ทั้งหมดฉันจะสร้างหน้าตาและหน้าตาแบบ (ดูธรรมดา) เป็นคนแรกหรือเปล่า? เพื่อให้ฉันรู้ว่าสิ่งที่ฉันต้องเขียน? หรือฉันจะเริ่มเขียน?
gideon

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