Đối phó với một dự án vô tận không thể trộn lẫn

Chúng tôi có một trang web lớn (hơn 1200 giờ) có nhiều nợ kỹ thuật. Điều này chủ yếu được gây ra bởi các lý do (thông thường) sau đây.

1. Nhiều lập trình viên đến và đi trong quá trình phát triển.
2. Thay đổi thông số kỹ thuật trong quá trình phát triển.
3. Nhiều chức năng được thêm vào (trong một thời gian ngắn).

Khách hàng muốn rất nhiều chức năng mới, và điều đó về cơ bản bắt đầu hoạt động trong dự án này hàng tuần trong hơn 10 giờ.

Do các khoản nợ kỹ thuật, chúng tôi dành RẤT NHIỀU giờ để sửa chữa hoặc điều tra các vấn đề, thường tìm thấy nguồn gốc của chúng theo một trong những điều sau đây:

1. Một lỗi không biết xấu hổ, ngớ ngẩn khiến người ta khóc.
2. Một tính năng mới dẫn đến kết quả ở trên vì chúng tôi đã không lường trước tất cả các vị trí mà tính năng mới sẽ có ảnh hưởng.
3. Một số vấn đề khác mà chúng tôi đã gặp phải (di chuyển máy chủ, nâng cấp)

Chúng tôi có vấn đề hàng ngày và chúng tôi đã cố gắng làm theo mọi thứ để tạm dừng vấn đề này:

1. Tạo tài liệu kỹ thuật liên quan đến nhập khẩu, thanh toán và làm việc chung của trang web.
2. Có cuộc họp vào đầu tuần - thảo luận về các vấn đề hoặc cải tiến hiện tại và cách giải quyết chúng.
3. Có kế hoạch kiểm tra. Lập trình viên A kiểm tra B, B kiểm tra C và C kiểm tra A. Sau đó, Người quản lý dự án của chúng tôi sẽ đưa ra một số thử nghiệm. Về tác động của tính năng, chúng tôi ném nó vào môi trường dàn dựng và để khách hàng tự kiểm tra.

Vấn đề là các vấn đề liên tục xảy ra ... và bằng cách nào đó chúng ta không thể nắm bắt được nó. Các tính năng mới vẫn gây ra lỗi và lỗi cũ tiếp tục nói xin chào. Bằng cách nào đó - có lẽ do quy mô của dự án - dường như chúng ta không thể nắm bắt được dự án này.

Tôi giả sử có rất nhiều lập trình viên làm việc trong các dự án lớn hơn thế này. Đó là lý do tại sao tôi đi đến câu hỏi của mình:

Chúng tôi có thể làm gì, hoặc bạn làm gì để tránh những vấn đề này trong các dự án lớn?

Chỉnh sửa nhỏ, thông tin thêm:

1. Chúng tôi sử dụng kiểm soát phiên bản (SVN).
2. Chúng tôi có quy trình phát triển DTAP.

Tôi sẽ chơi trò bênh vực của quỷ, đã thấy quá thường xuyên như thế nào điều này hóa ra: Bạn không thể đối phó với nó. Tôi đảm bảo bạn là người duy nhất thực sự nhìn thấy một vấn đề thực sự với hệ thống, nếu không, bạn sẽ không phải hỏi làm thế nào để đối phó với nó bởi vì văn hóa công ty sẽ là một trong những cách khắc phục lỗi và sửa mã bất cứ nơi nào có thể tức là vận hành như thế nào các chuyên gia thực sự làm việc.

Tôi cá là nó quá lớn để bắt đầu viết bài kiểm tra đơn vị, bởi vì nó chưa có ai biết cách kiểm tra đơn vị trước bạn (và may mắn là những người khác trong nhóm của bạn) và không thể biết bắt đầu từ đâu, và thậm chí có thể không thể kiểm tra vì nó phụ thuộc vào việc triển khai chính xác và dữ liệu cụ thể, do đó, sẽ mất quá nhiều thời gian để loại bỏ tất cả những điều đó ra các giao diện, giả, sơ khai và những thứ tương tự để có thể kiểm tra nó ngay từ đầu. Tôi cũng cá rằng bạn không thể đi và cấu trúc lại những gì cần được cấu trúc lại bởi vì nó quá chặt chẽ và vì không có thử nghiệm, ai biết cái gì sẽ bị hỏng bằng cách sửa mã xấu. Nói tóm lại, nó có thể trở nên quá ung thư để khắc phục nghiêm trọng, nhưng tất nhiên nó không thể bị cắt bỏ và bắt đầu tươi mới.

Bạn đang chiến đấu một trận thua, bạn của tôi. Hoặc bạn sẽ kiệt sức vì thất vọng và cuối cùng bỏ cuộc hoặc phát điên, hoặc nếu bạn phàn nàn về điều đó đủ lâu để khiến người khác nhận ra vấn đề, họ sẽ nghĩ vấn đề duy nhất là bạn và bạn sẽ được đưa ra cửa.

Những thứ kiểm tra đơn vị là một điểm khởi đầu tốt nếu bạn không làm gì cả. Ít nhất họ sẽ bảo vệ bạn khỏi việc thêm các lỗi mới khi sửa các lỗi cũ.

Kiểm soát nguồn cũng có ích, trừ khi bạn không sử dụng nó. Các tính năng đổ lỗi và đăng nhập, đặc biệt, là tuyệt vời để tìm hiểu làm thế nào / tại sao một đoạn mã lỗi từng được cam kết.

Về phía khách hàng, tôi đã thấy rằng thảo luận về giá cả và sự chậm trễ (kéo dài) ngay khi các thay đổi / tính năng bổ sung được yêu cầu hoạt động hợp lý, cũng như tính phí cho thời gian bạn dành để thảo luận / thiết kế chúng. Thông thường, khách hàng sẽ quyết định rằng vào ngày thứ hai họ nghĩ rằng họ có thể chờ đợi.

(Ngược lại, nếu bạn ngay lập tức đào sâu vào thông số kỹ thuật và ý tưởng thực hiện với anh ấy, họ thường sẽ thiết lập cho bạn một "ồ, tôi nghĩ rằng chúng tôi đã đồng ý bạn sẽ làm điều này" hoặc (tệ hơn, sau vài ngày trở lại và về các chi tiết cụ thể) "nhưng hãy nhìn xem, nó đã được thiết kế và chúng tôi đã thảo luận không quá khó!".)

Cuối cùng nhưng không kém phần quan trọng, tôi đã phát hiện ra rằng tôi chỉ đọc email một lần mỗi ngày (khi đến nơi làm việc) và rằng tôi có điện thoại cho bất cứ điều gì khẩn cấp hơn, dẫn đến tăng năng suất rất lớn.

Tôi đề nghị bạn nên thêm một số thử nghiệm dựa trên CI, chủ yếu trên các khu vực thường xuyên bị phá vỡ nhất. Điều đó sẽ giúp bạn tăng chất lượng vì công việc đang được thực hiện trong dự án.

Nó cũng trở nên rõ ràng hơn những khu vực / chức năng phá vỡ thường xuyên hơn và do đó dễ dàng hơn để quyết định phần nào cần tái cấu trúc, hoặc ít nhất là tăng kiểm tra.

Thêm nhiều rủi ro kiểm thử thủ công khiến dự án đi sai hướng về $$$ & thời gian cần thiết cho mỗi tính năng được thêm vào.

Một số đánh giá mã là tốt, nhưng có lẽ đó là một phần của sơ đồ thử nghiệm A-> B-> C-> A. (Có thể xem lại mã theo hướng khác?)

Hãy để tôi ném một câu chuyện ngụ ngôn vào bạn. Bạn đang đi dạo với một người trước đó trong ngày xuống phố và bạn đến đích. Người bạn đang đi cùng nhanh chóng phát hiện ra rằng anh ta bị mất chiếc nhẫn ở đâu đó dọc đường nên cả hai bạn quyết định quay lại và đi tìm nó. Người bạn đang đi bộ nhanh chóng dừng lại ở cột đèn và bắt đầu nhìn điên cuồng. Bạn nói, "Tại sao bạn nhìn vào cột đèn khi tôi nghĩ rằng bạn có thể đã mất nó khi chúng tôi cắt qua con hẻm?". Anh trả lời: "Tôi biết nhưng ánh sáng ở đây tốt hơn."

Tôi đã ở trong tình huống này hơn một vài lần và tôi đã nhận thấy một số điểm tương đồng. Các loại dự án ác mộng bảo trì này thường được chạy trong một môi trường quá trình nặng với sự giám sát nặng nề và cải tiến quy trình do ban quản lý áp đặt. Tôi không nói rằng cải tiến quy trình là một điều xấu nhưng thường xuyên hơn không phải là các loại cải tiến quy trình mà Quản lý thường muốn ban hành có hai điểm chính.

1) Họ thường không phá vỡ chính trị văn phòng và cân bằng quyền lực. 2) Họ thành công trong việc tạo ra ảo tưởng về sự kiểm soát của ban quản lý hơn là tấn công vào trung tâm của vấn đề.

Quản lý "ánh sáng tốt hơn ở đây" nghĩ rằng thường đi bằng cách nói, "Mỗi tính năng mới phải có thông số kỹ thuật chi tiết" hoặc "Hãy có một cuộc họp hàng giờ mỗi ngày để thảo luận về các vấn đề và cách khắc phục chúng."

Cả hai điều này thực sự không phải là vấn đề cốt lõi và chúng có thể làm giảm năng suất nhưng chúng chắc chắn xác nhận ảo tưởng về sự kiểm soát của ban quản lý.

Những thay đổi thực sự duy nhất mà bạn có thể giúp thúc đẩy sẽ là những thay đổi làm mọi thứ rung chuyển. Tôi nghi ngờ mặc dù sự quái dị của bạn về một trang web có thể vượt quá khả năng sửa chữa vào thời điểm này và bạn sẽ tiến xa hơn để tái kiến ​​trúc và viết lại. Tuy nhiên, trong tương lai, bạn có thể ghi nhớ tầm quan trọng của phương pháp Agile, Tích hợp liên tục, Phát triển dựa trên thử nghiệm, Đánh giá mã và các thông số kỹ thuật yêu cầu kinh doanh được quy định theo quy trình Kiểm soát thay đổi nghiêm ngặt để giúp giảm thiểu phạm vi leo thang mà không cần điều chỉnh lịch trình.

Những loại thay đổi này thực sự đòi hỏi một sự thay đổi trong cách suy nghĩ ở cấp quản lý và trong toàn bộ kinh nghiệm chuyên môn của tôi, tôi chưa bao giờ gặp phải điều này xảy ra nếu không có một loại chấn động cấp quản lý trung gian. Tôi hy vọng điều đó không quá nản lòng vì bạn nên cố gắng cho điều đúng đắn bất kể bạn đang chiến đấu trong một trận chiến khó khăn, bởi vì bạn có thể sẽ gặp phải sự kháng cự quyết liệt của những người yêu thích hiện trạng.

Tôi đã ở cùng một vị trí một thời gian trước đây. Tôi không còn nữa nhờ hai quy tắc đơn giản:

• Mỗi tuần một hoặc hai ngày được dành để sửa / viết lại hầu hết các phần có lông của ứng dụng. Không săn lỗi, không phát triển tính năng mới.
• Trong khi thực hiện các tính năng mới, chúng tôi cố gắng làm cho đúng ngay cả khi chúng tôi dành nhiều thời gian hơn khách hàng mong đợi.

Vấn đề duy nhất là khiến người khác tôn trọng họ. Phần dễ dàng đáng ngạc nhiên là khách hàng. Thật sự không thể giải thích tại sao, nhưng bằng cách nào đó chúng tôi đã thuyết phục anh ấy, rằng khi chúng tôi làm việc trên một tính năng lâu hơn một chút thì tốt hơn cho mọi người. Tôn trọng quy tắc đầu tiên hóa ra có nhiều vấn đề hơn, nhưng chúng tôi cũng cảm thấy nó giúp chúng tôi rất nhiều. Nó đảm bảo tiến độ ổn định vì các phần khác nhau của ứng dụng đang trở nên tốt hơn.

Mã đánh giá. Bài kiểm tra đơn vị. Kiểm tra QA thực. Quy trình thu thập thông số kỹ thuật và phát triển gia tăng - đây là một số điều sẽ giải quyết hầu hết các vấn đề của bạn.

Ngoài ra, đừng để khách hàng trực tiếp ping nhà phát triển của bạn - Đây thường là cách giải quyết vấn đề không hiệu quả nhất. Thuê một người quản lý chương trình tốt, người sẽ hình thành giao diện giữa khách hàng và nhà phát triển của bạn. Công việc của anh ta là biết sản phẩm từ đầu đến cuối, tình trạng hiện tại, hướng đi trong tương lai, v.v. Bất cứ khi nào khách hàng muốn một tính năng mới khác, anh ta sẽ có thể đưa ra danh sách các mặt hàng hiện tại và cho khách hàng thấy những gì sẽ bị phá vỡ nếu yêu cầu mới này được thực hiện.

Quá trình là xấu khi nó được sử dụng quá ít hoặc quá nhiều. Tôi nghĩ rằng bạn đang ở trạng thái cũ.

Như Deni đề cập, nếu bạn có thể thêm thử nghiệm đơn vị vào dự án, thì điều này sẽ giúp bạn. Có một bài kiểm tra bao gồm một phần của hệ thống mà bạn sắp thay đổi / sửa chữa, và vì vậy khi mã tái cấu trúc của bạn, hãy sử dụng bài kiểm tra đó như một hướng dẫn để đảm bảo bạn không phá vỡ bất cứ điều gì.

Ngoài ra, xử lý các phần bị hỏng nhất của mã. Cố gắng đưa những người bị ảnh hưởng xấu nhất vào danh sách rủi ro và quản lý những rủi ro đó một cách độc lập. Cố gắng có được một ý tưởng về việc có bao nhiêu mã bị hỏng trong cơ sở mã bằng cách truy vấn nơi xảy ra lỗi nhiều nhất. Sau đó, bạn có thể liệt kê khu vực bị ảnh hưởng theo số lỗi (hoặc các vấn đề được báo cáo, bất cứ điều gì phù hợp với bạn.).

Việc vá và làm sạch mã sẽ mất thời gian, nhưng nếu mỗi nhà phát triển trong nhóm có thể để lại mã sạch hơn một chút thì đó là trước khi họ tiến hành mã, theo thời gian, cơ sở mã sẽ cải thiện. Nếu bạn đang tìm kiếm một phong cách quân đội nhanh chóng, hãy sắp xếp nó ngay bây giờ, tôi nghi ngờ rằng có bất cứ điều gì thiết thực (hoặc được khuyến nghị) sẽ giúp ích.

Chúc mừng. Jas.

Viết thông số chức năng rõ ràng; vì vậy nếu bạn có thể chịu đựng nó và xem xét chức năng đối với các thông số kỹ thuật đó thường xuyên. Càng ít ý tưởng mà một nhà phát triển có về những gì anh ta được cho là đang phát triển, thì càng ít cơ hội để nó được phát triển.

Trước khi bạn bắt đầu viết mã, hãy thực hiện một số công việc thiết kế phía trước; điều này không cần phải hoàn hảo, hoặc lớn hoặc chứa UML, nhưng nó cần phác thảo một giải pháp khá vững chắc cho vấn đề cần giải quyết. Theo như tôi có thể nói rằng phần mềm càng ít được lên kế hoạch thì nó càng tệ. Thảo luận về thiết kế trước khi bạn bắt đầu làm việc với nó.

Khi bạn bắt đầu làm việc trên một khu vực của mã rõ ràng là xấu và thực sự cản trở tiến trình của bạn; ngừng thêm vào nó, lùi lại khỏi vấn đề, tìm ra cách bạn có thể thiết kế lại kiến ​​trúc để những trở ngại không có ở đó và để nó có thể thích nghi hơn trong tương lai. Bạn càng để nó lâu hơn trước khi bạn giải quyết nợ kỹ thuật thì càng khó giải quyết nó mà không cần viết lại đầy đủ. Tôi muốn nói đó là một điều theo cấp số nhân.

Thiết kế kiểm tra kiểm tra hành vi và không kết hợp chặt chẽ với kiến ​​trúc của bạn. Nó không phải là rất thời trang, nhưng tôi sẽ nói đừng bắt đầu thử nghiệm cho đến khi mục đích thực sự của mã của bạn là rõ ràng. Cụ thể không bắt đầu thử nghiệm cho đến khi bạn biết những gì bạn thực sự muốn thử nghiệm; IMO một bài kiểm tra suy nghĩ kém là tồi tệ hơn so với không có bài kiểm tra. Và bạn càng có nhiều bài kiểm tra thì càng khó thay đổi mã của bạn trong nội bộ. Đối xử với mã kiểm tra của bạn như bạn sẽ sản xuất mã; nó cần được lên kế hoạch và viết tốt

Thực hiện đánh giá mã thường xuyên / hàng ngày: đây là về kiểm tra độ tỉnh táo để đảm bảo nhà phát triển đã không đi quá xa. Sử dụng các phiên này để lên kế hoạch cho những ngày làm việc tiếp theo. Có thể có những ngày mất 5 phút hoặc 1 giờ; vấn đề là giữ cho một cuộc đối thoại mở và cho các nhà phát triển cơ hội thảo luận về công việc của họ với các nhà phát triển khác và tìm kiếm lời khuyên. Thực hiện một số phiên ghép nối trên các phần khó khăn của mã, hoặc theo ý tưởng nguyên mẫu, nhưng để mọi người có thời gian riêng để làm việc.

Làm cho nó dễ dàng để xây dựng và triển khai mã của bạn. Cố gắng giữ thời gian xây dựng ngắn. Càng dễ xây dựng, nó sẽ được xây dựng càng nhiều, nó càng được xây dựng nhanh hơn.

Áp dụng các tiêu chuẩn mã hóa và thực thi chúng một cách cứng nhắc. Điều này sẽ bao gồm tất cả mọi thứ từ nơi một dự án sẽ sống trong hệ thống tệp đến vỏ của một const riêng. Điều này có vẻ vô nghĩa và gây phiền nhiễu, nhưng những thói quen tốt là nền tảng của quá trình phát triển.

Về cơ bản tôi không nghĩ rằng quá trình bạn sử dụng rất quan trọng, thời trang đến và đi. Điều thực sự quan trọng là bạn chuyên nghiệp về cách bạn phát triển phần mềm và bạn có kỷ luật trong thực tiễn.

Tôi sẽ bắt đầu bằng cách thiết kế và tự động hóa các thử nghiệm khói, và ném chúng vào môi trường CI. Những người nên được chức năng. Khi khách hàng nói với bạn rằng một cái gì đó nên hoạt động bình thường, hãy yêu cầu viết nó ra, để bạn có thể tham khảo nó sau. Khi bạn thấy một giải pháp nào đó trong phần mềm, hãy đặt câu hỏi và ngay khi bạn nhận được câu trả lời, hãy kết hợp chúng vào cơ sở kiến ​​thức và làm cho chúng có thể theo dõi được.

Đảm bảo rằng các chức năng cơ bản cho các trường hợp tích cực hoạt động. Sau đó bắt đầu xây dựng các bài kiểm tra tăng dần để xử lý dữ liệu không chính xác, đặt các khiếm khuyết khi thấy cần thiết. Có một cuộc thảo luận dài và sâu về các ưu tiên, và để người quản lý kiểm tra biết về nó, để anh ta có thể chỉ định thời gian thử nghiệm cho phù hợp. Đừng cố tự động hóa mọi thứ, nhưng ngay sau đó, vì một số testcase có ý nghĩa được tự động hóa - đừng ngần ngại.

Nói chung, sử dụng thử nghiệm để tăng sự tin tưởng vào sản phẩm, và không phải là công cụ sẽ ngay lập tức tăng chất lượng. Hãy bình tĩnh, nhưng quyết đoán :). Có thể cố gắng đi nhanh, nhưng chỉ khi bạn hoàn toàn, tích cực có thể tham gia vào một PM được chứng nhận. Giới thiệu Agile bởi một người không biết Agile, rất có thể sẽ giết chết dự án.