Câu hỏi này thực sự có hai câu hỏi, cần được giải quyết riêng:
Tại sao một số đội có một quá trình phát triển nghiêm ngặt?
Câu trả lời đơn giản là bởi vì nếu họ không, sai lầm xảy ra. Sai lầm tốn kém. Điều này đúng cho sự phát triển và nó cũng đúng với phần còn lại của lĩnh vực CNTT (sysadmin, DBA, v.v.).
Điều này rất khó để nhiều nhà phát triển và nhân viên CNTT hiểu được vì hầu hết chúng ta chỉ từng làm việc tại một trong những "thái cực" - hoặc là những công ty lớn, theo phong cách Fortune với ít nhất một tá nhà phát triển và quy trình nghiêm ngặt phải tuân theo, hoặc các ISV nhỏ, siêu nhỏ hoặc thậm chí làm việc tự do trong đó mọi người chỉ không làm hỏng việc, hoặc chi phí cho việc bắt vít thấp.
Nhưng nếu bạn đã từng thấy một công ty ở giữa các giai đoạn này - thậm chí là một công ty có đội ngũ nhân viên CNTT tài năng, thông minh - bạn sẽ hiểu được sự nguy hiểm của việc không có quy trình hoặc có quy trình nửa vời. Bạn thấy đấy, giao tiếp giữa các nhân viên bị sự cố nổ kết hợp ; một khi bạn đạt đến mức khoảng 6-10 nhà phát triển trong một nhóm, nguyên nhân chính của các khiếm khuyết lớn hoặc nghiêm trọng không phải là do thiếu tài năng hoặc bí quyết, mà là do thiếu giao tiếp.
Alice hỏi xung quanh vào sáng thứ Hai và quyết định phẫu thuật tái tạo trong thân cây là ổn vì không ai khác làm việc trên phần đó. Bob đến một giờ sau đó, trở về từ kỳ nghỉ của mình và tràn đầy năng lượng và quyết định anh ta sẽ thực hiện một tính năng chính mới trong cùng khu vực đó, và tại sao phải bận tâm với một chi nhánh vì dù sao không ai chạm vào mã đó? Vì vậy, Alice đã trả hết "khoản nợ kỹ thuật" đó, Bob thực hiện tính năng sát thủ của mình đã tồn tại trong 6 tháng và cuối cùng khi cả hai kiểm tra mã của họ (tất nhiên là ngay trước giờ đóng cửa vào thứ Sáu, tất nhiên!) nhóm phải ở lại phía sau và cố gắng vượt qua cơn ác mộng của những cuộc xung đột vẫn tiếp tục sống như những con bọ và hồi quy trong suốt vài tuần tới.
Alice và Bob Cả hai đã làm rất tốt trong các nhiệm vụ mã hóa, nhưng cả hai đều bắt đầu với một quyết định tồi tệ ("điều tồi tệ nhất có thể xảy ra là gì?"). Trưởng nhóm hoặc người quản lý dự án sẽ đưa họ qua khám nghiệm tử thi và đưa ra một danh sách kiểm tra để ngăn điều này xảy ra lần nữa:
- Việc đăng ký phải được thực hiện hàng ngày để giảm thiểu tác động của xung đột;
- Những thay đổi sẽ mất hơn 1 ngày đáng kể phải được thực hiện trên các chi nhánh;
- Tất cả các tác vụ quan trọng (bao gồm cả các công việc không có tính năng như tái cấu trúc) phải được theo dõi và chỉ định đúng trong trình theo dõi lỗi.
Tôi sẽ đặt cược rằng, với nhiều người trong chúng ta, "quá trình" này có vẻ giống như lẽ thường. Đó là chiếc mũ cũ. Nhưng bạn có biết rằng rất nhiều đội nhỏ hơn không làm điều này? Một nhóm hai người thậm chí có thể không bận tâm đến việc kiểm soát nguồn. Ai quan tâm? Thật ra nó không cần thiết. Các vấn đề chỉ bắt đầu xảy ra khi nhóm phát triển nhưng quá trình thì không.
Tất nhiên, tối ưu hóa quy trình cũng giống như tối ưu hóa hiệu suất; nó theo một đường cong hàm mũ nghịch đảo. Danh sách kiểm tra ở trên có thể loại bỏ 80% lỗi, nhưng sau khi bạn thực hiện nó, bạn thấy rằng một số thứ khác chiếm 80% lỗi còn lại . Trong ví dụ giả tưởng nhưng quen thuộc của chúng tôi, đó có thể là lỗi xây dựng do có môi trường xây dựng khác nhau, do đó không có phần cứng và nhà phát triển tiêu chuẩn nào đang sử dụng các thư viện nguồn mở được cập nhật mỗi 2 tuần.
Vì vậy, bạn có ba lựa chọn: Hoặc (a) chuẩn hóa phần cứng và hạn chế nghiêm ngặt việc sử dụng thư viện của bên thứ 3, điều này gây tốn kém và có thể ảnh hưởng đáng kể đến năng suất, hoặc (b) thiết lập máy chủ xây dựng, cần có sự hợp tác từ nhóm sysadmin và nhà phát triển toàn thời gian để duy trì nó, hoặc (c) cho phép các nhà phát triển tự làm điều này bằng cách phân phối một máy ảo tiêu chuẩn và bảo các nhà phát triển xây dựng dựa trên đó. Rõ ràng (b) là giải pháp dài hạn tốt nhất nhưng (c) có sự cân bằng ngắn hạn tốt hơn về độ tin cậy và kinh nghiệm.
Chu kỳ cứ lặp đi lặp lại. Mọi "chính sách" mà bạn thấy thường được lập ra để giải quyết một vấn đề thực sự. Như Joel Spolsky đã viết từ năm 2000 trở về trước (về một chủ đề hoàn toàn khác bạn, nhưng vẫn có liên quan):
Khi bạn đi vào một nhà hàng và bạn thấy một tấm biển có ghi "Không cho phép chó", bạn có thể nghĩ rằng dấu hiệu đó hoàn toàn mang tính mô tả: Nhà hàng của ông không thích những con chó xung quanh, vì vậy khi ông xây dựng nhà hàng, ông đã đặt tấm biển đó.
Nếu đó là tất cả những gì đang diễn ra, thì cũng sẽ có một dấu hiệu "Không có rắn"; Rốt cuộc, không ai thích rắn. Và một dấu hiệu "Không có voi", bởi vì họ phá vỡ những chiếc ghế khi họ ngồi xuống.
Các thực lý do đó dấu hiệu là có lịch sử: đó là một dấu hiệu lịch sử chỉ ra rằng những người sử dụng để cố gắng mang lại những con chó của họ vào nhà hàng.
Hầu hết các nhóm phần mềm đều giống nhau (tôi sẽ không nói tất cả): Các chính sách như "Bạn cần thêm trường hợp kiểm tra cho mọi sửa lỗi" gần như luôn luôn chỉ ra rằng nhóm có lịch sử gặp vấn đề với hồi quy. Sự hồi quy là một trong những vấn đề thường xảy ra do sự cố truyền thông hơn là sự bất tài. Miễn là bạn hiểu chính sách, bạn có thể sử dụng các phím tắt hợp pháp (ví dụ: tôi phải sửa 6 lỗi nhỏ nhưng tất cả chúng đều có cùng tính năng, vì vậy tôi thực sự chỉ có thể viết một trường hợp thử nghiệm cho tất cả 9 lỗi).
Điều đó giải thích tại sao các quy trình ở đó, nhưng nó không phải là toàn bộ câu chuyện. Nửa còn lại là:
Tại sao quá trình này rất khó để làm theo?
Đây thực sự là câu hỏi đơn giản hơn để trả lời: Đó là vì nhóm (hoặc quản lý của nó) tập trung vào các kết quả lặp lại và giảm thiểu các khiếm khuyết (như trên) nhưng chưa được quan tâm đúng mức đến tối ưu hóa và tự động hóa quá trình đó.
Ví dụ, trong câu hỏi ban đầu, tôi thấy một số vấn đề:
Hệ thống kiểm soát sửa đổi (CVS) là di sản theo tiêu chuẩn ngày nay. Đối với các dự án mới , nó đã được thay thế gần như hoàn toàn bởi lật đổ (SVN), bản thân nó đang nhanh chóng bị lu mờ bởi các hệ thống phân tán như Mercurial (Hg). Chuyển sang Hg sẽ làm cho việc phân nhánh và hợp nhất trở nên đơn giản hơn rất nhiều , và ngay cả trong ví dụ giả thuyết của tôi ở trên, yêu cầu cam kết hàng ngày sẽ trở nên ít đau đớn hơn. Mã thậm chí không phải biên dịch, vì kho lưu trữ là cục bộ; - trên thực tế, các nhà phát triển lười biếng thậm chí có thể tự động hóa bước này nếu họ muốn, thiết lập một kịch bản đăng xuất để tự động cam kết thay đổi đối với kho lưu trữ cục bộ.
Không có thời gian đã được dành để tự động hóa quá trình Máy ảo. Toàn bộ quá trình lấy, định cấu hình và tải nguồn / thư viện vào máy ảo có thể được tự động hóa 100%. Đó có thể là một quá trình không giám sát mà bạn chạy trên một máy chủ trung tâm ở đâu đó trong khi bạn sửa lỗi trên máy cục bộ của mình (và chỉ sử dụng VM để đảm bảo bản dựng sạch).
Mặt khác, ở một quy mô nhất định, giải pháp VM-per-developer bắt đầu trở nên ngớ ngẩn và bạn chỉ nên có một máy chủ Tích hợp liên tục. Đó là nơi mang lại lợi ích năng suất thực sự, bởi vì nó (phần lớn) giải phóng các nhà phát triển cá nhân khỏi phải lo lắng về các bản dựng. Không cần phải lo lắng về việc thiết lập các máy ảo sạch vì máy chủ xây dựng luôn sạch sẽ.
Các từ ngữ của câu hỏi ( "test trường hợp với tất cả các bước") ngụ ý rằng có một số thủ thử nghiệm đang diễn ra. Điều này, một lần nữa, có thể làm việc cho các nhóm nhỏ với khối lượng công việc tương đối thấp, nhưng không có ý nghĩa gì ở quy mô lớn hơn. Kiểm tra hồi quy có thể và nên được tự động hóa; không có "bước", chỉ có một lớp hoặc phương thức được thêm vào bộ kiểm thử đơn vị / tích hợp.
Không cần phải nói, việc chuyển từ Bugzilla sang một hệ thống theo dõi lỗi mới hơn (tốt hơn) sẽ khiến cho trải nghiệm đó bớt đau đớn hơn rất nhiều.
Các công ty không nhất thiết phải rẻ hoặc ngu ngốc chỉ vì họ không giải quyết được những vấn đề này. Tất cả những gì họ biết là quy trình hiện tại hoạt động , và trong một số trường hợp, họ không thích rủi ro và miễn cưỡng thay đổi bất cứ điều gì về nó. Nhưng thực sự họ chỉ cần được thuyết phục về lợi ích .
Nếu các nhà phát triển đã dành một tuần để theo dõi thời gian của họ cho tất cả các nhiệm vụ không mã hóa, thì bạn có thể dễ dàng thêm nó, cho người quản lý thấy (ví dụ) một khoản đầu tư không vốn, 100 giờ để nâng cấp lên Mercurial loại bỏ tối đa 10 giờ mỗi tuần để giải quyết xung đột hợp nhất, sau đó là khoản thanh toán 10 tuần và họ gần như chắc chắn sẽ đồng ý với nó. Cùng ý tưởng với máy chủ xây dựng (CI) hoặc theo dõi lỗi tốt hơn.
Tóm lại: Các đội chưa làm những điều này vì chưa ai thuyết phục được ban quản lý rằng điều đó đủ quan trọng để làm ngày hôm nay . Vì vậy, hãy chủ động và biến nó thành một phương trình lợi ích chi phí; tìm hiểu bao nhiêu thời gian dành cho các nhiệm vụ có thể được đơn giản hóa / tự động với rủi ro tối thiểu và tính điểm hòa vốn và mức chi trả cuối cùng của một công cụ hoặc kỹ thuật mới. Nếu họ vẫn không nghe, thì bạn đã biết những lựa chọn còn lại của bạn là gì.
Nếu các nhà phát triển đã dành một tuần để theo dõi thời gian của họ cho tất cả các nhiệm vụ không mã hóa, thì bạn có thể dễ dàng thêm nó, hiển thị quản lý ... và biến nó thành một phương trình lợi ích chi phí, v.v ...
Trên một phần có giá trị mở rộng hơn nữa.
Tôi có thể xác nhận rằng nó hoạt động. Các lập trình viên đã sử dụng nó vài lần trong một trong những dự án tôi đã làm và mỗi lần nó dẫn đến những thay đổi mong muốn.
Ấn tượng chung của tôi là nếu được thực hiện đúng, thủ thuật này có thể ghi đè lên số lượng khá lớn sự thiếu hiểu biết về quản lý và quán tính.
Tôi muốn lưu ý rằng mặc dù công ty mà chúng tôi (nhà phát triển) phải sử dụng phương pháp DIY kiểu này rất khôn ngoan về CNTT. Tại các nhà cung cấp phần mềm dày dạn hơn, tôi thấy những thứ như thế chủ yếu được thực hiện bởi chính các nhà quản lý. Và như một quy luật, họ làm việc hiệu quả hơn những lập trình viên đó. Năng suất hơn nhiều.