Làm thế nào xác định tốt một sản phẩm phần mềm trước khi bắt đầu mã?


13

Tôi muốn biết mọi người thường định nghĩa tốt như thế nào về một sản phẩm phần mềm trước khi thực sự bắt đầu viết mã và nó đã hoạt động tốt như thế nào đối với họ? Tôi đang đề cập đến việc xác định các trường hợp sử dụng, phân tích rủi ro, vẽ sơ đồ lớp, v.v.

Tôi biết rằng nên có một ý tưởng đủ tốt về sản phẩm cuối cùng sẽ là gì để có thể tránh rủi ro trong tương lai, nhưng điều quan trọng là không định nghĩa một sản phẩm tốt đến mức khó thích nghi với thay đổi.

Các câu hỏi cụ thể khác có lẽ sẽ là:

  1. Bao nhiêu phần trăm thời gian của dự án thường được sử dụng trong các giai đoạn lập kế hoạch trước khi phát triển?

  2. Bạn có một số tiêu chí có thể đo lường nhất định mà bạn cố gắng đáp ứng trước khi bắt đầu viết mã hoặc là một điều gì đó không?

  3. Bạn có sơ đồ tất cả các lớp trước khi bắt đầu viết mã, hoặc chủ yếu là cố gắng tạo ra một thiết kế động ngay từ đầu để mong rằng mọi thứ sẽ thay đổi?

Bất kỳ kinh nghiệm bạn muốn chia sẻ sẽ là tuyệt vời!

Câu trả lời:


10

Câu trả lời theo nghĩa đen cho "làm thế nào xác định tốt?" Là

Xác định rõ đủ để bạn có thể bắt đầu.

Xác định rõ đủ để bạn có thể xác định phạm vi công việc ban đầu (đối với một khái niệm ban đầu). Điều này là vừa đủ để giúp xác định những thay đổi chắc chắn sẽ xảy ra.

Xác định rõ đủ để bạn có thể ưu tiên chạy nước rút.

Tôi đang đề cập đến việc xác định các trường hợp sử dụng,

Luôn luôn hữu ích. Nhưng không phải tất cả . Bạn phải ưu tiên và bao gồm các trường hợp sử dụng quan trọng đầu tiên. Các trường hợp sử dụng khác sẽ được đề cập trong các phiên bản sau. Một số trường hợp sử dụng sẽ có mức độ ưu tiên thấp đến mức họ sẽ không bao giờ hoàn thành.

phân tích rủi ro,

Nói chung là lãng phí thời gian.

vẽ sơ đồ lớp, v.v.

Nếu nó giúp.

Bao nhiêu phần trăm thời gian của dự án thường được sử dụng trong các giai đoạn lập kế hoạch trước khi phát triển?

Nó thay đổi rất nhiều. Mua một cuốn sách hay, như Kinh tế Kỹ thuật phần mềm để có được những con số "có thẩm quyền".

Bạn có một số tiêu chí có thể đo lường nhất định mà bạn cố gắng đáp ứng trước khi bắt đầu viết mã hoặc là một điều gì đó không?

"Có thể đo lường được". Điều đó gần như không thể định nghĩa.

"ruột". Chính sách tồi.

Vấn đề là "bạn có hiểu bạn đang làm gì không?"

Đó không phải là một điều ruột. Đó là câu hỏi Có / Không.

Nó không "đo lường được" vì nó chỉ là câu hỏi có / không.

Và, hơn nữa, bạn phải ưu tiên. Bạn không làm mọi thứ. Chỉ cần đủ để xử lý một vài lần chạy nước rút đầu tiên.

Bạn có sơ đồ tất cả các lớp trước khi bắt đầu viết mã, hoặc chủ yếu là cố gắng tạo ra một thiết kế động ngay từ đầu để mong rằng mọi thứ sẽ thay đổi?

Bạn không thể biết trước mọi thứ.

Đừng cố gắng.


cá nhân tôi thấy việc dành quá nhiều thời gian để viết sơ đồ lớp là một sự lãng phí thời gian vì mô hình và mã với nó thay đổi sau khi bạn bắt đầu.
AndersK

Tôi đồng ý rằng bạn không thể biết trước mọi thứ, nhưng một tài liệu thiết kế tốt ít nhất sẽ giúp bạn xác định phạm vi và tính năng creep khi nó xảy ra.
Tim Post

@Tim Post: Gợi ý hay. Đó là một cách để xác định "cách xác định rõ" trong câu hỏi. Nó sẽ "giúp bạn xác định phạm vi và tính năng creep." Không nhiều nữa, phải không?
S.Lott

@Tim Đăng: "xác định phạm vi" là sai lệch. Nó ngụ ý rằng có một số kiến ​​thức nhất định về "phạm vi" có sẵn cho bạn khi bắt đầu dự án, điều này không đúng. Phạm vi sẽ thay đổi trong suốt vòng đời của dự án khi nhu cầu kinh doanh thay đổi, bởi vì không có thị trường nào là tĩnh.
Rein Henrichs

@Rein Henrichs: Tôi điều chỉnh câu trả lời một chút để kết hợp quan điểm của bạn. Đủ định nghĩa phạm vi để bắt đầu. Tôi muốn thêm "và không còn nữa."
S.Lott

2

Nếu khách hàng của bạn tích cực tham gia dự án với tư cách là thành viên của nhóm dự án, người sẵn sàng cho các nhà phát triển cho câu hỏi và đưa ra quyết định nhanh chóng về chức năng. Sau đó, thông số kỹ thuật có thể ít chi tiết hơn.

Nếu khách hàng của bạn ở xa và không có sẵn để phản hồi trong một khoảng thời gian dài, thì thông số kỹ thuật của bạn sẽ rất chi tiết.

Tại công ty của chúng tôi, chúng tôi tạo các câu chuyện của người dùng và chơi Planning Poker với các nhà phát triển trong dự án. Điều đó cho chúng ta một dấu hiệu công bằng về số giờ dành cho câu chuyện của người dùng.


"Đại diện khách hàng" (vai trò bạn đề xuất cho khách hàng) là vai trò quan trọng nhất trong toàn bộ nhóm. Nếu nhóm của bạn không thể nhận được câu trả lời cho các câu hỏi về sản phẩm và kinh doanh, làm thế nào để họ đưa ra quyết định đúng đắn?
Rein Henrichs

Đó là một điểm tuyệt vời, cảm ơn bạn! Tôi đã không xem xét làm thế nào sự tham gia của khách hàng có thể thay đổi mạnh mẽ những gì hoạt động tốt nhất cho một dự án nhất định. Chắc chắn một cái gì đó tôi nên ghi nhớ. Ngoài ra, tôi chưa bao giờ nghe nói về "Kế hoạch chơi bài" và có vẻ như nó sẽ thực sự có giá trị.
vẽ

2

Làm thế nào xác định rõ dự án cần phải đủ tốt để bạn bắt đầu và biết nơi bạn sẽ đến trong hai tuần tới.

Là một Scrum Master, tôi chỉ đơn giản nói rằng bạn cần xác định các tính năng tổng thể của sản phẩm trong một bảng Excel hoặc bất cứ nơi nào khác, chỉ để theo dõi các tính năng của bạn. Làm cho họ Câu chuyện người dùng giúp suy nghĩ rất nhiều về tính năng bạn cần tiếp theo. Sau đó, ưu tiên chúng: Tính năng quan trọng nhất hoặc bắt buộc lên hàng đầu và ít nhất là thấp nhất.

Sau khi bạn đã liệt kê một số tính năng quan trọng nhất, hãy chọn các tính năng bạn nghĩ bạn có thể phát triển mang đến trạng thái Xong sau một khoảng thời gian hai tuần hoặc một tháng nếu bạn thích. Sau đó, khám phá các tính năng được chọn này để bạn có thể bắt đầu mã hóa trong một vài.

Trong khi mã hóa, chắc chắn bạn sẽ nghĩ đến các yếu tố khác cần được phát triển để đưa các tính năng đã chọn của bạn ở trạng thái Xong. Xong có nghĩa là bạn không còn gì để làm, nghĩa là kiểm tra, mã hóa, lắp ráp, tài liệu đã xong!

Trong bất kỳ lúc nào, danh sách các tính năng được chọn của bạn có thể mở rộng, miễn là bạn đạt được mục tiêu, nghĩa là bạn có thể phát triển mọi thứ bạn nói bạn đã làm trong khoảng thời gian nhất định.

Tóm lại, không có gì phải hoàn hảo. Đưa ra một số ý tưởng, chia sẻ với các đồng chí của bạn và xem liệu những gì được viết có ý nghĩa để đáp ứng với các yêu cầu sản phẩm yêu cầu. Nếu vậy, thì bạn đang ở! Để làm rõ, tôi sẽ sử dụng một sản phẩm Quản lý khách hàng đơn giản. Cần gì?

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;

Dự thảo đầu tiên của bạn có thể đơn giản như vậy! Sau đó, chúng ta có thể thấy rằng bảo mật là một phần quan trọng trong hệ thống của chúng ta, nó có đủ quan trọng để thực hiện ưu tiên cuối cùng (Y / N) không? Điều này sẽ phụ thuộc vào các yêu cầu bạn phải đáp ứng. Hãy nói rằng Quản lý khách hàng là điều quan trọng nhất ở đây. Vì vậy, trong Sprint tiếp theo, chúng tôi cần có khả năng quản lý khách hàng theo cách cơ bản nhưng có thể chấp nhận được. Quản lý khách hàng là gì?

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;
    -> ...

Điều này đã minh họa đủ chức năng để có thể bắt đầu phát triển ứng dụng. Nếu các lập trình viên của bạn cần hướng dẫn thêm, thì có lẽ một nhà phát triển thoải mái với sơ đồ lớp có thể thiết kế lớp Khách hàng và các thuộc tính và phương thức của nó! Nhưng theo như tôi quan tâm, với vài điều tôi đã viết, tôi sẽ có đủ để bắt đầu. Một số tính năng có thể được thêm hoặc thay đổi trên đường đi. Điều quan trọng là tập trung vào những gì bạn nói sẽ được thực hiện. Trong ví dụ của chúng tôi, đó là điều Quản lý khách hàng. Chúng tôi không cần quan tâm đến xác thực người dùng kể từ bây giờ Điều này sẽ đến sau trong Sprint tiếp theo.

Tôi hi vọng cái này giúp được! =)


Cám ơn rất nhiều! Thật tuyệt khi thấy điều này trong một kịch bản cụ thể như vậy. Tôi cảm thấy như đây là một khuôn khổ tốt để có một cái gì đó ít nhất có thể đo lường được phần nào liên quan đến những gì bạn định nghĩa về tổng thể sản phẩm nhưng nhấn mạnh các yếu tố phụ và cách tiếp cận theo định hướng tính năng. Cách tiếp cận này chắc chắn sẽ rất quan trọng khi tôi bắt đầu các dự án mới trong tương lai!
vẽ

Không có gì! Tôi rất vui vì hạt muối của tôi có thể giúp bạn! =) Điều quan trọng là không xác định quá nhiều tính năng chuyên sâu, vì các yêu cầu sản phẩm có thể thay đổi trên đường đi vì khách hàng, khi anh ta sẽ thấy những gì bạn đã thực hiện cho đến nay, có thể có ý tưởng hoặc thay đổi khác để thực hiện những gì bạn đã làm Làm xong. Bạn sẽ cần điều chỉnh sản phẩm cho phù hợp để đáp ứng các yêu cầu mới. Vì vậy, nếu bạn thiết lập toàn bộ mọi thứ cùng một lúc khi bắt đầu dự án, hãy tưởng tượng việc mất việc này có thể gây ra! Có lẽ bạn sẽ làm việc hàng giờ chỉ để vứt nó đi và khởi động lại từ đầu. Hãy để nó phát triển =)
Will Marcouiller

1

Chà, điều làm việc tuyệt vời đối với tôi là có chức năng "khá tốt" được chỉ định và kiến ​​trúc phần mềm chỉ rất đặc biệt.

Để tôi bắt đầu làm việc, tôi cần biết những gì tôi đang làm. Nó không hoạt động với tôi khi tôi chỉ hiểu nhu cầu của khách hàng. Ngay cả khi tôi đang viết một công cụ cho mục đích sử dụng của riêng mình, tôi vẽ màn hình, mô tả chức năng, mỗi nút làm gì, mọi thứ. Nếu không, tôi thấy tôi không thể bắt đầu.

Mặt khác, tôi đã từ bỏ việc thực sự rút ra chính xác cách tôi sẽ phát triển mã. Có thể đây là một thực hành tồi tệ nhất, nhưng nó hiệu quả với tôi. Tôi có thể định nghĩa một tập hợp các bảng cơ sở dữ liệu mà tôi sẽ tạo, nhưng không phải là các cột trong mỗi bảng. Tôi có thể nghĩ về những đối tượng và lớp tôi cần, nhưng tôi chắc chắn không vẽ sơ đồ.

Chết tiệt, đôi khi tôi thậm chí không biết làm thế nào cho đến khi tôi làm sai. Tôi xây dựng nó một lần, xé nó ra, và làm lại, bây giờ tôi biết làm thế nào. Tại thời điểm này tôi có thể vẽ một lộ trình khá chi tiết và khởi động lại.


Cảm ơn vì đã chia sẽ kinh nghiệm của bạn. Dường như đi cùng với sự đồng thuận rằng điều quan trọng là bạn, với tư cách là nhà phát triển, cảm thấy đủ thoải mái để bắt đầu. Tất nhiên bạn sẽ khám phá ra những điều bạn sẽ thay đổi nếu bạn phải làm lại, nếu không bạn đã dành quá nhiều thời gian lên kế hoạch. Tôi biết cảm giác muốn viết lại hoàn chỉnh ngay sau khi sản phẩm hoàn thành, và đó là những gì tôi đang cố gắng tránh;) (ít nhất là ở mức độ hợp lý).
drewag

1

Bạn đang sử dụng ngôn ngữ và phương pháp nào?

Một số ngôn ngữ, như Java và C ++, yêu cầu cấu trúc ban đầu nhiều hơn các ngôn ngữ như Common Lisp hoặc Python (C ++ nhiều hơn Java, vì việc tái cấu trúc dễ dàng hơn trong Java). Leo Brodie (tôi nghĩ trong "Thinking Forth") đã đưa ra hai lời khuyên về khi nào nên bắt đầu viết mã: sớm hơn bạn cảm thấy thoải mái với Forth, muộn hơn bạn muốn bằng ngôn ngữ khác.

Phương pháp thác nước (đặc biệt là khi thiết kế ban đầu có thể giao được) sẽ đòi hỏi nhiều công việc trước hơn là nhanh nhẹn (mặc dù bạn cũng không muốn bỏ qua kế hoạch sớm trong các phương pháp nhanh). Có một bộ kiểm tra tự động tốt giúp an toàn hơn khi thay đổi những thứ lớn hơn, và do đó cho phép bạn có được bằng cách làm việc ít hơn trước.

Ngoài ra, nó phụ thuộc vào từng cá nhân và sự quen thuộc của họ với loại phần mềm được tạo. Tại một thời điểm, khi thực hiện các ứng dụng CRUD chủ yếu, tôi có thể viết toàn bộ chương trình bắt đầu bằng một vài thông số kỹ thuật và một mẩu giấy trắng 3 "x5". Tôi không thể viết những thứ tôi viết bây giờ như thế.


Cảm ơn cho quan điểm. Tôi đã không xem xét làm thế nào ngôn ngữ và nền tảng có thể ảnh hưởng đến các thực tiễn tốt nhất khi nói đến quản lý dự án. Tôi tình cờ nói về Objective-C, UIKit và AppKit. Tuy nhiên tôi cũng làm việc trong một loạt các ngôn ngữ khác (C, C ++, C #, Java, Python, v.v.). Điều đó có nghĩa là tôi nên cẩn thận đừng cho rằng một phương pháp nhất định sẽ tốt nhất cho tất cả các dự án, tôi nên điều chỉnh phương pháp của mình dựa trên nền tảng và ngôn ngữ đích (và có thể chọn ngôn ngữ dựa trên đó nếu tôi có lựa chọn).
drewag

1

Hai thuật ngữ hữu ích ở đây là MVP (Sản phẩm khả thi tối thiểu) và MMF (Tính năng thị trường tối thiểu). MMF là phiên bản nhỏ nhất của một tính năng mang lại giá trị kinh doanh. MVP là MMF ít nhất có thể tồn tại dưới dạng sản phẩm. Khi bắt đầu một dự án, điều tốt nhất để làm là xác định MMF và MVP và bắt đầu từ đó.

Phát hành sản phẩm của bạn ngay khi nó khả thi, sau đó tiếp tục cải thiện dần dần.


Đó là một số thuật ngữ thực sự tuyệt vời, cảm ơn! Đó là điều tốt nhất ở đây để đưa ra một cái gì đó có thể đo lường được. Tất nhiên nó không hoàn hảo, nhưng có vẻ như sẽ rất dễ dàng để quyết định xem một tính năng có bán được trên thị trường hay không và / hoặc nó làm tăng giá trị cho sản phẩm.
drewag
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.