Làm thế nào để lên kế hoạch cho các dự án phần mềm khổng lồ?

Question

Chúng tôi đã bắt đầu một dự án lớn. Chúng ta biết nó trông như thế nào nhưng không phải là cách để thực hiện nó. Chúng tôi bắt đầu bằng cách viết các mẫu thử nghiệm để kiểm tra các triển khai khác nhau. Những gì chúng ta thiếu là tổng quan về tiến độ phát triển tổng thể. Chúng tôi không biết liệu chúng tôi có dành quá nhiều thời gian vào chi tiết hay không hoặc liệu các chi tiết đó có đủ quan trọng để dành thời gian không.

Tôi đã bắt đầu bằng cách tạo danh sách các tác vụ chúng tôi phải làm, những thứ như "triển khai tính năng X", "kiểm tra cách triển khai Y". Bây giờ tôi có một bản đồ tâm trí khổng lồ với khoảng 500 nhiệm vụ. Bước tiếp theo tôi có thể làm là xác định sự phụ thuộc giữa các nhiệm vụ. Bằng cách này tôi muốn biết những gì để thực hiện đầu tiên và các nhiệm vụ được phụ thuộc nhiều nhất là những người quan trọng nhất. Nhưng tôi không thể thực hiện loại thứ tự này bằng công cụ bản đồ tâm trí. Nó rất bực bội.

Bạn lập kế hoạch cho các dự án phần mềm lớn như thế nào?

Answer 1

Đây là những gì giúp tôi để bắt đầu:

[1 ] Bắt đầu với một tài liệu yêu cầu. Viết từ quan điểm của khách hàng. Viết tất cả mọi thứ xuống những gì phần mềm sẽ có thể làm. Tránh đưa ra các giải pháp. Hãy rõ ràng. Nếu một chức năng sẽ nhận được đầu vào xác định chính xác những gì nó có thể mong đợi, bao nhiêu nó sẽ mong đợi và làm thế nào nó nên hành động trong các tình huống lỗi.

Đừng quên chỉ định giới hạn. Mọi thứ đều có giới hạn. Nếu giải pháp của bạn sẽ quản lý các tài khoản có bao nhiêu giải pháp có thể xử lý? 20 hay 10 triệu?

Tài liệu yêu cầu của bạn phải bao gồm các yêu cầu chức năng và không yêu cầu chức năng. Không yêu cầu chức năng là: hiệu suất, tính ổn định, sử dụng tài nguyên, bảo mật và vân vân.

[2] Khi bạn hoàn tất việc chỉ định yêu cầu, hãy cung cấp mọi yêu cầu về điểm quan trọng: phải có, quan trọng, tùy chọn.

[3] Bây giờ viết một tài liệu mà bạn chỉ định cách mọi yêu cầu sẽ được thực hiện. Hãy cẩn thận với các chi tiết. Đừng đi sâu. Đi cho quy tắc 20/80. Chỉ định 20% chức năng chuyên sâu sẽ ảnh hưởng đến 80% dung dịch.

Bạn có thể sẽ nhận thấy rằng bạn không thể mô tả cách mọi yêu cầu sẽ được thực hiện. Nó là ok để viết "Tôi không có một đầu mối làm thế nào để thực hiện điều này". Nhưng điều quan trọng là bạn viết nó xuống! Số tiền "không biết" sẽ cho bạn biết mức độ rủi ro của dự án của bạn.

[4] Bước tiếp theo là tạo danh sách nhiệm vụ. Bạn sẽ cần phải biết những gì thực sự bạn phải làm. Đối với mọi yêu cầu, bạn sẽ có một vài nhiệm vụ để thực hiện.

Một trong những tác vụ đó là tìm hiểu cách triển khai các yêu cầu "không biết". Đừng cố gắng làm rõ mọi "không biết". Đi cho những cái phải có và những cái quan trọng. Làm rõ một số "không biết" thậm chí có thể là một tiểu dự án nhỏ.

[5] Khi bạn có nhiệm vụ ước tính thời gian bạn cần hoàn thành chúng. Đừng ngại ước tính. Không thể ước tính chính xác khi bạn đang ở đầu dự án. Khi dự án di chuyển, bạn sẽ ước tính lại các nhiệm vụ và ước tính của bạn sẽ chính xác hơn.

Tôi rất hữu ích khi gọi ba ước tính điểm. Ước tính thời gian bạn sẽ cần nếu mọi thứ diễn ra suôn sẻ. Đây là thời điểm lạc quan. Sau đó, ước tính sẽ mất bao lâu nếu bạn gặp phải vấn đề. Đây là thời điểm bi quan của bạn. Sau đó ước tính thời gian thực tế. Khoảng cách giữa thời gian lạc quan và bi quan sẽ cho bạn biết bạn không chắc chắn về việc triển khai.

[6] Bây giờ bạn sẽ phải thực hiện các tác vụ theo thứ tự chúng sẽ được triển khai. Một số nhiệm vụ sẽ có các phụ thuộc mà đơn đặt hàng của bạn sẽ phải phản ánh. Có một công cụ rất tốt để giúp bạn hình dung thứ tự này: bức tường văn phòng của bạn. Viết các nhiệm vụ của bạn lên hậu kỳ và đặt chúng lên tường. Nghiêm túc. Nó làm việc rất tốt cho tôi.

[7] Bây giờ bạn đã ở giữa dự án của mình. Tổng số ước tính của bạn sẽ cho bạn hai ngày phát hành (sự lạc quan và bi quan). Bạn có thể đặt đá dặm. Cập nhật các ước tính cho các tác vụ của bạn theo định kỳ. Thay đổi ngày phát hành đã tính sẽ cho bạn biết bạn đang thực hiện như thế nào.

Answer 2

Làm công việc của bạn trong các lần lặp lại. Tập trung vào những gì cần thiết cho một lần lặp lại cụ thể. nếu bạn sẽ tập trung vào tất cả các chi tiết cùng một lúc, bạn sẽ thất bại.

Trước hết, hãy quyết định xem bạn muốn có và thiết kế những chức năng chung nào.

Trên các bước tiếp theo, bạn sẽ thêm ngày càng nhiều tính năng nâng cao.

Khi bạn có khung dây kiến ​​trúc ổn định, bạn có thể chia dự án thành các mô-đun và phân phối chúng cho một số nhóm. Các đội cũng sẽ làm việc trong các lần lặp.

Không ai có thể thiết kế dự án phần mềm lớn ngay từ đầu. Dự án lớn đang phát triển chậm, với tất cả các vấn đề thời thơ ấu bình thường.

Answer 3

Có một số bài viết và sách hay về chủ đề này. Nhưng tóm lại, cắt giảm sự phụ thuộc, giữ mọi thứ đơn giản nhưng linh hoạt, và bắt đầu bằng cách viết các thành phần có thể mã hóa nhanh - điều này mang đến cho bạn cảm giác tốt hơn về cách bạn sẽ cần làm mọi thứ. Chuẩn bị cho các thiết kế của bạn để phát triển và chuẩn bị viết lại khá nhiều mã.

Đừng cố gắng viết hệ thống hoàn hảo từ đầu. Đặt ra để viết một hệ thống đơn giản và cuối cùng bạn có thể viết hệ thống hoàn hảo.

Answer 4

Mỗi lần cắn một lần.

Nghiêm túc, nhìn vào toàn bộ điều là tốt miễn là bạn không hoàn toàn tập trung. Chúng ta phải chia nó thành các dự án nhỏ hơn và nhỏ hơn cho đến khi chúng ta có thể có được vòng tay của chúng ta.

Nếu bạn chưa đi theo cách này, bất kỳ phương pháp Agile nào hoạt động tốt nhất. Scrum tuyệt vời, XP là tốt. Những lần sử dụng lặp lại này, đó là nhận được ít bit của functionalitiy ra càng nhanh càng tốt.

Cố gắng nắm lấy vòng tay của bạn xung quanh toàn bộ vấn đề thực sự, thực sự khó khăn và tôi thấy nó cực kỳ giảm tốc. Nhưng với một kỹ thuật Agile, người dùng thấy sự tiến bộ ngay lập tức và nhóm của chúng tôi bị kích thích vì mã của họ đang được sử dụng trong cuộc sống thực.

Answer 5

Tất cả điều này phải đến từ tài liệu yêu cầu dự án, điều này sẽ cho bạn biết các tính năng nào thực sự là yêu cầu và tính năng nào được thêm vào trong phạm vi creep. Hãy chắc chắn rằng bạn thực hiện những gì họ muốn.

Lời khuyên của tôi luôn nói chuyện với người bạn cần để cung cấp dự án, hãy đưa ra lịch biểu khi bạn sẽ có tính năng quan trọng x hoàn thành. Tìm hiểu những gì phải được thực hiện là một sự khởi đầu thông qua một tài liệu yêu cầu và cho các dự án lớn (và nhỏ) ưu tiên đặt trên nhiệm vụ nào cần được phân phối trước tiên.

Nói chuyện nói chuyện là cách tốt nhất để đảm bảo mọi người đều biết điều gì đang diễn ra mọi lúc.

Answer 6

Bắt đầu bằng 1 mảnh, phát triển nó, hoàn thiện và học hỏi từ nó. Một khi bạn đã làm điều này, di chuyển lên phần tiếp theo. Khi bạn thực hiện từng phần, hãy thêm vào thư viện có thể sử dụng lại mã của bạn. Khi bạn đi, quá trình sẽ trở nên tinh tế hơn và thời gian phát triển sẽ giảm đi. Điều tồi tệ nhất bạn có thể làm là phát triển toàn bộ điều trong cách tiếp cận dựa trên thác nước. Nhận một cái gì đó làm việc và hoàn thiện nó, điều này sẽ không chỉ cho phép bạn để hiển thị các mảnh làm việc ông chủ, nhưng cũng cho phép bạn tìm sự cân bằng tự nhiên của bạn giữa lập kế hoạch và mã hóa.

Nếu bạn muốn có một cách chính thức để lên kế hoạch, tôi sẽ khuyên bạn nên phát triển nhanh. Nó sẽ cung cấp cho bạn một hướng dẫn tốt về cách lập kế hoạch nhiệm vụ của bạn và thực hiện chúng. Nhưng tôi vẫn nghĩ rằng một nhóm phát triển sẽ rơi vào nhịp điệu mà các suite tốt nhất và cách tiếp cận gia tăng sẽ cho phép điều này.

Answer 7

Rõ ràng bạn muốn phá vỡ nó xuống tại mảnh nhỏ hơn, hãy nhớ khi thực hiện (Structure Làm việc Breakdown) WBS không chỉ phá vỡ nó xuống thành từng mảnh nhỏ, nhưng để thêm:

• xác định những mảnh sẽ đã làm việc đầu tiên (ưu tiên cho những doanh nghiệp quan trọng nhất)
• kế hoạch phân phối, nhiều dự án phân phối mã nhưng sau đó có thời gian khó khăn trong việc quảng cáo, lập kế hoạch cho mỗi bản phát hành và tác động tiềm năng đến người dùng
• /nhanh chóng - không có gì xây dựng sự tự tin như chiến thắng sớm
• phát triển kế hoạch truyền thông của bạn - ai cần biết gì và khi nào - Ví dụ: cho mỗi bản phát hành lặp lại cần được thông báo về thay đổi/tác động
• xác định xem bạn có đánh giá lại phản hồi trong khi phát hành hay không hoặc chức năng được thay đổi
• nhận ra rằng sớm bạn phát hành để sản xuất sớm hơn bạn cần phải hỗ trợ nó cũng như tiếp tục với sự phát triển