(주) 개발자가 개발 / IT 팀에서 더 나은 프로세스와 관행을 추진하도록 노력해야합니까?

저는 변경 사항을 정당화 할 수 있고 팀이 업무를 수행하는 데 도움이된다면 팀 프로세스를 구성 할 수있는 능력을 갖춘 주니어 개발자입니다. 과거의 회사가 관리에서 나온 프로세스를 엄격하게 정의했기 때문에 이것은 새롭습니다.

우리 팀은 상당히 작고 다소 새롭습니다 (<3 세). 그들은 부족합니다 :

• 잘 정의 된 소프트웨어 개발 / 작업 관리 프레임 워크 (예 : 스크럼)
• 강력한 제품 소유권
• 잘 정의 된 역할 (예 : 비즈니스 직원이 수동 테스트를 수행함)
• 정기 회의
• 통합 된 이슈 추적 프로세스 (도구가 있으며 프로세스는 아직 개발 중임)
• 단위, 시스템, 회귀 또는 수동 테스트 스위트 또는 목록
• 비즈니스 로직 및 프로세스에 대한 문서
• 내부 및 고객 대면 팁을 문서화하는 기술 자료

그리고 목록은 계속됩니다. 가치가 정당화되고 가장 중요한 작업 (즉, 개발)을 수행하는 데 도움이되는 한, 관리는 개선 구현에 개방적입니다. 그러나 기본 가정은 아무도 당신을 위해 그것을하지 않을 것이므로 구현에 소유권을 가져야한다는 것입니다. 그리고 위의 프로젝트 중 일부는 사소한 것이 아니며 시간이 많이 걸리지 않으며 개발 작업이 아닙니다.

시간이 지남에 따라 위의 사항을 시도하고 추진하는 (주니어) 개발자의 노력이 가치가 있습니까? 아니면 "차선을 유지"하고 개발에 집중하고 프로세스 정의와 최적화를 관리에 맡기는 것이 가장 좋습니까?

지금까지 좋은 답변이지만 모든 기반을 다루지는 않습니다.

내 경험상 대학을 졸업 한 많은 사람들은 환상적인 이론적 지식을 가지고 있습니다. 저나 다른 노인들보다 수십 년 동안 생활용 소프트웨어를 구축 한 사람들보다 훨씬 낫습니다.

그러나 그것은 큰 BUT이지만 지식은 실제 시나리오에 근거하지 않습니다. 현실 세계에서, 그 이론의 많은 부분은 평평 해 지거나, 실세계 시나리오에서 실제로 잘 작동하지 않는 것으로 밝혀 졌기 때문에 최소한 소금 한 덩어리로 취해야합니다.

예를 들어 : 내가 오래 전에 작업 한 애플리케이션은 훌륭한 OO 이론가에 의해 설계되었으며, OO 원칙과 이론을 T에 따르도록 설계되었으며, 모든 곳에 패턴이 많이 적용되었습니다.

환상적인 소프트웨어 디자인이었습니다.

안타깝게도 이로 인해 생산 및 유지 관리의 악몽이 발생했습니다. 코드베이스는 너무 크고 복잡하여 장소를 변경할 수 없었습니다. 특히 부서지기 쉽기 때문에 너무 복잡했기 때문에 아무도 일어날 일에 대해 두려워하지 않았습니다 (원래 건축가 / 디자이너는 오랫동안 떠난 계약자였습니다).

또한 패턴의 다층 구조와 필요한 디자인 클래스 라이브러리로 인해 성능이 매우 떨어졌습니다. 예를 들어, 데이터베이스에서 단일 호출을하기 위해 화면의 버튼을 클릭하면 수백 개의 객체 인스턴스화와 메소드 호출이 발생합니다.

이 건축가는 그의 이름에 관한 주제에 관한 몇 권의 책을 가지고있는 대학 교수였습니다. 그는 상업 프로젝트에서 프로그래머로 하루를 일한 적이 없었습니다.

소프트웨어 구축에 대한 실질적인 경험을 가진 사람들은 디자인이 불가피하게 더 실용적인 접근 방식을 가져 와서보다 실용적인 접근 방식을 취함으로써 유지 관리가 쉽고 더 나은 시스템을 만들 수 있다는 사실을 깨달았을 것입니다.

신입생 또는 실제로 어떤 회사의 신입 사원으로 만나는 다른 많은 것들에도 동일한 내용이 적용될 수 있습니다. 이론적 근거가 무언가 잘못되었거나 차선책이기 때문에 그렇게 할 이유가 없다고 가정하지 마십시오.

지금도이 분야에서 20 년이 넘는 경험을 쌓아온 저는 함께 일하는 회사에서 일을하는 방식에 대해 비판하고 있습니다. 나는 통과 할 때 내 경험이 가장 최적이지만 호전적인 방식이 아니라는 것을 알았습니다. 이것은 종종 왜 그런 것들이 있는지에 대한 흥미로운 대화로 이어집니다. 변화의 가치가 비용보다 작은 지에 따라 변화가 일어날 수도 있고 아닐 수도 있습니다.

일이 더 잘 될 수 있다고 제안하는 것을 두려워하지 말고 항상 당신이 알고있는 모든 코가 아닌 아이로 배우지 말고 배우는 것뿐만 아니라 배우려고 노력하고 기꺼이 노력하는 동료로 오지 않도록하십시오. 이론적 정확성뿐만 아니라 회사의 개선을위한 프로세스 개선에 도움을줍니다.

예 ,하지만 많은주의를 기울여야합니다!

그것을 명확히하겠습니다.

소프트웨어의 거주 성을 향상 시키려고 노력해야합니다. 코드 / 팀 / 비즈니스 / 프로젝트 / 관리를보고 첫 번째 응답이 샤워를하는 것이라면, 그것은 습관적이지 않습니다. 당신의 첫 번째 대답은 yeah! ...을 외치고 외출 할 때 불평을한다면 집을 더 거주 할 수있게 만들어야합니다. 느낌, 당신은 그것을 알게 될 것입니다.

즉, 당신은 복잡한 공상으로 일하고 있습니다. 당신이하는 일은 잘못 될 가능성이 있으며, 간단한 변화에는 파문이 있기 때문에 적어도 단기적으로 상황이 악화 될 수 있습니다. 그래서 먼저 겸손 해지십시오. 나는 밀어 붙이거나 물건이 나쁘다는 것을 받아들이려는 것이 아닙니다. 나는 당신의 좋은 의도가 당신을 악의적으로 켜 놓을 것이라는 사실에 동의합니다.

문제

최선의 의도로 당신은 광범위한 변화가 일어나야한다고 생각할 수 있습니다. 나는 이러한 상황이 존재한다는 것에 동의하지 않지만 그것에 대해 생각하는 데 잠시 시간이 걸립니다. 현재 시스템이 작동하고 있으며, 귀하와 귀하의 팀이 코드를 생성하고 있습니다. 느리거나 어려울 수 있습니다. 당신은 대략 무엇을 기대해야하는지, 간단히 말해이 시스템의 전문가입니다.

그러나 변화를 겪은 후에는 아마도 구현자를 제외하고 아무도 무엇을 기대해야하는지 알지 못합니다. 한마디로 모든 사람이 시스템의이 부분에서 네오 피트 수준으로 재설정되었습니다. 그 좋지 않다. 신 생물은 시간이 걸리는 새로운 규칙을 배워야합니다. 그 당시 신 생물은 연습을하지 않았기 때문에 실수를하고 있습니다. 이러한 실수는 이제 당신이 살아야 할 시스템의 일부가되며, 지금은 반짝 거리지 않습니다.

앞으로 나아가는 길

슬래시, 레코딩 및 재 구축이 훨씬 더 좋은 경우가 있습니다. 구식 시스템에서 아무도 연습하지 않으면 특히 매력적입니다. 왜냐하면 잃어버린 유일한 것은 체계화 된 지식이기 때문입니다. 이 지식을 완전히 이해할 수 없다면 이미 잃어버린 것부터 시작하는 것이 유일한 선택입니다. 반대로 체계화 방법 또는 그것이 어떻게 사용되었지만 문제가 있지만 기능이 있다면, 그 지식은 여전히 ​​접근 가능하고 아마도 가치가있을 수 있습니다.

다른 선택은 모든 사람이 참조 프레임을 갖도록 시스템과 함께 작업하는 것이지만 팀의 모든 사람이 알 수 있도록 시스템의 작은 부분을 변경하거나 변경 사항을 알지 못하는 경우 모두 쉽게 수행 할 수 있습니다. 통지하고 배우기 쉽습니다. 이것이 Kaizen 이라는 관행의 기초입니다 . 골든 야크를 면도하는 프레젠테이션에서 더 개발자 중심의 공식이 제시됩니다. 그것을보고 생각하는 것이 좋습니다.

그러므로 당신의 삶을 향상시킬 수있는 작은 것을 찾으십시오. 상황을 수정하거나 개선하십시오. 이를 통해 변경 사항을 실제로 적용하는 방법과 실습이 제공됩니다. 피드백을 받도록하십시오 : 더 잘 논의 할 수 있었는지, 실제로 유용한 지, 시스템의 다른 부분을 화나게 했습니까? 수행 할 수있는 작업과 수행 방법에 대한 느낌을 개발하십시오.

이제 세 가지 일이 발생했습니다.

• 시스템을 개선했습니다
• 시스템을 변경하는 방법에 대한 경험을 얻었습니다
• 팀이 시스템을 성공적으로 변경하는 것을 보았습니다.

이제 경험이 커지고 교수형 문제가 줄어듦에 따라 시스템에서 더 어려운 문제에 직면하기 시작하지만 적어도 지금은 X를 변경해야한다고 말할 때 개선해야 할 또 다른 사항을 선택하십시오.

• 변경 사항이 시스템에 어떤 영향을 미치는지 알고 있습니다
• 어떤 문제가 발생할지 알고 있습니다 (어떤 규칙을 다시 학습해야하는지)
• 변경으로 인해 발생할 수있는 문제를 해결하거나 개선 할 수있는 즉각적인 방법을 알고 있습니다
• 주변 사람들은 시스템에 대해 잘 알고 있으며 시스템을 성공적으로 변경할 수 있음을 알고 있습니다.

그래 넌 할수있어. 그러나...

조심해야합니다.

내 경력이 시작될 때 (오래 아주 오래 전) 나는 "주니어"라는 몇 개월 된 프로젝트에 참여하는 것이 운이 좋았다.

내가 처음 알게 된 것처럼 (OMG) 코드 저장소가 없었습니다! 우편으로 서로 zip 파일을 보내어 모든 코드 병합을 수동으로 수행했습니다.

그래서 나는 또한 (새로운) 관리자에게 가서 저장소가 필요하다고 제안했다. 대답은 다음과 같습니다

따라서 도움없이 코드 리포지토리를 구성하는 것이 회사에서 새로운 일이었으며 이제는 겸손한 경험이었습니다.

내가 모두 설정했을 때, (충격) 아무도 그것을 사용하고 싶지 않았습니다. 그래서 나는 일을 추진하려고했지만 운 좋게도 내 관리자는 그것이 중요하다는 것을 이해했기 때문에 지원을 받았습니다.

그러나 이것은 내가 좋아하지 않았고 불행히도 소스 제어 시스템에서 파생 된 별명을 얻었습니다.

그래서 이것에 대한 나의 취지는 먼저 팀원들에게 다음에 설정하는 것이 중요하다고 생각하는 것입니다.

어쩌면 그들은 당신과 같은 목록을 가지고있을 수도 있습니다. 어쩌면 그들은 모든 것을 통과했지만 목록에서 그 "일"을하고 싶었습니다. 어쩌면 그들은 .... (무엇이든) ....

팀 전체를 조정해야합니다.

그러나 그렇지 않다면 여전히 전문적으로 일할 수 있습니다. 그리고 마음이 맞는 사람을 찾아서 어떻게해야한다고 생각하는지 함께 협력하십시오. 이것이 좋은 결과를 가져 오면 더 많은 사람들이 귀하와 함께 일하게되고 결국에는 "the"프로세스가됩니다.

코드와 마찬가지로 개발 프로세스에서도 마찬가지입니다. 지속적인 개선이 필요합니다.

그렇습니다. 항상 개선하려고 노력해야합니다.

또한 함께 일하는 많은 사람들을 기억하고 이미 전문가 일 수 있으며 무엇이 잘못되고 무엇이 필요한지 알고 있습니다.

시간이 지남에 따라 위의 사항을 시도하고 추진하는 (주니어) 개발자의 노력이 가치가 있습니까?

그렇습니다. 일을 개선하고 개선하기 위해 항상 노력할 가치가 있습니다. 당신은 결국 어떤 문제에 직면했는지 가장 잘 압니다.

그러나 언급했듯이 해결해야 할 많은 문제가 있으며 그 중 많은 문제는별로 귀중하지 않습니다. 그리고 많은 곳에서, 당신의 성공 또는 그들을 더 잘 위치시키는 다른 사람들에게는 극복 할 수없는 장벽이있을 것입니다. 그래서 당신은 항상 따기 의미하더라도, 더 좋은 상황으로 만들려고해야 하는 것들을 더 잘 만들려고 노력하는 당신의 시간을 보내고 있습니다.

결국 솔루션의 일부가 아닌 경우 문제의 일부가되기 때문입니다.

예. 그러나 조직의 변화는 선임자에게도 어려운 일이므로 실제로 변화를 원한다면 올바른 방법으로 변화를 취하십시오.

• 첫 주 동안은 아님 : 이 시간을 사용하여 다음을 수행 하십시오.

  • 좋은 첫 함침을 만드십시오. 팀에 적합하다는 것을 보여주십시오.
  • 부족한 문화와 정치 또는 회사. 변경을 추진하는 것이 안전합니까?
  • 동료와 좋은 관계 구축
  • 팀의 프로세스, 규칙 및 요구 사항에 대해 학습
  • 일을 배우고 최선을 다하십시오. 당신은 분명히 충분히 바쁠 것입니다.

• 전투를 선택하십시오. 초기 승리를 거두십시오 : 모든 것을 바꾸기 위해 에너지를 가지고 도착할 수도 있지만 이것은 비현실적입니다. 매달린 과일에 집중하고 아이디어가 효과가 있음을 보여주십시오. 더 복잡한 개선을 수용하기를 원합니다. 그리고 책에서 일이 더 쉽다는 것을 기억하십시오.

• 다른 사람들에게 미치는 영향을 고려하십시오 . 많은 파일에 영향을 미치는 리팩터링을 수행합니다. 그들이 코드를 개선하더라도 병합을 엉덩이의 고통으로 바꾸지 않도록 매우 조심해야합니다. 그들이 계속 그렇게 작동하는 이유를 이해하도록 노력하십시오. 테스트가 부족하고 테스트되지 않은 코드를 자주 프로덕션에 푸시하는 것을 두려워하여 스크럼을 사용할 수 없을 수도 있습니다. 실현 가능한 테스트를 작성하는 것은 쉬운 일이 아닙니다. 현재 코드는 실제로 테스트하기 어려울 수 있습니다. 또한 팀은 테스트 또는 테스트 가능한 코드를 작성하는 데 사용하지 않아야합니다. 현재 코드베이스는 특별히 테스트하기 어려울 수 있으며 리팩터링해야합니다. 이 문제를 변경하는 데 몇 년이 걸릴 수 있지만 최소한 근본 원인에 초점을 맞출 수 있습니다.

• 판단하지 마십시오. 요구하지 마십시오. 요청하고주의 깊게 들어보십시오. 이것은 의사 소통이 중요하고 프로그래머가 미묘한 뉘앙스에 능숙하지 않은 순간입니다. 도움이되는 기술이 있습니다 . 답에 초점을 맞추는 대신 아이디어를 계속 추진하는 것이 쉽습니다. 먼저 그들이 당신이 그들의 포인트를 가지고 있다고 느끼는지 확인하십시오. 감정이 중요하다는 것을 이해하십시오. 이 변화로 인해 기분이 어떻습니까? 무서움? 불충분? 분노? 좌절? 기대? 게으른? 바보? (사람들을 바보처럼 느끼게하지 마십시오). 물론 당신은 이전에 많은 질문을했을 것이고, 이것은 많은 잘못된 발걸음을 막을 것입니다.

• 예를 통해 리드 : 불평은 쉽고 변경을 만드는 것은 어렵습니다. 결과를 보여 주면 사람들이 당신을 믿을 것입니다. 그들이 테스트를 사용하지 않으면 단위 테스트를 작성할 수 있습니다. 사람들이 문서화하지 않으면 일부 Google 문서를 팀과 공유 할 수 있습니다. "Ok, do"는 가능한 최상의 시나리오 중 하나이며이를 제공해야한다는 것을 이해하십시오. 이 경우 어떤 리소스가 필요할지 생각해야합니다 . 예 : Jenkins 서버의 관리자로부터 2 시간 동안 작은 Amazon 인스턴스를 제공하십시오.

• 작고 간단하게 유지 (그리고 저렴하게) : 공식 예산 승인을 기다리거나 상사에게 값 비싼 프로그래머의 귀중한 시간을 잃고 있다고 생각하지 않도록하십시오. 이 코드가 소프트웨어를 검토하거나 여러 오픈 소스 도구를 평가하는 것이 좋을 것입니다. 그러나 우리는 지금 repo를 사용할 것입니다.

• 중요한 집단 확보 : 품질 향상에 중점을 둔 사람들을 모으십시오. 회의에 참석하여 도움이나 멘토링을 요청할 수도 있습니다. Peopleware 는 팀의 기반과 함께 "거대한 현상 깨우기"가 말 그대로 생산성을 저하시키는 어리석은 관행에 반기를 나타냅니다. 이것은 개인적으로 정말 위험했을 것이며 권장하지 않았습니다. 그러나 모든 그룹이 동의하면 변경이 더 쉽습니다.

• 시간 좀 줘 그런 다음 발로 투표하십시오 : 몇 개월에서 최대 2 년 동안 시도해 볼 수 있습니다. 그러나 일부 회사에는 쉬운 솔루션이 없습니다. 일부 팀은 변경하기를 원치 않으며 인센티브가 없습니다. 그리고 일부 코드 기반은 순수한 공포입니다. 당신이 세상에 반대한다고 생각한다면, 직업 풀에 많은 제안이 있다는 것을 기억하십시오. 당신은 좋은 습관을 배우고 싶고 장기적으로는 임금이 상당히 적지 만 더 가치있는 경험을 얻는 것이 좋습니다.

보너스 : CV / 인터뷰를 위해 적어 두십시오. 주니어는 일반적으로 말할 것이 거의 없으며 더 나은 변화를 만드는 것은 항상 좋은 징조입니다. 당신은 당신이 개인적으로 한 일과 다른 사람들의 일에 대해 매우 명확하고 현실적인 견해를 갖기를 원합니다. 다음의 인터뷰 질문을 상상해보십시오.

• 당신이 팀을 변화시킨 시간에 대해 말해주세요.
• 글쎄, 나는 그들이 매우 구식의 관행을 가지고 있었던 곳이었습니다. 많은 사람들이 그것에 만족하지 않았고 생산성은 개선 할 여지가 컸습니다. 그래서 나는 회고를 ​​가지고 빠른 실험을 하자고 제안했다. 우리는 X와 Y를했다. 그 결과 우리는이 훌륭한 결과를 얻을 수 있었다. "

예. 그러나 당신이 제안하는 것은 아닙니다.

목록에서 단위 / 통합 테스트는 진행할 수있는 유일한 항목입니다.

최소한의 시간 투자로 직접 추가를 시작하고 즉각적인 가치를 보여줄 수 있습니다. 널리 받아 들여지는 이점이있는 기술적 문제이며 다른 업무 관행에는 영향을 미치지 않습니다. 또한 결과를 받아들이지 않아도 코드베이스에 대한 지식을 얻을 수 있습니다. 쉬운 판매.

다른 팀은 일반적으로 전체 팀 또는 다른 팀과 관련된 비즈니스 프로세스입니다. 개선 사항을 제안 할 수는 있지만 하급 직원이 변경하기가 어려울 수 있으며 변경하는 프로세스는 일반적으로 기술적이지 않으며 정상적인 작업과 관련이 없습니다.

또한 CI 파이프 라인 설정, 자동화 된 배포, 버전 관리, 라이브러리를 공격하기에 좋은 패키지로 패키징하는 것도 좋습니다.

그것은에 달려 있습니다 :

• 더 나은 사례에서 얻을 것으로 예상되는 금액
• 거기에 도착하는데 얼마나 많은 노력을 기울여야합니까
• 간단한 채택 실패에서 새로운 관행에 이르기까지 실제로는 끔찍하고, 코드 품질이 저하되고, 핵심 인물이 떠나고, 모든 사람이 당신을 미워하고 다른 도시에서 다른 사람의 이름을 모르는 다른 직업을 찾아야합니다.

기본적으로 : 자신이 생각하는 최선의 것을 옹호하는 데 합리적인 시간을 보내는 것이 귀하의 책임 안에 있습니다. 그러나 결정은 팀 또는 관리 책임이어야합니다. 더 나은 관행으로 끝나더라도 사람들을 소외시키는 것이 그다지 가치가 없다는 것을 명심하십시오.

스크럼과 같은 가장 복잡한 것부터 시작하지 마십시오. 가장 쉬운 단계부터 시작하십시오.

소스 코드 관리에 대해서는 언급하지 않았습니다. 소스 코드 저장소 (git, svn, cvs 등)가 있습니까? 태깅 및 브랜칭 전략? 이는 초보자가 할 수있는 간단한 단계입니다. 이 단계 (시도)로 해결되는 문제와 회사가 비용을 줄이는 데 도움이되는 방법 (관리자가 관심을 갖는 부분)을 읽으십시오.

다음 단계는 예를 들어 Jenkins와 같은 모든 체크인 후 매일 밤 또는 자동으로 자동화 된 빌드가 될 수 있습니다. 테스트를 자동으로 실행할 수도 있습니다. 코드 품질을 측정하기위한 몇 가지 도구를 추가하십시오 (예 : 일부 코딩 표준을 정의하는 것도 좋은 단계입니다).

스크럼에 대해서는 "Extreme Programming"(XP)에 대해 더 잘 읽어보십시오. 스크럼은 XP의 많은 아이디어를 기반으로하고 그 주위에 공식화 된 프로세스를 추가합니다. XP의 개념은 해당 프로세스 없이도 계속 사용할 수 있습니다.

사물을 제안하고, 배경 정보를 제공하고, 다른 사람들이 시도해 보도록 유도하고, 결과를 분석하지만, 다른 사람들과 많은 협력을 기대하지 마십시오. 대부분의 사람들은 오래된 나쁜 습관을 고집하는 것을 선호합니다. 그러나 시도하지 않으면 아무것도 개선되지 않습니다.

당신은이 팀이 아주 새롭다 고 말 했으므로 (3 세), 지금 좋은 원칙을 소개 할 수 없다면 10 년 후에는 더 어려워 질 것입니다. 테스트 및 버전 관리 시스템과 같이 언급 한 사항 중 일부는 이미 제안 할 수있는 사항 중 하나이지만, 명백한 이점에 중점을두고 개발 스택에 필요한 도구를 선택하지 않고 제안을 포기하지 마십시오.

처음에는 질문하십시오

목록을 읽으면 다음 질문을 제안합니다 (자세한 내용은 목록을 참조하십시오).

• 비즈니스 소유자가 요청한 작업을 어떻게 알 수 있습니까?
• [Scrum]을 사용해 보셨습니까?
• 이 제품의 소유자는 누구입니까?
• 어떤 역할이 있습니까?
• [이 역할]은 무엇을합니까?
• [이 활동]에서 어떤 역할을 담당합니까?
• 매일 스탠드 업을 시도 했습니까?
• 팀원들에게 장애를 어떻게 전달합니까?
• 다른 팀원이 어떤 일을하고 있는지 어떻게 알 수 있습니까?
• 이슈 추적 도구에 [this]를 넣어야합니까?
• 이슈 추적 도구에 [this]를 어떻게 써야합니까?
• [this]가 발생하면 이슈 추적 도구에 [that]으로 넣어야합니까?
• 우리는 어떻게 테스트합니까?
• 다른 사람들이 재사용 할 수 있도록 테스트를 어떻게 기록합니까?
• [JUnit]을 사용해 보셨습니까?
• [this]는 어디에 기록되어 있습니까?
• [MediaWiki]를 사용해 보셨습니까?

질문이 이해되거나 우선 순위에 맞도록 [브래킷]에있는 것을 교체하십시오. 내 문구가 귀하의 스타일과 일치하지 않으면 리워드를 고려하십시오.

이미 시작했을 수도 있습니다. 그룹 대화보다 일대일 대화를 선호하십시오. 일대일이기 때문에 상대방의 생각을 더 잘 읽을 수 있습니다. 이 사람이이 변경에 해당합니까? 반대? 약하게? 어리석게?

새로 왔을 때 질문하는 것은 사실상 무료입니다. 사람들은 당신이 질문을 기대해야합니다. 당신의 질문이 암묵적으로 반대하는 입장을 암시한다고하더라도 화를 내지 말아야합니다. 그들은 왜 그 입장에 반대하는지 설명해야합니다. 나는 그들과 논쟁하지 말 것을 권한다. 논쟁은 설득력있는 것보다 더 많은 입장을 강화시키는 경향이 있습니다. 누가 어떤 자세를 취하고 나아가는지 주목하십시오.

나중에 조치를 취하십시오

귀하와 다른 사람 (예 : 귀하가 이전에 동의 한 것으로 알려진 것)이 원하는 변경을 시작할 수있는 방법을 찾으십시오. 모두가 스탠드 업을 원하지는 않습니까? 왜 안돼? 아마도 하나를 원하는 사람들은 자신의 스탠드 업을 가질 수 있습니다. 전체 팀만큼 효과적이지는 않지만 지금보다 더 효과적입니다.

장애가있는 경우 (스탠드 업에서 공유 할 수 없다고 가정 할 경우) 팀에 이메일을 보내 도움을 요청하십시오.

귀하와 동의하는 다른 사람들의 도움을 받아 역할이 무엇인지 파악하십시오. 일에 자신이해야 할 것으로 생각되는 역할 (일부 그룹)이 관련 될 때 일관되게 사람들을 만나십시오. 그들이 밀려 나면, 누가 그 역할을 소유해야하는지 확인하도록 요청하십시오.

제품 소유자 (확인한)에게 제품이 현재와 미래에 어떻게 작동해야하는지에 대한 설명을 작성하도록 요청하십시오.

테스트 프레임 워크를 설치하고 (다른 사람들이 선호하는 경우 어떤 프레임 워크를 공동으로 결정하는지) 프로젝트에 사용하십시오. 버그를 고칠 때는 테스트를 작성하십시오. 이를 이슈 트래커의 버그 보고서에 문서화하십시오 ([location]에 저장된 버그를 보여주는 테스트 작성). 다른 사람이 변경을 할 때 테스트를 실행하도록 권장하십시오. 그렇지 않은 경우 직접 테스트를 실행하고 필요에 따라 추적기에 문제를 제출하십시오.

관리 지원을받을 수있는 경우 Wiki 소프트웨어 또는 이와 유사한 것을 설치하고 문서화를 시작하십시오. 사람들이 문서를 읽지 않았다는 질문을하면 관련 페이지를 가리 키십시오. 그들이 문서를 이해하지 못하면 더 많은 질문을하도록 격려하십시오. 그들이 문서에 포함 된 질문을 계속하면 대답 할 때 문서에서 인용하십시오. 문제가 읽지 않고 구조적이라고 생각되면 위키를 업데이트하도록 권장하십시오.

한 번에 하나의 작업에만 집중하는 것이 좋습니다. 그리고 한 번에 하나만 밀어주십시오. 강하게 밀지 ​​마십시오. 그룹이 원하는 것보다 더 강하게 밀고있는 이 예 를 보십시오 . 그들의 행동보다 행동 변화에 더 집중하십시오. 당신의 길이 올바른 길이라면, 그것은 당신을 관찰하는 사람들에게 분명해야합니다. 행동은 말보다 더 크게 말합니다. 조금씩 움직일 때 같은 사람과 반복하지 마십시오. 말을 물로 안내 한 후에는 언제 또는 다른 사람에게 마실 것인지 선택하십시오.

결국, 당신은 수석 될거야

시간이 지남에 따라 팀은 새로운 사람들을 고용 할 것입니다. 당신은 신입 사원이되는 것을 멈추고 새로운 사람들과 당신의 입장을 옹호 할 수 있습니다. 그들과 협력하여 변경하십시오. 또한 기존 팀원들과도 진전이 있음을 알 수 있습니다. 또는 그것이 효과가 없다면, 더 나은 관행을 가진 새로운 직업을 찾으십시오. 서두르지 않습니다. 당신은 직업이 있습니다. 더 나은 직업을 찾거나 더 나은 직업을 찾음으로써 더 나은 직업을 갖는 동안 잠시 기다릴 수 있습니다.

짧은 답변 : 아니요. 다른 답변에 요약 된 모든 이유가 있습니다. 중간 또는 수석 개발자 인 경우에도 일반적으로 새 팀에 합류 할 때 먼저 이해 하는 것이 좋습니다 .

제안 된 해결책 :

1) 개선해야한다고 생각 될 때마다 주목하십시오! (노트북, 디지털 메모에서 ...)

2) 6 개월 후 메모로 돌아가서 확인하십시오. 이제 얼마나 많은 아이디어가 무의미하고 부적절하다고 생각합니까? 아마 많이, 당신은 자신을 약간 당황스럽게 구했습니다. 아이디어가 여전히 남아 있다면, 가능하면 먼저 직접 테스트하여 아이디어를 소개 할 수있는 좋은시기입니다.

늦게 답변하고 다른 답변에는 많은 좋은 내용에 동의합니다.

여기서 중요한 문제는 특정 관행이 아니라 전반적인 팀 문화라는 것입니다.

• 문화적 변화를 만드는 것은 어렵습니다 .
• 더 "주니어"로 본다면

지속적인 개선 을위한 수단이 있다면 다른 모든 것이 따를 수 있습니다 .

이를 달성하기위한 나의 접근 방식은 다음과 같습니다.

• 문서화 된 프로세스 및 절차
• 프로세스 문서에 대한 조치가 변경되는 팀의 회고.

스프린트가 없다면 아직 규칙적인 레트로가 없습니다. 필요한 것은 팀과 대화 한 다음 행동하는 것입니다.

당신은 쉽게 프로세스를 문서화 시작할 수 있습니다. "나는 새로운 사람이야, 내가 이걸 얻었나? 내가 적어 보자." 그런 다음 실제로 프로세스를 직접 따르거나 중단되는 곳으로 전화를 걸어보십시오.

어쩌면 그런 대화에서 임시 로 시작한 다음 정기적 인 의식을 제안 할 수도 있습니다 .

이 방법을 사용하면 점차적으로 부드럽게 접근 할 수 있습니다. 당신은 그들이 모두 알고있는 것 중학교에 출석하는 것을 피하고 대신 팀을 변화시키기위한 촉진자가 되려고 노력합니다.

몇 가지 고려 사항 :

• 일부 팀은 프로세스가 좋지 않지만 실제로는 이미 알고 있습니다. 그들은 변화를 원하고 그것을 촉진하기 위해 무언가가 필요합니다. 다른 팀은 실제로 방해가되었고 변경하기가 훨씬 더 어려웠습니다.
• 개인도 마찬가지입니다.
• 당신은 그 점에 민감해야하고 팀의 누구에게 변화가 열려 있고 누가 그렇지 않은지를 알아 내야합니다. 이유를 이해하십시오.
• 쉬운 승리를 찾으십시오.
• 팀의 변화를 환영합니다 : 개별적인 문제를 찾아 해결하십시오.