5 điều trước khi bắt đầu một dự án? [đóng cửa]

5 điều đầu tiên bạn làm trước khi bắt đầu một dự án mới là gì?

Bạn luôn dành một ngày để nghiên cứu các khuôn khổ mới? Hoặc, sử dụng các sản phẩm tương tự hoặc cạnh tranh?

Điều này là khá phụ thuộc vào dự án. Đây có phải là một dự án tôi đang bắt đầu với ý định bán, hoặc một dự án cho một khách hàng cụ thể? Ngoài ra, những gì cấu thành "bắt đầu"? Đó là trước hoặc sau khi thu thập yêu cầu? Một danh sách sơ bộ, mặc dù:

1. Lấy bối cảnh cho dự án. Đó là, tìm hiểu những gì khách hàng hoặc người dùng tiềm năng của bạn đang cố gắng thực hiện và tại sao. Nếu bạn đang xây dựng một hệ thống đăng ký khách sạn, chẳng hạn, có gì sai với các tùy chọn OTS.

2. Thu thập yêu cầu. Gặp gỡ các bên liên quan. Gặp gỡ với người dùng. Gặp gỡ với bất cứ ai có tiếng nói trong dự án, nếu bạn có thể. Nhìn vào các giải pháp hiện có mà dự án này sẽ thay thế, hoặc là khách hàng đang sử dụng hoặc tồn tại trên thị trường. Từ đó, viết tất cả bằng một ngôn ngữ phi kỹ thuật như bạn có thể - một tài liệu reqs tốt sẽ mô tả những việc cần làm nhưng không phải làm thế nào để làm điều đó. Sau đó thảo luận về tài liệu này với khách hàng và lặp đi lặp lại cho đến khi họ đồng ý với nó. Bước này có thể ít chính thức hơn cho các dự án nhỏ hơn (thậm chí có thể hoàn toàn bằng lời nói).

3. Bắt đầu đưa ra quyết định kỹ thuật. Chọn ngôn ngữ, khung, ORM, cơ sở dữ liệu, vv giải quyết vấn đề tốt nhất, cho dù điều này có nghĩa là gắn bó với thứ gì đó bạn biết hoặc học một cái gì đó mới.

4. Phân tích các rủi ro cho dự án này. Nếu đây là hợp đồng của chính phủ, bạn có thể muốn báo cáo rủi ro ràng buộc bằng da 100 trang. Nếu đó là dự án 3 tháng 4 người, bạn có thể ổn với một số ghi chú trong tệp văn bản hoặc bảng tính. Dù bằng cách nào, bạn muốn tìm hiểu điều gì có thể xảy ra với dự án, khả năng xảy ra, mức độ tổn thương và những gì bạn sẽ làm để chuẩn bị cho nó, xử lý và / hoặc giảm thiểu nó tác dụng sau thực tế. Một ví dụ phổ biến là "Một trong những nhà phát triển bị xe buýt đâm, bỏ cuộc, bị ốm, v.v." Vì vậy, bạn có thể giảm thiểu điều đó bằng cách lập trình cặp để chia sẻ kiến ​​thức, sử dụng các thực tiễn kiểm soát nguồn tốt để giữ mã tập trung, v.v. Nói chung,

5. Thiết lập công nghệ. Đó là điều mà không ai muốn làm một khi bạn đang ở trong quá trình mã hóa thực sự, vì vậy hãy thiết lập repo, máy chủ xây dựng, hệ thống xây dựng của bạn, wiki, trình theo dõi lỗi của bạn hoặc bất cứ điều gì bạn định sử dụng cho dự án của bạn.

Tôi sẽ trả lời phần này của câu hỏi, vì đó là phần duy nhất tôi có thể liên quan đến:

Bạn luôn dành một ngày để nghiên cứu các khuôn khổ mới?

Không. Tôi thực sự nghi ngờ rằng thậm chí có thể hoạt động ... Làm thế nào một người nào đó có thể nghiên cứu các khung mới chỉ trong một ngày, trước mỗi dự án và tìm hiểu điều gì đó có liên quan? Nó không xảy ra theo cách đó. Thay vào đó, tôi dành nhiều phần trong ngày, mỗi ngày để nghiên cứu công nghệ khác nhau (không chỉ các khung mới). Nghiên cứu nó không phải là điều tôi làm khi tôi cần. Đó là điều tôi làm mọi lúc và nó đã ở đó khi tôi cần nó ở đó. Lập trình rất thú vị, đó là lý do tại sao tôi tham gia vào công việc này. Bạn không thể ngăn tôi thử những thứ khác nhau mỗi ngày.

Có một nhà văn dành một ngày để thu thập ý tưởng trước khi bắt đầu một cuốn sách mới?