"품질 컬트"를 만드는 방법 [닫기]


21

DeMarco and Lister (Peopleware)는 프로그래밍 팀 내에서 "품질 컬트"를 만들 것을 제안합니다. 실망스럽게도, 그들은 당신이 그렇게하는 방법을 제안하지 않습니다!

누구나 이것을 달성하는 방법에 대한 생각을 가지고 있습니까?


1
"품질의 숭배"는 시간이 허락하는 한 유효합니다. 보스가 '금요일에 완료해야합니다' 라고 말하면 속도에 대한 품질이 떨어지게됩니다. 분명히 이것은 코더가 선호하는 것이 아닙니다. 이상적으로 우리는 품질을 보장하기 위해 시간을 선호합니다!
반전

1
@WesleyWerner : 좋은 지적입니다. 그러나 '품질의 컬트 (cult of quality)'는 또한 기술 부채를 처리하는 것을 포함해야한다고 생각합니다.
talonx

@invert : 일반적으로 그러한 경우에는 CAP 정리와 유사한 상황이 있다고 대답합니다. 우리는 질과 속도, 인력이 있으며 두 가지를 선택할 수 있습니다.
JensG

답변:


37

내 경험은 개발 팀 (일반적으로 모든 팀)이 3 가지 유형의 사람들로 구성되어 있다는 것입니다.

  • 품질을 높이기 위해 드라이브가 내장 된 기기,
  • 돈 (맥주 / 소녀 / 무엇이든)을 위해 그 안에 있고 동기를 부여하려고 노력하지만 덜 신경 쓰지 않는 사람들,
  • 더 나은 단어가 부족한 "의사".

마지막 그룹이 가장 크며 집권당을 따르는 경향이 있습니다. 팀에 양질의 인력이 충분한 경우 대다수를 스스로 끌어 당겨 팀 정신과 동기 부여에 강한 상향 나선형을 만들 수 있습니다. 그러나 슬랙 커가 너무 많으면 죽음의 나선 인 반대 효과를 쉽게 만들 수 있습니다.

따라서 관리자의 가장 중요한 임무 는 올바른 사람선택하고 유지하고 나쁜 사람을 최대한 빨리 제거하는 것입니다 . "의사"가 아니라 개선을 시작하고, 다른 사람들의 좋은 아이디어를지지하기 위해 영향을받을 수 있으며, 그들 중 일부는 결국 스스로 긍정적 인 트렌드 세터가 될 수도 있습니다.

[업데이트 2] Alb의 답변 : IMO를 반영합니다 . IMO는 팀 내에서 우수한 개발자가 반드시 다수를 차지할 필요는 없습니다. 있다 "경향 설정 임계 값" 하위 그룹의 의견과 행동은 신속하게 지역 사회 내에서 "주류"가 될 수있는 위 , 그래서 다른 사람들이 통지를 타고 따라 시작. 당신은 항상 더 큰 사회에서 일하는 것을 볼 수 있습니다 (예 : 금연 습관, 건강 및 다이어트, 팝 페이드, 유기농 음식). 내 대략적인 추정은 25-30 % 정도가 될 수 있지만 많은 요인에 달려 있다는 것입니다. 이것은 나쁜 사람들이 많이 다칠 수있는 곳입니다. 팀 내의 몇 안되는 나쁜 사람들조차도 그 임계 값을 크게 높일 수 있습니다. [/ 업데이트 2]

물론 최고의 남자들을 충분히 고용하는 것이 항상 가능한 것은 아닙니다. 따라서 첫 번째 진영이 스스로 일을 추진할만큼 강하지 않으면 경영진이 그들을 도울 필요가 있습니다. 이것에 대한 몇 가지 생각 :

  • 스크럼은 제품 데모를 통해 이에 대한 좋은 아이디어를 가지고 있다고 생각합니다. 팀원뿐만 아니라 다른 팀의 개발자, 관리자, 앱 사용자까지 구성된 청중 앞에서 구현 한 기능을 보여주는 것은 자존심의 큰 원천이자 팀이 젤을 도울 수있는 강력한 요소가 될 수 있습니다.

  • 또 다른 것은 경영진이 품질과 관련하여 개발자 팀에게 진지하게 귀를 기울이는 것입니다. DeMarco와 Lister는 개발팀이 생산에 갈 수있는 것을 거부하는 회사 / 부서가 있다고 언급했습니다. 앱이 아직 프라임 타임에 준비되지 않았다고 생각하면 원하는 관리에 관계없이 릴리스를 연기 할 수 있습니다. 이제는 관리하기가 어렵지만 팀 수준을 구축하고 단어 수준이 아니라 품질이 정말로 중요하다는 메시지를 강력하게 전달한다고 상상할 수 있습니다.

  • 그 결과 다음 단계로 이어질 수 있습니다. "품질 컬트"를 만들려면 경영진은 대부분의 숙련 된 개발자가 이미 알고있는 내용을 철저히 이해해야합니다. 따라서 사람들은 장기적인 유지 보수성에 대해 생각 하고 빠른 해결책 대신 좋은 해결책을 찾기 위해 노력해야 합니다.

최신 정보

@Machado는 자신의 의견에 의문을 제기했습니다 (적어도 나에게).

관리자가 아닌 팀 구성원으로서 팀의 코드 품질을 향상시키기 위해 무엇을 할 수 있습니까?

몇 가지 생각 :

  • 계속 듣고 배우는 사람들에게 지식을 전파하십시오 . 전문 분야 에서 모범 사례를 배우고 사용하십시오 .
  • 당신의 일에 자부심을 가지십시오 .
  • 이 두 가지는 거의 자연스럽게 다른 사람들 , 특히 신입생과 후배들 에게 긍정적 인 역할 모델이 될 것입니다 . 이를 의식하고 팀 전체의 이익을 위해 귀하의 역할을 활용하십시오. 다른 사람에게 영향을 미치는 가장 좋은 방법은 긍정적 인 예입니다.
  • 코드뿐만 아니라 소프트웨어 개발의 전체 프로세스를 살펴보십시오. 개발 프로세스최적화 하기 위해 계속 질문하고 피드백을 제공 합니다 .

마지막 으로, "최고의 사람"이 될 수있는 곳을 찾으십시오 . 당신이 지금 "mediocre"그룹에 있다면, 자신을 발전 시키려고 노력하십시오. 그러나 현재 팀의 "더 낮은 지층"에있는 경우 그 이유를 분석하는 것이 좋습니다. 당신을 자극하는 것은 무엇입니까? 나쁜 근무 조건? 팀원? 조치? 일의 종류? 그리고 당신을 흥분시키고 흥미롭게하는 것은 무엇입니까? 동료 나 상사에게 이야기해야 할 수도 있습니다. 또는 더 나은 직업을 찾거나 새로운 직업을 찾아야 할 수도 있습니다. 만족스럽지 못하거나 우울한 활동으로 인생의 많은 부분을 소비 할 가치가 없습니다.

또한 외부 요인으로 인해 현재, 차선책을 유지해야 할 수도 있습니다 (직무 개선 기회 부족, 청구서 지불 등). 때때로 발생합니다. 이 경우에도 최대한 활용하십시오. 양질의 작업 (환경이 허용하는 한도 내에서)을 생산하는 것은 그 자체로 보상이되어, 자존심을 유지하고 장기적으로 자신을 깨끗하고 개방적으로 유지하는 데 도움이됩니다. 따라서 더 좋은 기회가 생길 때 더 잘 준비 할 수 있습니다.


4
위험한 조언. OP가 2/3 그룹에 속하는 경우 어떻게됩니까? ;)

1
큰 대답, 나는 이것에 대해 결코 생각하지 않았지만 너무 말이됩니다.
Alb

9
@Developer라면 DeMarco와 Lister를 읽거나 여기에서 질문하지 않을 것입니다.
Alb

나는 그 질문이 팀원 관점에서 더 지시되었다고 생각했다. 경영진이 정말로 품질을 원한다면 최고 / 핵심 개발자의 말을들을 것입니다. 관리자가 아닌 팀 구성원으로서 팀의 코드 품질을 향상시키기 위해 무엇을 할 수 있습니까?
Machado

1
@ Thorbjørn, 훌륭한 질문입니다! 나는 지금까지 대부분의 직장에서 이것을 놓쳤다는 것을 인정한다. 너무 자기 성취하지 않기를 바라면서 저는 항상 팀원들이 찾아보고 배울 것을 찾고 있었지만 거의 찾지 못했습니다. 그래서 나는 책과 인터넷을 보았습니다. 가능한 한, 나는 Martin Fowler, Uncle Bob Martin 등에서 역할 모델을 찾았습니다. 그리고 최근 SO 커뮤니티에서! 배우기에 훌륭한 곳입니다. 또한 강력한 "현실 점검 공급자". 자신의 지식의 한계와 격차를 드러내는 겸손한 경험은 받아들이 기 어려울 수 있지만 나에게는 매우 건강합니다.
Péter Török

2

Péter Török의 훌륭한 답변 은 대다수의 훌륭한 사람들과 만이를 관리 할 수 ​​있음을 강조합니다. 좋은 사람들이 있으면 지팡이보다는 당근을 더 많이 목표로해야합니다. 개발자에게 권한을 부여하고, 프로젝트 / 태스크의 소유권을 갖도록하고, 품질 측면에서 경쟁을 장려하고, 사람들이 어떻게 프로젝트의 생산성을 개선했는지에 대한 짧은 프레젠테이션을하도록 할 수 있습니다. 좋은 개발자는 동료에게 깊은 인상을주기 위해 동기를 부여받을 것입니다.


동기 부여에 대한 +1 장점. 나는 대다수와 관련하여 분명히 이해할 수 없었습니다. 명확히하기 위해 답변을 업데이트했습니다.
Péter Török

2

Peter의 의견 (실제로 핵심 문제임) 외에도 품질이 나중에 추가되는 기능이 아닌지 확인해야합니다.

더 구체적으로:

  • '나중에 정리하겠습니다'라는 생각의 흔적을 제거하십시오. 대신 올바른 방법으로 시작하기 위해 처음부터 노력하십시오.
  • 변경 사항을 검토하고 개발자 이외의 사람과 관련된 일종의 QA 프로세스를 통해 작업해야합니다.
  • 프로젝트 초기 단계에서 품질에 대한 생각을 강요하십시오. 개발 과정에서 "다른 사람들이 유지하기 쉬운 방법"과 같은 것들에 집중하십시오.
  • 발생하는 버그를 추적하고보고합니다. 트렌드가 있다면 버그의 근본 원인과 싸우는 방법을 살펴보십시오.
  • 소프트웨어를 개선 할 수있는 공예품과 제작자가 자랑스럽게 생각할 수있는 아이디어를 소개합니다.

1

가장 좋은 방법은 출력보다 품질을 높이는 것입니다. 이것은 Lean Software 운동의 전제 중 하나입니다 (Lean Manufacturing 기반). Lean이 무엇인지에 대해 논의하는 긴 블로그 게시물을 작성했습니다 . 품질의 컬트를 만드는 법을 알려드립니다. 직원에게 투자하고 회사에 투자하게하십시오 (금전적 투자가 아니라 개인적 투자).

Dan Pink는 TED에서 우리에게 동기를 부여하는 것에 대해 큰 이야기를했습니다 . 그는 그것을 구체적으로 언급하지는 않지만. 매슬로우의 욕구 계층은 관찰 된 현상을 완벽하게 설명합니다. 고용주가 처음 두 가지 요구를 해결하는 한 (즉, 돈이 문제가되지 않도록 충분한 돈을 지불하는 경우) 남은 것은 소속, 에스테 엠 및 자기 실현입니다.

  • 소속을위한 견고한 커뮤니티를 제공하십시오.
  • 직원이 실수를 할 때 자유롭게 느끼는 환경을 제공하여 성과를 달성 할 때 존중을 쌓을 수 있습니다.
  • 개발자가 자기 실현에 대한 중요한 결정을 내릴 수 있도록 고삐를 건네줍니다.

품질은 지시 할 수있는 것이 아니라 오히려 활성화 된 것입니다. 직원이 최선을 다하고 길을 벗어나도록 신뢰하십시오. 결국, 당신은 그들이 떠나야한다고 그들에게 말해야 할 것입니다. 더 많은 시간을 투입하도록 요구하기보다는

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.