Điều quan trọng là viết các thông số chức năng như thế nào?

Question

Tôi chưa bao giờ viết thông số chức năng, tôi thích nhảy vào mã và thiết kế mọi thứ khi tôi di chuyển. Cho đến nay nó hoạt động tốt, nhưng đối với một dự án cá nhân gần đây, tôi đang viết một số thông số mô tả tất cả các tính năng của sản phẩm và cách nó hoạt động mà không đi sâu vào chi tiết về cách triển khai và tìm thấy nó rất có giá trị.

Suy nghĩ của bạn là gì, bạn có viết thông số kỹ thuật hay bạn chỉ bắt đầu viết mã và lập kế hoạch khi bạn đi và thực hành nào tốt hơn?

Answer 1

Nếu bạn đang lái xe từ nhà đến cửa hàng tạp hóa gần nhất, có thể bạn không cần bản đồ. Nhưng ...

Nếu bạn đang lái xe đến một địa điểm bạn chưa từng đến trước ở một tiểu bang khác, có thể bạn sẽ làm.

Nếu bạn đang lái xe một cách ngẫu nhiên vì niềm vui khi lái xe, có thể bạn không cần bản đồ. Nhưng ...

Nếu bạn đang cố gắng để có được một nơi nào đó trong thời trang hiệu quả nhất (giảm thiểu khoảng cách, giảm thiểu thời gian, thực hiện ba điểm dừng cụ thể trên đường đi, vv) bạn có thể làm.

Nếu bạn đang lái xe một mình và có thể mất bao lâu tùy thích, hãy dừng bất kỳ lúc nào bạn thấy điều thú vị hoặc xem xét lại điểm đến hoặc tuyến đường của bạn, bạn có thể không cần bản đồ. Nhưng ...

Nếu bạn đang lái xe như một phần của đoàn xe vận tải, và tất cả mọi thứ cần phải làm thức ăn và nghỉ qua đêm dừng lại với nhau, và cần phải đến với nhau, bạn có thể làm.

Nếu bạn nghĩ rằng tôi không nói về lập trình, bạn có thể không cần một spec chức năng, thẻ câu chuyện, câu chuyện, CRCs, vv Nhưng ...

Nếu bạn nghĩ rằng tôi, có lẽ bạn muốn xem xét ít nhất một trong những điều trên.

;-)

Answer 2

Điều quan trọng là không để viết cho họ: There's Nothing Functional about a Functional Spec

Answer 3

tôi làm điều đó cả hai cách, nhưng tôi đã học được điều gì đó từ Test Driven Development ...

Nếu bạn đi vào mã hóa với một lộ trình bạn sẽ nhận được đến cuối của chuyến đi một helluva nhiều nhanh hơn bạn sẽ nếu bạn chỉ cần bắt đầu đi bộ xuống đường mà không có bất kỳ ý tưởng về cách nó sẽ ngã ba ở giữa.

Bạn không phải ghi lại mọi chi tiết về mọi chức năng sẽ làm, nhưng xác định những điều cơ bản để bạn biết mình nên làm gì để mọi thứ hoạt động tốt cùng nhau.

Tất cả những gì được nói, tôi cần phải viết một loạt các trình xử lý ngoại lệ ngày hôm qua và tôi chỉ khắc phục ngay mà không cần cố gắng phác họa nó. Có lẽ tôi nên đọc lại lời khuyên của chính mình;)

Answer 4

Đối với người "nhảy vào mã" và "thiết kế khi họ đi", tôi có thể viết bất cứ thứ gì bao gồm thông số chức năng tốt hơn các phương pháp hiện tại của bạn. Bạn có thể tiết kiệm rất nhiều thời gian và công sức nếu bạn dành thời gian suy nghĩ và thiết kế nó trước khi bạn bắt đầu.

• Yêu cầu giúp xác định những gì bạn cần thực hiện.
• Thiết kế giúp xác định những gì bạn định làm.
• Tài liệu người dùng xác định những gì bạn đã thực hiện.

Bạn sẽ thấy rằng hầu hết các địa điểm sẽ có một số biến thể của ba tài liệu này. Thông số chức năng có thể được gộp vào tài liệu thiết kế.

Tôi khuyên bạn nên đọc Rapid Development nếu bạn không bị thuyết phục. Bạn thực sự có thể hoàn thành công việc nhanh hơn nếu bạn dành nhiều thời gian hơn để lập kế hoạch và thiết kế.

Answer 5

Đối với hack một lần và các tiện ích nhỏ, đừng bận tâm.

Nhưng nếu bạn đang viết một ứng dụng lớn, nghiêm túc và có yêu cầu khách hàng và phải chạy trong một thời gian dài thì đó là PHẢI. Đọc phần lớn của Joel articles về chủ đề - đó là một khởi đầu tốt.

Answer 6

Nhảy "thẳng đến mã" cho các dự án phần mềm lớn gần như chắc chắn sẽ dẫn đến thất bại (như immediatley bắt đầu đặt các viên gạch để xây dựng một cây cầu).

Những người ở số 37 Signals sẽ nói tốt hơn là viết một tài liệu ngắn trên giấy hơn là viết một thông số phức tạp. Tôi muốn nói rằng điều này có thể đúng khi chế nhạo nhanh các trang web mới (nơi thiết kế và ý tưởng có thể dẫn đầu tốt hơn lược đồ cứng nhắc), nhưng không phải lúc nào cũng chấp nhận được trong các tình huống thực tế khác.

Chỉ cần nghĩ đến tầm quan trọng (hợp pháp, thậm chí) một tài liệu cụ thể được ký bởi khách hàng của bạn có thể có.

Các tinh thần có lẽ là: hãy linh hoạt, và kế hoạch với thông số kỹ thuật chức năng hoặc kỹ thuật nhiều như bạn cần, theo kịch bản dự án của bạn.

Answer 7

Tôi sẽ nói hoàn toàn "phụ thuộc" vào loại sự cố. Tôi có xu hướng tự hỏi mình là tôi viết nó vì lợi ích của nó hay cho các lớp ở trên bạn. Tôi cũng đã tranh luận về điều này và kinh nghiệm cá nhân của tôi nói, bạn nên vì nó giữ cho dự án theo đúng với những kỳ vọng (thay vì đi ra khỏi khóa học).

Answer 8

Điều mà nhiều người không muốn thừa nhận hoặc nhận ra là phát triển phần mềm là một kỷ luật kỹ thuật. Rất nhiều điều có thể học được về cách chúng tiếp cận mọi thứ. Lập bản đồ ra những gì bạn sẽ làm trong một ứng dụng không nhất thiết phải quan trọng đối với các dự án nhỏ vì thường dễ dàng hơn để nhanh chóng quay trở lại và sửa lỗi của bạn. Bạn không thấy bao nhiêu thời gian là lãng phí so với viết xuống những gì hệ thống sẽ làm đầu tiên.

Trong thực tế trong các dự án lớn, gần như cần thiết để có bản đồ đường đi về cách thức hoạt động của hệ thống và hoạt động của nó. Gọi nó là một Spec chức năng nếu bạn sẽ, nhưng thông thường bạn phải có một cái gì đó có thể cho bạn thấy lý do tại sao bước b sau bước a. Tất cả chúng ta đều nghĩ rằng chúng ta có thể nghĩ rằng nó trên bay (tôi chắc chắn phạm tội này quá), nhưng trong thực tế nó gây ra cho chúng tôi vấn đề. Hãy suy nghĩ lại và tự hỏi mình đã bao nhiêu lần bạn gặp phải điều gì đó và tự nhủ với chính mình "Người đàn ông mà tôi ước gì tôi có thể nghĩ về điều đó sớm hơn?" Hoặc người khác nhìn thấy những gì bạn đã làm và cho bạn thấy rằng bạn có thể thực hiện 3 bước để hoàn thành nhiệm vụ mà bạn đã thực hiện 10.

Đặt nó xuống giấy thực sự buộc bạn phải suy nghĩ về những gì bạn sẽ làm. Một khi nó trên giấy nó không phải là một ý nghĩ nebulous nữa và sau đó bạn có thể nhìn vào nó và đánh giá nếu những gì bạn đang suy nghĩ thực sự có ý nghĩa. Việc thay đổi một tài liệu trang dễ dàng hơn thay đổi 5000 dòng mã.

Answer 9

Nếu bạn đang làm việc trong một XP (hoặc tương tự) môi trường, bạn sẽ sử dụng tầng để hướng dẫn phát triển cùng với rất nhiều đơn vị kiểm tra và hành lang useability (Tôi đã say Kool-Aid, tôi đoán).

Tuy nhiên, có một khu vực nơi yêu cầu tuyệt đối: khi phối hợp với một nhóm bên ngoài. Tôi đã có một dự án với một công ty bảo hiểm lớn, nơi chúng tôi cần có một thỏa thuận về một số hành vi của chương trình, một số khía cạnh của thiết kế cơ sở dữ liệu và một số bố cục tệp. Không có thông số kỹ thuật, tôi đã mở rộng một cách sáng tạo về những gì chúng tôi đã hứa. Đây là những người tốt - tôi tin tưởng họ và thích làm việc với họ. Nhưng mà, nếu không có thông số đó thì đó sẽ là một cuộc diễu hành chết. Với thông số kỹ thuật, tôi luôn có thể chỉ ra nơi họ đã lệch khỏi bố cục được thỏa thuận hoặc nơi họ yêu cầu công việc tùy chỉnh bổ sung ($$!). Nếu làm việc với một mối quan hệ bán đối kháng, spec có thể giúp bạn tiết kiệm từ thậm chí tệ hơn: một vụ kiện.

Ồ vâng, và tôi đồng ý với Kieveli: "nhảy sang mã" gần như không bao giờ là ý tưởng hay.

Answer 10

Tôi hiếm khi cảm thấy cần có thông số chức năng. OTOH Tôi luôn luôn có người dùng chịu trách nhiệm về tính năng gọi điện thoại đi, vì vậy tôi luôn có thể truy vấn chúng cho các yêu cầu chức năng khi tôi đi.

Đối với tôi, đặc tả chức năng là một công cụ chính trị hơn là kỹ thuật. Tôi đoán một khi bạn có một spec bạn luôn có thể đổ lỗi cho spec nếu sau này bạn phát hiện ra vấn đề với việc thực hiện. Nhưng ai để đổ lỗi thực sự là không quan tâm đến tôi, vấn đề vẫn sẽ ở đó ngay cả khi bạn tìm thấy một vật tế thần, tốt hơn sau đó để xem lại việc thực hiện và cố gắng làm điều đó đúng.

Hầu như không thể viết một thông số tốt, bởi vì bạn thực sự không biết đủ về vấn đề hoặc công cụ hoặc thay đổi trong môi trường để làm điều đó đúng. Vì vậy, tôi nghĩ điều quan trọng hơn là thích ứng với một cách tiếp cận nhanh chóng để phát triển và dành đủ nguồn lực và thời gian để xem lại và tái cấu trúc khi bạn đi.

Answer 11

Tôi muốn phân tách mọi vấn đề không tầm thường một cách lỏng lẻo trên giấy trước tiên, thay vì nhảy vào mã, vì một số lý do;

• Những thứ tôi viết trên giấy không phải biên dịch hoặc thực hiện bất kỳ ý nghĩa với một máy tính
• tôi có thể làm việc ở các cấp độ tùy ý trừu tượng trên giấy
• tôi có thể thêm hình ảnh và sơ đồ thực sự dễ dàng
• tôi có thể suy nghĩ thấu đáo và gỡ lỗi một khái niệm rất nhanh chóng

Nếu vấn đề tôi đang đối phó với có khả năng liên quan đến hoặc là một số lượng đáng kể thời gian, hoặc một số người khác, tôi sẽ viết nó lên như một phác thảo chức năng spec. Nếu tôi được người khác trả tiền để phát triển phần mềm, và có bất kỳ tiềm năng nào cho sự mơ hồ, tôi sẽ thêm đủ chi tiết để loại bỏ sự mơ hồ này. Tôi cũng muốn sử dụng tài liệu này làm điểm khởi đầu để phát triển các trường hợp kiểm tra tự động, khi phần mềm đã được viết.

Đặt một cách khác, tôi viết đủ thông số chức năng để hiểu chính xác phần mềm tôi đang viết, và để giải quyết bất kỳ sự mơ hồ nào có thể cho bất kỳ ai khác có liên quan.