Tôi có nên sử dụng scrum cho các dự án lớn? [đóng cửa]

Tôi đã làm việc như một lập trình viên cho một dự án được thiết kế cho phần mềm chung cho các trạm xăng (sẽ được phân phối lại cho nhiều khách hàng) trong 18 tháng. Dự án lớn. Hôm nay chúng tôi có khoảng 150 bàn. Chúng tôi đã không sử dụng một chương trình cụ thể, nó không được quản lý tốt.

Bảng người có ngày hôm nay khoảng 70 cột, nhưng 15 tháng trước nó có khoảng 30 cột. Những lĩnh vực mới này đã xuất hiện để tích hợp với các mô-đun khác như bán hàng, tài chính và kế toán. Ngoài ra nhiều lĩnh vực đã được tạo ra sau đó bị xóa.

Kết quả là, chúng tôi đã có nhiều lần tái cấu trúc và làm lại. Dự án không bao giờ sẵn sàng vì luôn có những yêu cầu mới xuất hiện.

Đây là nghi ngờ của tôi: nếu chúng tôi đã sử dụng một cách tiếp cận thông số kỹ thuật thông thường, chúng tôi sẽ có các cuộc phỏng vấn, một tài liệu yêu cầu, hoạt động, trình tự và sơ đồ lớp, vì vậy chúng tôi sẽ biết rằng từ đầu bảng "người" sẽ cần 70 trường, sau đó chúng tôi đã tránh được rất nhiều tái cấu trúc.

Scrum có thể giúp đỡ trong dự án này? Tôi có cảm giác rằng trong trường hợp này, scrum cũng sẽ có rất nhiều cấu trúc lại.

Tôi chỉ là một lập trình viên, không phải là người quản lý dự án. Tôi đang tự hỏi làm thế nào nó nên được thực hiện: với scrum hoặc với thiết kế lớn lên phía trước.

Biên tập

Chỉ để bổ sung cho kết thúc của câu chuyện này. Tám tháng sau tôi đã hỏi câu hỏi này, sau khi đưa dự án vào sản xuất trong một số "chi phí thử nghiệm", chính thức dự án đã thất bại. Chủ sở hữu sản phẩm quyết định từ bỏ dự án. Thật khó để sửa chữa các vấn đề và rất nhiều vấn đề về nước hoa xảy ra.

Có vẻ như bạn đã bắt đầu con đường của mình trong một quá trình phát triển không được kiểm soát để tạo ra một hệ thống phát triển không bao giờ kết thúc. Điều này xảy ra trong các hệ thống nhanh.

Vấn đề gốc là thiếu các yêu cầu và trong khi giải pháp của bạn có vẻ là sử dụng một phương pháp nhanh để khắc phục điều này (vì agile được thiết kế xung quanh các yêu cầu thay đổi), nó sẽ không giải quyết được vấn đề.

Ngay cả các phương pháp nhanh cũng yêu cầu một điểm khởi đầu khá vững chắc. Chúng đáp ứng tốt với các yêu cầu thay đổi, nhưng chúng cũng vô dụng như mọi phương pháp khác nếu bạn bắt đầu không có yêu cầu. Bạn vẫn phải có một kế hoạch mà bạn đang hướng tới trước khi bắt đầu. Agile giúp khi mục tiêu đó trôi đi, nó không giúp bạn xác định mục tiêu đó.

Bây giờ sự thật là một thiết kế phía trước cố định quá cứng nhắc nếu bạn không biết chính xác những gì bạn đang xây dựng.

Vì vậy, tôi nghĩ rằng bạn sẽ phải chuyển từ phương pháp 'hỗn loạn' hiện tại của mình sang một thứ có tổ chức hơn và sẽ phải thực hiện một số lượng lớn thiết kế và lập kế hoạch. Bạn có thể thử làm điều này trong một lần với một phương pháp nặng, hoặc bạn có thể linh hoạt hơn với một phương pháp nhanh nhẹn. Những gì bạn không thể làm là mong đợi bất kỳ phương pháp nào để khắc phục sự thiếu kế hoạch ban đầu của bạn.

Ngẫu nhiên, Kanban âm thanh phù hợp hơn cho nhu cầu của bạn. Scrum hoạt động tốt nhất với các nhóm và dự án nhỏ. Kanban có thể làm việc với các dự án lớn hơn nhưng nó cũng hoạt động với phương pháp tiếp cận công việc, vì vậy các thay đổi thiết kế là liên tục và không bị cắt xén thành nước rút. Tôi nghĩ rằng bạn sẽ có nhiều thành công hơn với điều đó.

18 tháng, 150 bàn mà vẫn không sản xuất? Âm thanh giống như một cuộc diễu hành tử thần đối với tôi. Cách duy nhất bạn có thể khắc phục điều này, nếu có bất kỳ cơ hội nào để lưu nó ngay bây giờ, là thu hẹp đáng kể phạm vi dự án của bạn - ít nhất là cho bản phát hành sản xuất đầu tiên của bạn. Những gì bạn cần là lập kế hoạch phát hành phù hợp, các mục tiêu nhỏ, có thể tiếp cận và đưa hệ thống đến người dùng cuối càng sớm càng tốt.

Và khi bạn có bản phát hành đầu tiên trong sản xuất, chỉ với một phần mười yêu cầu được thực hiện, bạn sẽ phải mở rộng từng bước theo khối yêu cầu tiếp theo, điều này sẽ gây ra "tái cấu trúc". Bạn cũng sẽ nhận được thông tin phản hồi, có nghĩa là yêu cầu sửa lỗi và thay đổi, điều này cũng sẽ gây ra tái cấu trúc.

Bây giờ cho bạn câu hỏi - Scrum sẽ giúp đỡ? Co le không. Scrum là một công cụ để hỗ trợ phát triển lặp lại và thay đổi các yêu cầu, và tập trung vào những điều quan trọng trước tiên. Các phương thức "Agile" khác cũng làm điều này và một quy trình không chính thức cũng có thể xử lý điều đó. Nhưng miễn là bạn cố gắng đưa một con quái vật như thế này trong một "vụ nổ lớn" vào sản xuất, không có vấn đề gì nếu bạn sử dụng phát triển "nhanh nhẹn" hoặc "trả trước", cả hai sẽ thất bại.

Vì vậy, trước khi nghĩ về Scrum, trước tiên hãy suy nghĩ lại về mục tiêu và chiến lược phát hành của bạn, sau đó kiểm tra xem Scrum có phải là công cụ phù hợp cho điều đó không, ngược lại.

Nếu bạn không thể quản lý các yêu cầu và không có người có khả năng thực hiện các yêu cầu đúng cách, SCRUM sẽ không giúp bạn (nhiều) và đó dường như là vấn đề thực sự bạn gặp phải.
SCRUM có thể giúp bạn giải quyết tốt hơn các yêu cầu thay đổi so với các hệ thống quản lý dự án tĩnh hơn, nhưng đó không phải là chén thánh sẽ làm cho mọi thứ hoạt động một cách kỳ diệu. Trên thực tế, trừ khi người của bạn ở trên tàu, sẵn sàng và có khả năng làm việc với SCRUM, và phần còn lại của tổ chức, điều đó có thể khiến mọi thứ trở nên tồi tệ hơn.

Nếu bạn có một bảng được phát triển rất nhiều để phù hợp với các công cụ để liên kết với các hệ thống khác, thì tôi cho rằng thiết kế cơ sở dữ liệu của bạn là thiếu sót nghiêm trọng chẳng hạn. Không có số lượng SCRUM sẽ cải thiện thiết kế cơ sở dữ liệu của bạn mà không có bạn, kể cả những người giỏi thiết kế cơ sở dữ liệu trong nhóm của bạn và không sợ những thay đổi thiết kế đó và những thay đổi mà chúng sẽ gây ra cho phần còn lại của hệ thống.

Xin lưu ý rằng khi tôi viết câu trả lời này, tôi đã không nhận ra rằng hệ thống này chưa được sản xuất.

Theo cách bạn mô tả sản phẩm của bạn, tôi không nghĩ rằng vấn đề trước mắt của bạn là vấn đề quản lý, cũng không phải quá trình phát triển của bạn. Đó là kiến ​​trúc hệ thống của bạn.

Bạn đã quản lý để tạo ra một tảng đá nguyên khối - và một cái khá lớn ở đó. 150 bảng là rất nhiều cho một hệ thống *. Cụ thể, bạn đề cập rằng bạn có 40 lĩnh vực mới trong 15 tháng qua chỉ để tích hợp với các hệ thống bên ngoài. Tôi sẽ xem xét nghiêm túc việc chia hệ thống của bạn thành một số dịch vụ tự trị, có thể bắt đầu bằng các dịch vụ để tích hợp với các hệ thống bên ngoài - nhưng sau đó xác định các lĩnh vực kinh doanh riêng biệt được triển khai trong bạn, và sau đó có thể chia các mối quan tâm đó thành các dịch vụ riêng biệt.

Nếu bạn quản lý để tách khối nguyên khối này thành các cơ sở mã có thể duy trì riêng biệt, bạn cũng có thể chia các nhà phát triển của mình thành các nhóm nhỏ hơn với các trách nhiệm được xác định rõ trong các lĩnh vực cụ thể của doanh nghiệp của bạn và bạn có thể có nhiều nhóm nhanh nhẹn hơn duy trì cơ sở mã riêng của họ, thay vì tất cả các hack trong cùng một cơ sở mã.

Về lý do tại sao bạn đã đến một kiến ​​trúc như vậy, nguyên nhân gốc rễ cho vấn đề của bạn, có thể có nhiều câu trả lời. Có thể nó bắt nguồn từ quá trình phát triển của bạn, có thể tất cả các nhà phát triển của bạn chỉ có kinh nghiệm với phần mềm nhất quán giao dịch hoặc có thể đó là hậu quả của cách tổ chức của bạn được cấu trúc (bạn là nạn nhân của Luật Conway ). Tôi nghĩ có một cơ hội tốt đó là sự kết hợp của hai cái sau.

Tôi không nghĩ rằng việc thực hiện scrum, hoặc trở nên tốt hơn trong việc quản lý các yêu cầu sẽ giúp giải quyết vấn đề tức thời của bạn, cũng không phải là nguyên nhân gốc rễ. Điều chỉnh kiến ​​trúc cho sự phức tạp của hệ thống của bạn sẽ và giải quyết nguyên nhân gốc rễ tại sao bạn xây dựng một hệ thống như vậy.

* Một số người có thể sẽ lập luận rằng họ có thể duy trì một hệ thống với 150 bảng - hoặc họ đã duy trì các hệ thống lớn hơn nhiều, nhưng tôi tin rằng hầu hết các nhà phát triển sẽ coi đây là một số lượng lớn các bảng cho một hệ thống.