사람들이 자전거 흘림을 멈추게하려면 어떻게해야합니까 (사소한 일에 중점을 둡니다)?

나는 다른 팀들에게 새로운 코드베이스를 가르치는 임무를 맡았지만 계속해서 문제가 발생합니다. 실제로 사람들과 함께 코드를 살펴볼 때마다 전체 운동이 자전거 헛간 (사소한 문제에 불균형 한 가중치를 부여하는 조직 구성원) 운동으로 전환되기 전에는 멀지 않습니다 . 그들은 코드베이스를 알지 못하지만 코드베이스를 향상시키는 데 도움이 필요하다고 생각하기 때문에 이해할 수 있는 것에 집중합니다 .

Why is that named that? _{(2 분이라는 이름을 가진 이유를 설명하기 위해 10 분 이상 새로운 이름을 토론 함)}

Why is that an abstract base class rather than an interface? _{(설명하는 데 2 ​​분,이 결정의 상대적인 장점에 대해 10 분 이상 토론)}

...등등. 이제 오해하지 않는다 - 좋은 이름과 좋은 일관성있는 디자인이 중요하지만, 우리는 코드가 실제로 무엇을 논의에 도착하지 않는 시스템이 의미있는 방식으로 설계 또는 방법에 대해 설명합니다. 나는 탄젠트에서 사람들을 꺼내기 위해 회의 심판을했지만, 애완 동물의 사소한 문제가 해결되었을 때 코드가 무엇인지, 산만 해져서 더 큰 그림을 그리워합니다.

따라서 나중에 다시 시도하거나 코드베이스의 다른 부분을 사용하여 사람들이 자전거 흘림 효과를 극복하기에 충분한 지식을 얻지 못했기 때문에 반복됩니다.

난 그냥 일부는 다른 사람보다 더 많은 도움이 ... 짧은 즉시 인수를 절단, 사망에 주장을시키는, 작은 그룹, 큰 그룹, 코드, 화이트 보드, Visio 다이어그램, 텍스트의 거대한 벽을 시도했지만, 아무것도 작동하지 않습니다 . 지옥, 나는 심지어 팀의 다른 사람들이 설명하기에 나쁘다고 생각했기 때문에 그것을 설명하려고 시도했습니다.

그렇다면 다른 프로그래머가 사소한 문제에 대한 고착을 멈추고 디자인에 의미있게 기여할 수있을 정도로 어떻게 교육해야합니까?

문제는 "다른 팀에게 새로운 코드베이스를 가르치는 일이었다"는 과제라고 생각합니다.

당신은 잘못된 직업을 받았거나, 당신이받은 직업을 잘못 해석했을 수도 있습니다.

코드 수준에서 발표함으로써 코드 수준 사고를 초대합니다.

시스템 수준에서 시작하여 디자인 및 디자인 선택 사항을 제시하십시오. 확장 된 토론을 허용하지 마십시오. 검토하지 않습니다. 질문을하십시오 : 당신은 그들이 시스템을 이해하기를 원합니다. 사람들이 "다르게 행동했을 것"이라면 괜찮습니다. 아마 동의 할 것입니다. 아님 그러나 계속하십시오. 바로 지금의 방식입니다.

코드 수준에 도달하면 이미 시스템 용어로 준비했습니다. 이름 (나는 가정)이 의미가 있습니다. 위와 동일 : 확장 된 토론 없음, 이해를위한 질문. 어서

이제 몇 가지 클래스 문제를 해결하십시오. 개선 X를 어떻게 만들 수 있습니까? 시스템 설계의 "흐름에 따른"사소하지 않은 것을 선택하고 변경하려는 작업을 수행하십시오. 그들은 이제 시스템의 이론적 근거를 얻고 있어야합니다. 잘못한 경우 시스템을 손상시킬 수있는 다른 개선 사항을 선택하고 올바르게 수행 할 수있는 방법을 보여줍니다. 그것은 그들을위한 Ah Ha 순간 이어야한다 . 어떤 사람들은 당신을 이길 수도 있습니다!

그것은 특히 잘못된 시작 후에 힘든 공연입니다. 당신은 이미 많은 시간과 노력을 투자 한 것으로 들릴 것입니다. 'Fess up하고 다시 시작하십시오. 우리는 그들이 똑똑한 사람이라고 가정합니다. 더 높은 수준의 사고에 도전하십시오. 그리고 새로운 세션에 대해 서로 다른 팀의 크로스 섹션을 선택하여 이미 존재하는 그룹을 분리하십시오.

"그들에게". 공과를 시작할 때 토론 할 내용을 설명하고 주제 외 주제를 명확하게 설명하십시오. 분명히 구약에 관한 질문을 받았다면, 그렇게 말하고 계속하십시오. 그들이 다시 돌아 오면, 나중에 토론하기 위해 화이트 보드에 질문을 작성하고 (이것이 중요합니다) 계속 진행하십시오. 공과가 끝날 때, 당신이 아닌 자신의 시간에있을 때, 그 질문들이 얼마나 빨리 해결되는지보십시오.

기대를 올바르게 설정하고 솔직하고 개방적이며 선결합니다.

목표가 개방적이고 투명해야합니다.

andy256 (+1)에 의해 촉진 된 높은 수준의 견해로 토론을 시작하고 목표를 포함시켜야합니다.

"...이 문제를 살펴볼 때 x, y 및 z에 초점을 맞추지 않도록하십시오. 또한 a, b, c 또는 사소한 세부 사항과 같은 구현 세부 사항도보고 있지 않은지 확인하십시오. j, k, l과 같은 코드에는 많은 세부 사항이 있으며, 해결하거나 개선하거나 표준으로 만들 수있는 것들을 자세히 설명해야하지만 실제로 더 높은 수준에서 달성하고있는 것을 살펴보십시오. "

그렇다면 다른 프로그래머가 사소한 문제에 대한 고착을 멈추고 디자인에 의미있게 기여할 수있을 정도로 어떻게 교육해야합니까?

먼저, 그들의 우려를 "사소한 일"또는 "자전거 흘리기"로 생각하지 마십시오. 그것들은 판단적인 말이며 모욕적입니다. 그들의 우려는 유효합니다. 지금은 중요하지 않습니다.

좋은 만남의 열쇠는 모두가 아는 것입니다.

• 왜 회의를하고 있고
• 당신이 그것에서 벗어나고 싶은 것
• 얼마나 오래 지속되어야합니까

이러한 것들을 미리 명시하고 목표를 설명하십시오.

예를 들어 다음과 같이 말할 수 있습니다. "이 회의에서는 Foo 패키지와이 보고서가보고 모듈에서 사용되는 방식을 익히 게되었습니다. 제 목표는 Foo에 대해 Bar Reports 프로젝트를 진행할 수있을만큼 충분히 이해하는 것입니다. 다음 주에 다음 90 분 안에 마무리 되길 바랍니다. "

그런 다음 주제가 나타나면 다음과 같이 진행될 수 있습니다.

새로운 사람 : "FooWidget은 왜 정면 패턴으로 구현됩니까?"

당신 : "글쎄요, (디자인 결정에 대한 짧은 설명)"또는 "모르기 때문인 것 같습니다."

대답이 충분하면 훌륭합니다. 그렇지 않은 경우 계속됩니다.

NP : "단일 톤으로하는 것이 더 나을 것이라고 생각하지 않습니까?"

당신은 "나는 그것에 대해 정말로 생각하지 않았지만 FooWidget의 작동 방식을 계속 설명하고 싶습니다."

NP : "하지만 싱글 톤으로 완료하면-"

"중단해서 죄송하지만 FooWidget의 작동 방식에 초점을 맞춰야합니다.이 회의는 11:00까지만 예정되어 있으며 많은 시간이 필요합니다. 디자인 토론은 다른 시간을 기다려야합니다. "

이 과정을 한두 번 수행 한 후 "이 회의 범위를 벗어났습니다."

당신이 유의 하지 "그것은 중요하지 않습니다"또는 "닥쳐"또는 또는 "그게 걱정 바보입니다"라고 "당신은 입력이 너무 새로운이야." 당신은 단순히해야 할 일과 시간에 초점을 맞추고 있습니다.

특정 조직에서는이를 달성 할 수 없습니다. 많은 조직이 지적 능력, 근면 및 충성 이상의 정치적 논쟁과 사다리 등반 방식을 중요하게 생각합니다. 그리고 왜 안될까요. 사다리 등반은 사람들을 권력의 위치에 놓아두고 더 많은 재량 소득으로 개인 생활을 향상시킬 수 있으며 실제로는 결코 쓸모가 없습니다.

이 문제를 실제 문제 해결, 추상적 인 사고, 나중에 발생할 수있는 어려운 문제에 대한 결정과 비교하면 많은 직원들이 가능한 한 자전거를 타기 위해 많은 노력을 기울입니다.

내가 제안하는 유일한 조언은 가능한 한 조직의 맥락에서 이러한 참가자의 개인적인 운명 이 해결하려는 실제 문제에 대한 이해, 기여 및 노력에 달려 있다는 점을 분명히 하는 것입니다. 이것이 엔터프라이즈 코드라면이 오류 코드베이스와 모든 실패로 표현됩니다. 그들은 그들에 대해 실질적으로 의미있는 정보 를 제공해야한다는 것을 분명히하십시오 . 다른 어떤 무작위성도 아니고, 그것은 누군가 또는 다른 사람의 애완 동물 피 브로 발생하며, 누군가에게 말했다는 것에 동의함으로써 그들에게 좋은 브라우니 포인트를 얻을 것입니다.

선임의 누군가가 일반적으로 진행되는 기술을 이해하지 못하고, 흥미롭지 않으며, 불행하게도 원재료를 통제하기 때문에, 이것은 종종 어려운 일입니다. 직원 시간; 고용 및 화재, 회의실 정치, 판촉 등을 진지하게, 기타 등등.

당신이 자전거 셰딩이라고 부르는 것을, 나는 누군가의 생각의 흐름을 우리 자신의 것으로 바꾸는 것을 부를 것입니다. 이름, 패턴에 대해 논의함으로써 코드를 자신의 용어로 이해하게되며이를 막을 방법이 없어야합니다.

게다가, 전체 코드베이스에 대해 매우 상세하게 연습 할 필요가 없습니다. 세부 사항은 작업하기 전에 오래 전에 잊혀 질 것이기 때문입니다.

이 두 가지 아이디어를 바탕으로 코드베이스를 단위로 나누고 학습자를 두 사람 그룹으로 나누는 것이 좋습니다. 각 코드 단위에 대해 각 그룹은 25 분 ( 물론 LOC 에 따라 다름 )을 사용하여 다른 사람에게 코드를 5-10 분 동안 안내 할 수 있습니다. 3 분 동안 질문을하고 다음 단원과 반복하십시오. 핵심 단어를 설명하십시오. 그들은 다른 사람들이 모든 것을 이해하도록해야합니다.

당신은 시간을 집행하기 위해서만있을 것이고, 주제를 벗어난 것은 아니며, 유닛을 충분히 이해하지 못했습니다. 그들은 배우의 배우가 될 것이며 자전거 타기보다 다른 사람들에게 설명하는 데 더 집중할 것입니다.

코드 단위의 고급 수작업 스키마가 필요할 수 있습니다.이 스키마는 팀 공유 문서에 복사 및 보관되므로 나중에 참조 할 수있는 내용이 있습니다. 추억을 고정시키는 것도 좋습니다.

이미 시도했다면 죄송합니다 ...

사람들이 개별적으로 살펴볼 수있는 프리-레슨을 만들어 보셨습니까?

내용, 코드 작동 방식 또는 기본적으로 배우고 자하는 모든 내용을 설명하는 짧은 비디오 또는 프리젠 테이션을 작성하여 자신이 직접보고 배우려는 정보를 배우십시오.

그런 다음 팀 기반 세션을 사용하여 컨텐츠와 관련된 문제를 논의합니다. 팀 세션이 내용과 관련된 문제 만 논의하고 해결하기위한 것임을 명확하게 식별해야합니다.

개별적으로 사람들에게 공과를 제공한다면, 단일 문제가 집단으로서 집단의 목소리가되어 공과의 실제 목적에서 멀어 질 수있는 다른 사회적 문제를 피할 수 있습니다.

코드베이스의 디자인을 먼저 가르치고 특정 예제를보기 전에 아키텍처를 안내해보십시오. 그렇게하면 코드 예제가 더 큰 그림에 어떻게 맞는지 알 수 있습니다. 훈련 프로그램이 어떻게 구성되어 있는지 생각해보십시오. 그리고 디자인 뒤에 비즈니스 동기를 포함시킵니다.

몇 년 동안 다른 개발자를 훈련 시켰으며 시스템이 어떻게 조화를 이루는 지 보여주기 전에는 코드를 작성하지 않았습니다. 그런 다음 프레임 워크에서 코드 연습을 할 때 질문이 구조화되고 주제가되었습니다.