Tác động của ITIL hoặc CMMI đối với sự phát triển là gì?

Question

Tôi đã đọc rất nhiều sách về những thực hành nào hoạt động tốt hay không trong phát triển phần mềm. Và tôi KHÔNG BAO GIỜ nghe về phương pháp như ITIL hoặc CMMI trong bất kỳ trang web hoặc sách hoặc blog nào trong lĩnh vực phát triển.

Tôi đã nghe về các phương pháp này trong trường học của tôi, và đối với tôi, có vẻ như đó là các biện pháp quan liêu.

Tuy nhiên mọi cuốn sách về phát triển tôi đã đọc đều nói về sự cộng tác hoặc những người trên tài liệu. (Có, rất nhiều sách nhanh nhẹn)

Vì vậy, câu hỏi của tôi là: Các phương pháp như ITIL hay CMMI có một số tác động hoặc mối quan hệ với sự phát triển hoặc cuộc sống hàng ngày của nhà phát triển? Và bạn có những cuốn sách hay blog tuyệt vời nói về một số ý tưởng hay trong các phép đo lường này mà tôi có thể sử dụng cho một nhóm phát triển?

Answer 1

ITIL tập trung hơn vào cơ sở hạ tầng và hỗ trợ và không phát triển, do đó, thảo luận về ITIL có thể phù hợp hơn với phiên bản tập trung "CNTT" của StackOverflow được cho là đang phát triển. Ngoài ra, tôi có ngoại lệ với việc gọi trang web "CNTT" khác tập trung vào CNTT bao gồm cơ sở hạ tầng, hỗ trợ và phát triển ở hầu hết các doanh nghiệp ... có thể là một tỷ lệ phần trăm tốt của người dùng StackOverflow là các nhà phát triển trong các phòng CNTT.

Tôi đã làm việc với CMMI và Quy trình phần mềm nhóm (TSP), cả hai sản phẩm của Watts Humphrey và Viện kỹ thuật phần mềm Carnegie Mellon. Nếu bạn cam kết cải tiến liên tục và tin rằng đo lường là trọng tâm của bất kỳ cải tiến liên tục nào, thì bạn sẽ tìm thấy giá trị trong CMMI. Nó là rất dễ dàng để làm CMMI (và TSP) sai hoặc trong một cách mà xa lánh các nhà phát triển và cuối cùng kết thúc lên như cửa sổ mặc quần áo hoặc cái gì đó có vẻ tốt trên một đống chứng chỉ. Hãy nhìn vào các nhà cung cấp phát triển ở Ấn Độ ... tất cả họ đều là cấp độ CMMI 5 kỳ diệu.Những gì họ không nói với bạn là hầu như luôn luôn có một dự án nhỏ hoặc một nhóm trong tổ chức của họ làm việc chăm chỉ để có được chứng nhận, nhưng thực hành lặp lại đơn giản là không có 95% tổ chức của họ.

Tập trung vào theo dõi thời gian (đồng hồ bấm lỗ), theo dõi lỗi (giới hạn lỗi), dòng mã (nhiều cách để "trò chơi" nếu bạn nghiêng) và làm cho quy trình của bạn có thể lặp lại được một người không có quyền tự do đổi mới) sẽ tắt nhiều nhà phát triển. < - lưu ý các đối số đã bị giật trong ngoặc đơn. Thực tế vẫn còn 90% các nhà phát triển ở đó (một vài trong số đó đọc StackOverflow hoặc bất kỳ blog/trang web kỹ thuật nào) chụp từ hông và vô cùng thiếu tự nhận thức về nơi họ có cơ hội cải thiện. Đối với họ, quy trình nghiêm ngặt và cơ hội để thực hiện các cải tiến gia tăng về chất lượng thông qua việc tự nhận thức rằng việc lặp lại và đo lường tạo điều kiện thuận lợi là các thành phần có giá trị của CMMI.

Thực hiện đúng, bạn sẽ có được những lợi ích tương tự từ các phương thức Agile như Scrum, nơi tập trung vào lặp lại lặp lại, học hỏi từ mỗi lần lặp và cải thiện/thu hẹp mục tiêu của bạn. Phải mất rất nhiều thời gian trưởng thành và kinh nghiệm để dẫn dắt một nhóm trong việc áp dụng các phương pháp Agile hoặc CMMI và nhận được giá trị đầy đủ của chúng.

Nhanh nhẹn là gợi cảm và CMMI gần như gợi cảm như bạn có thể nhận được, đó là lý do tại sao bạn không nghe nhiều về điều đó.

Answer 2

Việc áp dụng nhanh nhẹn có xu hướng là từ dưới lên: các chuyên viên kỹ thuật vấp ngã và đề xuất việc quản lý.

ITIL/CMMI có xu hướng từ trên xuống: quản lý tình cờ gặp phải và đẩy nó xuống các chuyên gia công nghệ.

Điều đó không làm tốt và điều xấu khác; phần lớn ảnh hưởng đến ngôn ngữ được sử dụng để mô tả từng cách tiếp cận. Và có rất nhiều ngoại lệ - những người có kinh nghiệm trong các chiến hào, những người giỏi áp dụng CMMI và những người quản lý, những người nhanh nhẹn.

Google cho "nhanh nhẹn CMMI" và bạn sẽ nhận được nhiều lần truy cập. Tôi không muốn giới thiệu một cách cụ thể, bởi vì đó là một cuộc tranh luận đang diễn ra (tức là một số người trong số này chỉ đơn giản là sai).

Theo quan điểm của tôi, khái niệm về quy trình chắc chắn là một ý tưởng hữu ích khi phân tích công việc phát triển phần mềm hàng ngày. Ý tưởng cho rằng có một số hoạt động định kỳ, và rằng các hoạt động này thường được tổ chức theo trình tự tương tự, là điểm đầu vào tốt để đặt câu hỏi dẫn đến cải thiện. Bạn cũng có thể nhận được một số dặm bằng cách yêu cầu có thể lặp lại và những hoạt động nào có thể được gọi là được quản lý.

Lỗi và sự dư thừa bắt đầu khi suy nghĩ phép thuật đặt trong: "Nếu chúng ta mô tả (trên giấy) quy trình hoàn hảo và viết tài liệu chính xác, mọi người sẽ theo dõi và chúng tôi sẽ nhận được phần mềm hoàn hảo". Nó không hoạt động theo cách đó.