Làm thế nào các tiêu chuẩn và cải tiến quy trình nên được giới thiệu cho một tổ chức mà không có chúng?

10

Tôi đã được giao nhiệm vụ cải tiến quy trình phát triển phần mềm thông qua việc thực hiện các cải tiến quy trình, trong đó chúng tôi rất có thể sẽ sử dụng CMMI cho Phát triển, Phiên bản 1.3 làm hướng dẫn và áp dụng các thực tiễn tốt nhất toàn bộ hoặc một phần. Cách tốt nhất để giới thiệu các tiêu chuẩn và cải tiến quy trình để mức độ đẩy lùi và kháng cự từ các nhà phát triển được giảm thiểu là gì?

standards cmmi process-improvement

— rjzii
nguồn

Chỉ tò mò, bạn đã có ý tưởng tại sao nhiều lỗi hơn thông qua sau đó mong muốn?

— Chris Pitman

2

@ S.Lott Bạn có thể tạo ra một trường hợp cho các lỗi không được giảm (về phía người tiêu dùng) mà không có tiêu chuẩn? Kinh nghiệm của tôi về một quy trình và tiêu chuẩn làm giảm đáng kể những gì người tiêu dùng nhìn thấy về lỗi ... không phải là họ không tồn tại mà họ không bao giờ bị khách hàng nhìn thấy.

— Rig

@RobZ: Tôi không hỏi những gì bạn hiện có. Tôi vẫn đang cố gắng để hiểu câu hỏi. "Thực hiện cải tiến quy trình" dường như là mô tả chính xác nhất về những gì bạn đang hỏi về. Tôi muốn đề xuất rằng "tiêu chuẩn" là một thuật ngữ khó hiểu, vì nó có định nghĩa chính thức và bạn không sử dụng định nghĩa chính thức đó.

— S.Lott

@Robz: "Tiêu chuẩn mã hóa" không phải là "Tiêu chuẩn chính thức". Điều đó sẽ làm rõ câu hỏi. Lần nữa. "Tiêu chuẩn chính thức" là các tiêu chuẩn W3C, Posix, ISO, IEEE, ANSI. Dự thảo và phê duyệt bởi một tổ chức độc lập được công nhận. Nếu bạn đang nói về các tiêu chuẩn mã hóa, vui lòng cập nhật câu hỏi để xóa từ "Chính thức" và sử dụng từ "Mã hóa". Với sự thay đổi câu hỏi của bạn có ý nghĩa. Và là một bản sao.

— S.Lott

"Liên quan đến các từ" tiêu chuẩn "trong tiêu đề kết hợp với quá trình cải tiến, các tiêu chuẩn từ không chỉ áp dụng cho mã mà ai đó viết"? Gì? Đây là một gợi ý. Vui lòng không sử dụng từ "tiêu chuẩn" mà không có một số loại vòng loại; thật khó hiểu Nếu bạn có nghĩa là "tiêu chuẩn mã hóa" xin vui lòng sử dụng cụm từ đó. Nếu bạn có nghĩa là một số loại "tiêu chuẩn" khác, vui lòng đủ điều kiện từ "tiêu chuẩn" với một cụm từ đủ điều kiện để làm rõ những gì bạn đang nói về. "tiêu chuẩn" là mơ hồ và khó hiểu.

— S.Lott

2

Bắt đầu dự án cải tiến quy trình phần mềm (SPI) . Xác định phạm vi và mục tiêu của nó. Nó chắc chắn sẽ giúp nếu tiêu chuẩn hóa có mục tiêu và biện pháp riêng áp dụng cho tổ chức của bạn.
Phân công người chịu trách nhiệm áp dụng các tiêu chuẩn . Nó cũng có thể là một vài người hoặc thậm chí bộ phận trong trường hợp của tổ chức lớn. Điều quan trọng là tất cả những người chịu trách nhiệm về tiêu chuẩn hóa sẽ là:
- đủ chuyên nghiệp để xem toàn bộ hình ảnh
- đủ ảnh hưởng để đối phó với các nhóm và giúp họ chấp nhận / đàm phán thay đổi
Phát triển các khóa đào tạo bao gồm cả tiêu chuẩn bạn muốn áp dụng và các chi tiết cụ thể được áp dụng cho tổ chức của bạn. Và nó thực sự quan trọng miễn là tất cả những người không được đào tạo đều có khả năng chống lại những thay đổi. Ví dụ, khi tôi làm việc trong một công ty lớn, tôi đã hướng dẫn tất cả nhân viên mới về quy trình QA, CMMI, ISO và Hệ thống quản lý chất lượng. Đào tạo như vậy là bắt buộc. Nó giúp cải thiện kiến thức về các quy trình quản lý chất lượng và nâng cao nhận thức của nhân viên về vấn đề quan trọng của chất lượng phần mềm.
Đàm phán thay đổi và thiết kế phù hợp thường được chấp nhận cho các nhu cầu cụ thể của bạn. Nó sẽ giúp tránh quan liêu và thực hiện các quy trình nặng không ai thực sự cần.
Thiết lập giám sát về cách cải tiến quy trình được thực hiện đang được hỗ trợ và liệu chúng có đủ hiệu quả trong tổ chức của bạn không.

Nó cũng sẽ giúp nếu bạn sẽ tìm thấy tất cả những người trong tổ chức của bạn, những người thực sự quan tâm đến chất lượng. Rất có thể, đó sẽ là những tài nguyên quan trọng nhất giúp bạn thúc đẩy các thay đổi và thiết lập các thực tiễn trưởng thành.

— thay thế
nguồn

6

Một vài suy nghĩ từ trường học của gõ cứng:

1) Hầu hết các sáng kiến cải tiến quy trình dành 80% thời gian cho thiết kế quy trình và 20% cho giáo dục và xã hội hóa. Lật các tỷ lệ phần trăm. Một tiêu chuẩn tầm thường theo sau đó là một tiêu chuẩn hoàn hảo không phải là một.

2) Xác định lý do rõ ràng tại sao bạn yêu cầu mọi người thay đổi cách họ làm việc. Trường hợp kinh doanh là gì? Lý tưởng nhất là nó mang lại lợi ích cho mỗi đội. Đôi khi nó chỉ là cải tiến hệ thống. Dù bằng cách nào, làm cho trường hợp có thể nhìn thấy.

3) Đơn giản hóa, sau đó tiêu chuẩn hóa, không phải là cách khác.

4) Bạn không thể ủy thác hoàn toàn việc này cho PMO. Người quản lý trực tiếp cần được mua vào, và người đứng đầu đơn vị kinh doanh sẽ cần phải phá vỡ mối quan hệ khi có khiếu nại.

5) Tìm những người chấp nhận sớm thân thiện. Mọi người sẽ phàn nàn về việc mất bao nhiêu thời gian. Bạn cần một người mà bạn có thể chỉ vào và nói, "chỉ mất 15 phút"

6) Đối với các số liệu, đẩy mạnh cho định lượng hơn định tính. Nếu không, bạn có các dự án có màu xanh cho đến một ngày trước khi phát trực tiếp, khi mọi thứ trôi qua một tháng.

7) Nhấn mạnh các kỹ thuật trên các công cụ. Kế hoạch tốt là quan trọng hơn MS Project.

8) Đưa vào một mức độ quá trình liên quan đến nhu cầu. Mọi nhà hàng đều cần quy trình, nhưng Nobu và tiệm giặt Pháp cần một loại khác với McDonalds. Tương tự với các công ty phần mềm.

Chúc may mắn!

— Toán học
nguồn

1

Câu trả lời tuyệt vời - Tôi cũng sẽ thêm rất cẩn thận với quy trình bạn giới thiệu - Đảm bảo bạn không rơi vào bẫy làm việc gì là tốt nhất cho quy trình, không phải điều gì là tốt nhất cho khách hàng - tức là quy trình phải tập trung vào khách hàng. Ngoài ra, hãy cẩn thận với những gì bạn đo lường - theo định nghĩa, đâu là biện pháp quan trọng và những gì không được đo là không quan trọng. Đo lường những điều sai (SLOC / Ngày, Lỗi / SLOC, v.v.) và bạn sẽ không được cải thiện, nhưng các phép đo sẽ cho bạn biết bạn là ai.

— mattnz

1

@mattnz - Tôi không biết, lỗi / SLOC có thể là một số liệu hữu ích nếu bạn áp dụng đúng. Nếu ai đó nói rằng họ trung bình 1 lỗi / 10 SLOC, tôi có thể sẽ lo ngại. Bí quyết là bạn phải biết các thanh ở đâu, có thể khó.

— rjzii

Điểm tốt. Mọi người tối ưu hóa theo số liệu của họ. Nếu bạn sản xuất các số liệu tài chính trước tiên, mọi người sẽ tối ưu hóa điều đó với chi phí cho chức năng hoặc dịch vụ khách hàng. Đó là tất cả về sự cân bằng và ưu tiên.

— MathAttack

1

Đo lường tôi bằng các lỗi / SLOC, SLOC / ngày và bạn sẽ ngạc nhiên về cách tôi có thể tạo mã nguồn mà không cần thêm bất cứ điều gì hữu ích. Ví dụ, vị trí của niềng răng, trên một dòng mới, luôn luôn - càng nhiều dòng càng ít, tôi càng trở thành lập trình viên tốt hơn. Đưa cho tôi bất kỳ biện pháp nào, và tôi sẽ chỉ cho bạn cách tôi có thể làm cho phép đo đó khiến tôi đẹp hơn.

— mattnz

1

@mattnz - Đó là đánh giá mã dành cho ai, nếu ai đó đang tạo mã của họ một cách không cần thiết để che giấu sự thật rằng nó bị đánh cắp lỗi thì tỷ lệ cược là họ không nên viết mã để bắt đầu. Bạn cũng có thể xem xét các khiếm khuyết trên mỗi điểm chức năng cực kỳ khó để giả mạo khi bạn thấy một sự giải thích về số lượng các chức năng với số bị giảm (dấu hiệu xấu) hoặc số chỉ bắt đầu đi xuống khi mã tốt hơn (tốt ký tên).

— rjzii

2

Dựa trên những nỗ lực của bạn trên CMMI có lẽ là một ý tưởng tốt, ngay cả khi bạn không trải qua các cuộc đánh giá và được kiểm toán và đánh giá chính thức. Có rất nhiều tài liệu có sẵn về CMMI , CMMI và các kỹ thuật cải tiến quy trình khác như Lean và Six Sigma , và CMMI và phát triển phần mềm linh hoạt . Các SEI có cả một bộ sưu tập các nguồn lực , một số có sẵn miễn phí, về các khía cạnh khác nhau của CMMI và hướng dẫn với nhiều loại khác nhau của các tổ chức.

Tôi khuyên bạn nên tìm hiểu sâu về cách tiếp cận liên tục để thực hiện CMMI, thay vì cách tiếp cận theo giai đoạn. Đây là một cách hiệu quả hơn nhiều để xác định chính xác vị trí của tổ chức của bạn hiện tại và cải thiện trong các lĩnh vực có thêm giá trị kinh doanh nhất. Điều này sẽ cho phép bạn không chỉ điều chỉnh các nỗ lực cải tiến của mình với các mục tiêu kinh doanh, mà còn nhanh chóng đạt được các mốc tiến bộ và chứng minh các tác động của cải tiến, tăng mua vào từ tất cả các cấp.

Tuy nhiên, một điều cần ghi nhớ là cải tiến quy trình thường thành công hơn khi đó là nỗ lực cơ sở. Khi những thay đổi quá trình được quyết định từ phía trên - bởi những người mà các nhà phát triển "trong các chiến hào" có thể thấy là không liên lạc với cách mọi thứ được thực hiện trong các chiến hào - có lẽ sẽ bị đẩy lùi, ngay cả khi ý tưởng đó là một ý tưởng tốt. Hãy chuẩn bị cho việc này.

Một số loại nhóm quy trình kỹ thuật cũng có thể có lợi. Tập hợp các đại diện của các thành phần tổ chức và các nhóm khác nhau bị ảnh hưởng bởi sự cải tiến để tiếng nói của mọi người được lắng nghe. Điều này sẽ bao gồm không chỉ đại diện của từng vai trò, mà có lẽ các nhóm phát triển sản phẩm khác nhau. Không biết tổ chức của bạn được cấu trúc như thế nào, tôi không thể nói chính xác bạn có thể muốn xem xét ai, nhưng bao gồm mọi người từ mọi cấp của tổ chức trong nhóm. Ngoài ra, làm cho các cuộc thảo luận và quyết định của nhóm này có sẵn cho tổ chức để nhận xét và nêu ra bất kỳ vấn đề nào.

— Thomas Owens
nguồn

Không chắc chắn sẽ thúc đẩy các nỗ lực ở cơ sở như thế nào vì rất ít trong số các nhóm dự án đã chính thức hóa bất kỳ quy trình nào, đó là lý do tại sao điều này sẽ là một quá trình từ trên xuống. Mặc dù vậy, mọi người đều quan tâm đến việc làm cho mọi thứ nhẹ nhàng nhất có thể để ngăn chặn nỗ lực thất bại do thiếu thực hiện thực tế.

— rjzii

@RobZ Theo định nghĩa, bạn không thể thúc đẩy các nỗ lực ở cơ sở - nó phải tự nhiên xuất phát từ dưới lên. Trừ khi các nhóm dự án nhận ra rằng có một vấn đề thực sự, xu hướng là không thay đổi và chống lại những thay đổi được coi là xấu theo một cách nào đó (chẳng hạn như làm cho công việc trở nên phức tạp hoặc khó khăn hơn, thường liên quan đến cải tiến quy trình, mặc dù nó không phải là 't thường là trường hợp).

— Thomas Owens

Chính xác và đó là lý do tại sao quản lý đang chính thức hóa mọi thứ. Đã có vấn đề với một số phần mềm đã ra khỏi cửa và họ đang tìm cách thay đổi văn hóa công ty cùng với việc đảm bảo rằng các sản phẩm xấu không được đưa vào lĩnh vực này một lần nữa.

— rjzii

@RobZ Và khi quản lý bước vào và ra lệnh hành động, nhà phát triển chống lại. Bạn không thể bắt buộc thay đổi văn hóa và hy vọng nó sẽ xảy ra một cách đơn giản và lặng lẽ. Đó là một quá trình dài, đau đớn.

— Thomas Owens

Không ai thực sự mong đợi rằng đó là trường hợp và chúng tôi đã gặp phải sự kháng cự, tại thời điểm này, chúng tôi đang tìm cách để giảm thiểu nó.

— rjzii

0

Đối với mỗi thay đổi:

Gọi ra 1 thay đổi và làm thế nào nó sẽ cải thiện sự phát triển.
Thực hiện thay đổi.
Chứng minh sự cải thiện
Xóa các thay đổi không chứng minh sự cải thiện

Rõ ràng việc phân tích cần phải diễn ra theo thời gian, nhưng không nên thay đổi cho đến khi nó được chứng minh là có hiệu quả. Đó cũng là lý do tại sao tôi sẽ thực hiện không quá 2-3 thay đổi trong mỗi chu kỳ nếu không bạn thường không thể đo lường được liệu có cải thiện hay không.

Không có gì kích thích tôi hơn là mù quáng tuân theo các thực tiễn tốt nhất mà không thực hiện phân tích để cho thấy rằng đó thực sự là một thực tiễn tốt nhất cho môi trường của bạn. Một thực tiễn tốt nhất không chứng minh sự cải thiện là lãng phí tốt nhất và gây thiệt hại nặng nhất.

Tất cả các bước trong quy trình của bạn và tất cả các thực hành trong phương pháp nên được phân tích và chứng minh là có lợi. Nếu nó không phải là nó nên được gỡ bỏ. Phân tích này nên được thực hiện trên cơ sở đang thực hiện bất kể việc thêm hoặc loại bỏ các bước hoặc thực hành.

— chế độ ăn kiêng
nguồn