표준과 프로세스 개선이없는 조직에 표준과 프로세스 개선을 어떻게 도입해야합니까?

10

프로세스 개선 구현을 통해 소프트웨어 개발 프로세스를 개선하는 데 중점을 두었습니다. CMMI for Development, 버전 1.3 을 지침으로 사용하고 모범 사례를 전체적으로 또는 부분적으로 채택 할 것입니다. 개발자의 푸시 백 및 저항 정도를 최소화하기 위해 표준 및 프로세스 개선을 도입하는 가장 좋은 방법은 무엇입니까?

standards cmmi process-improvement

— rjzii
소스

궁금한 점이 있는데, 왜 더 많은 버그 가 발생하고 원하는지 이미 알고 있습니까?

— Chris Pitman

2

@ S.Lott 표준없이 버그가 줄어들지 않을 수 있습니까 (소비자 측)? 내 경험에 따르면 프로세스와 표준은 소비자가 버그에서 보는 것을 크게 줄입니다. 존재하지 않는 것은 아닙니다.

— Rig

@RobZ : 나는 당신이 현재 가지고있는 것을 묻지 않았습니다. 나는 아직도 그 질문을 이해하려고 노력하고 있습니다. "구현 프로세스 개선"은 귀하가 요구하는 것에 대한 가장 정확한 설명 인 것으로 보입니다. "표준"은 형식적인 정의를 가지고 있고 그 형식적인 정의를 사용하지 않기 때문에 혼동되는 용어라고 제안합니다.

— S.Lott

@Robz : "코딩 표준"은 "공식 표준"이 아닙니다. 그것은 질문을 명확히 할 것입니다. 다시. "공식 표준"은 W3C, Posix, ISO, IEEE, ANSI 표준입니다. 인정받는 독립 기관에 의해 작성되고 승인되었습니다. 코딩 표준에 대해 이야기하는 경우 질문을 업데이트 하여 "공식"이라는 단어를 제거하고 "코딩"이라는 단어를 사용하십시오. 그 변화로 당신의 질문은 의미가 있습니다. 그리고 중복입니다.

— S.Lott

"프로세스 개선과 관련하여 제목에서"표준 "이라는 단어와 관련하여 단어 표준은 누군가가 작성한 코드에만 적용되지 않습니다"? 뭐? 힌트는 다음과 같습니다. 한정자없이 "표준"이라는 단어를 사용하지 마십시오. 혼란 스럽습니다. "코딩 표준"을 의미하는 경우 해당 문구를 사용하십시오. 다른 종류의 "표준"을 의미하는 경우 "표준"이라는 단어를 한정 문구로 한정하여 말하는 내용을 명확하게하십시오. "표준"은 모호하고 혼동됩니다.

— S.Lott

2

소프트웨어 프로세스 개선 (SPI) 프로젝트를 시작하십시오 . 범위와 목표를 정의하십시오. 표준화에 고유 한 목표가 있고 조직에 적용 가능한 측정 값이 있으면 확실히 도움이됩니다.
표준 채택을 담당하는 담당자를 지정하십시오 . 대규모 조직의 경우 여러 사람 또는 부서 일 수도 있습니다. 중요한 것은 표준화를 담당하는 모든 사람이 다음과 같습니다.
- 전체 그림을 볼 수있을 정도로 전문가
- 팀을 상대하고 변화를 수용 / 협상 할 수 있도록 충분한 영향력
채택하려는 표준과 조직에 적용되는 표준을 모두 다루는 교육 을 개발 하십시오. 그리고 훈련을받지 않은 모든 사람들이 잠재적으로 변화에 저항 할 수있는 한 그것은 정말로 중요합니다. 예를 들어, 대기업에서 근무할 때 모든 신규 직원에게 QA 프로세스, CMMI, ISO 및 품질 관리 시스템에 대해 지시했습니다. 그러한 훈련은 의무적이었다. 또한 품질 관리 프로세스에 대한 지식을 향상시키고 소프트웨어 품질의 중요한 문제에 대한 직원의 인식을 제고했습니다.
변경 사항을 협상 하고 일반적으로 허용되는 관행을 특정 요구에 맞게 조정하십시오. 그것은 실제로 필요하지 않은 무거운 프로세스의 관료주의와 구현을 피하는 데 도움이 될 것입니다.
구현 된 프로세스 개선이 지원되는 방식과 조직에서 충분히 효과적인지 모니터링 합니다.

조직 내에서 진정으로 품질에 관심이있는 모든 사람들을 찾을 수 있다면 도움이 될 것입니다. 아마도 이것이 변경을 촉진하고 성숙한 관행을 확립하는 데 도움이되는 가장 중요한 리소스 일 것입니다.

— 교대
소스

6

하드 노크의 학교에서 몇 가지 생각 :

1) 대부분의 프로세스 개선 이니셔티브는 프로세스 설계에 80 %, 교육 및 사회화에 20 %를 소비합니다. 이 비율을 뒤집습니다. 따르는 평범한 표준은 그렇지 않은 완벽한 표준을 능가합니다.

2) 사람들에게 그들이 일하는 방식을 바꾸라고 요구하는 분명한 이유를 식별하십시오. 비즈니스 사례는 무엇입니까? 이상적으로는 모든 팀에게 개별적으로 혜택을줍니다. 때때로 그것은 단지 체계적인 개선 일뿐입니다. 어느 쪽이든, 사건을 보이게 만드십시오.

3) 다른 방법으로 단순화하지 말고 표준화하십시오.

4) 이것을 PMO에 완전히 위임 할 수 없습니다. 직속 관리자를 구매해야하며, 불만이 제기 될 때 사업부 책임자가 연결을 끊어야합니다.

5) 친절한 얼리 어답터를 찾으십시오. 사람들은 시간이 얼마나 걸리는지 불평 할 것입니다. "15 분 밖에 걸리지 않았습니다"라고 말하고 말할 수있는 사람이 필요합니다.

6) 측정 항목의 경우 정 성적보다 정 성적으로 밀어 넣으십시오. 그렇지 않으면 모든 것이 한 달 씩 미끄러지는 Go Live 전날까지 녹색 프로젝트가 있습니다.

7) 도구보다 기술을 강조하십시오. 좋은 계획은 MS 프로젝트보다 중요합니다.

8) 필요에 따라 일정 수준의 프로세스를 수행하십시오. 모든 식당에는 과정이 필요하지만 Nobu와 French Laundry는 McDonalds와는 다른 종류가 필요합니다. 소프트웨어 회사와 동일합니다.

행운을 빕니다!

— MathAttack
소스

1

훌륭한 답변-또한 소개하는 프로세스에 매우주의를 기울일 것입니다. 고객에게 가장 적합한 것이 아니라 프로세스에 가장 적합한 것을 수행하는 함정에 빠지지 않도록하십시오. 즉, 프로세스는 고객 중심이어야합니다. 또한 측정 대상에 유의하십시오. 정의에 따라 측정 대상이 중요하고 측정되지 않은 대상이 중요하지 않습니다. 잘못된 것 (SLOC / Day, Bugs / SLOC 등)을 측정하면 개선되지는 않지만 측정 결과에 따라 사용자에게 알립니다.

— mattnz

1

@ mattnz-잘 모르겠습니다. 오류 / SLOC를 올바르게 적용하면 유용한 지표가 될 수 있습니다. 누군가가 평균 1 오류 / 10 SLOC라고 말하면 우려 할 것입니다. 비결은 막대가 어디에 있는지 알아야한다는 것입니다.

— rjzii

좋은 지적. 사람들은 자신의 측정 항목에 최적화합니다. 재무 지표를 먼저 생성하면 기능이나 고객 서비스를 희생하여 사람들이 재무 지표를 최적화합니다. 균형과 우선 순위에 관한 것입니다.

— MathAttack

1

오류 / SLOC, SLOC / day로 나를 측정하면 유용한 것을 추가하지 않고 소스 코드를 만들 수있는 방법에 대해 놀랄 것입니다. 예를 들어 새 줄에 중괄호를 배치하면 항상 줄이 많을수록 통계가 적을수록 프로그래머가 더 잘됩니다. 측정 값을 알려주십시오. 측정 값을 개선하는 방법을 알려 드리겠습니다.

— mattnz

1

@ mattnz-그것이 코드 검토의 목적입니다. 누군가 버그로 가득 차 있다는 사실을 숨기기 위해 코드를 불필요하게 장황하게 만들면 코드를 작성하지 않아야 할 가능성이 있습니다. 함수 포인트 당 결함을 볼 수도 있습니다.이 숫자는 숫자가 줄어드는 함수 수에 대한 설명 (잘못된 부호)을 보거나 코드가 나아질수록 숫자가 줄어 듭니다. 기호).

— rjzii

2

CMMI에 대한 노력의 근거는 평가를 거치지 않고 공식적으로 감사를 받고 평가를 받더라도 좋은 아이디어 일 것입니다. CMMI , CMMI 및 Lean and Six Sigma 와 같은 프로세스 개선 기술 , CMMI 및 민첩한 소프트웨어 개발에 대한 많은 문헌이 있습니다 . SEI는 자원의 전체 컬렉션이 조직의 다른 유형에 대해 다른 CMMI의 측면과지도에 대한, 무료 일부 사용할 수를.

단계별 접근 방식이 아닌 CMMI 구현에 대한 지속적인 접근 방식을 자세히 살펴 보는 것이 좋습니다. 조직의 현재 위치를 정확하게 파악하고 비즈니스 가치가 가장 높은 영역에서 개선 할 수있는 훨씬 효율적인 방법입니다. 이를 통해 개선 노력을 비즈니스 목표에 맞추는 것뿐만 아니라 진행 상황을 신속하게 달성하고 개선의 효과를 입증하여 모든 수준에서 바이 인을 늘릴 수 있습니다.

그러나 명심해야 할 것은 공정 개선이 풀뿌리 노력 일 때 일반적으로 더 성공적이라는 것입니다. 프로세스 트렌치가 위에서부터 지시 될 때 (사람들이 트렌치에서) 트렌치에서 작업이 수행되는 방식과 접촉하지 않는 것으로 보일 수 있습니다. 아이디어가 좋은 경우에도 푸시 백이있을 수 있습니다. 준비하십시오.

일부 유형의 엔지니어링 프로세스 그룹 도 도움이 될 수 있습니다. 개선의 영향을받는 다양한 조직 구성 요소 및 팀의 대표를 모아 모든 사람의 의견을들을 수 있습니다. 여기에는 각 역할의 대표자뿐만 아니라 다양한 제품 개발 팀이 포함됩니다. 조직이 어떻게 구성되어 있는지 모른 채로 누가보고 싶어하는지 정확히 말할 수는 없지만 조직 내 모든 수준의 사람들을 그룹에 포함시킵니다. 또한이 그룹의 토론과 결정은 조직이 의견을 제시하고 문제를 제기 할 수 있도록합니다.

— 토마스 오웬스
소스

프로젝트 팀 중 소수만이 프로세스를 공식화했기 때문에 풀뿌리 노력을 얼마나 잘 추진할 것인지 잘 모르겠습니다. 이것이 더 하향식 프로세스가되는 이유입니다. 그럼에도 불구하고, 모든 사람들은 실제 구현의 부족으로 인한 노력의 실패를 막기 위해 가능한 한 부드럽게 작업하는 것에 관심이 있습니다.

— rjzii

@RobZ 정의에 따르면 풀뿌리 노력을 강요 할 수 없습니다. 자연스럽게 아래에서 위로 와야합니다. 프로젝트 팀이 실제 문제가 있음을 인식하지 않는 한, 변경되지 않는 경향이 있으며 어떤 방식 으로든 나쁜 것으로 인식되는 변경 (예 : 작업을 더 복잡하거나 어렵게 만드는 것, 종종 프로세스 개선과 관련되어 있음) 종종 그렇지는 않습니다).

— 토마스 오웬스

바로 이것이 경영진이 공식화하는 이유입니다. 문을 열었던 일부 소프트웨어에 문제가 있었으며 나쁜 제품이 다시 현장에 들어 가지 않도록 회사 문화를 바꾸려고합니다.

— rjzii

@RobZ 그리고 경영진이 개입하여 행동을 지시 할 때 개발자는 저항합니다. 문화적 변화를 요구할 수 없으며 간단하고 조용히 일어날 것으로 예상됩니다. 길고 고통스러운 과정입니다.

— 토마스 오웬스

아무도 사실이 될 것으로 기대하지 않으며 이미 저항에 직면하고 있습니다.이 시점에서 우리는 그것을 최소화하는 방법을 찾고 있습니다.

— rjzii

0

각 변경에 대해 :

1 가지 변경 사항과 개발 개선 방법에 대해 설명하십시오.
변경을 구현하십시오.
개선 시연
개선되지 않은 변경 사항 제거

분명히 분석은 시간이 지남에 따라 이루어져야하지만, 효과가 입증 될 때까지 어떠한 변화도 수용해서는 안됩니다. 그렇기 때문에 사이클 당 2-3 회 이하의 변경을 구현 해야하는 이유입니다. 그렇지 않으면 개선이 있는지 여부를 종종 측정 할 수 없습니다.

실제로는 환경에 가장 적합한 방법 이라는 분석을 수행하지 않고 모범 사례 를 맹목적으로 따르는 것 이상으로 나를 자극하지 않습니다 . 가장 좋은 방법 개선을 보여주지 않는 최적의 낭비에와 손상 최악이다.

프로세스의 모든 단계와 방법론의 모든 관행이 분석되고 유익한 것으로 입증되어야합니다. 그렇지 않은 경우 제거해야합니다. 이 분석은 단계 나 관행을 추가하거나 제거하는 것과 관계없이 지속적으로 수행되어야합니다.

— 다이어트
소스