작업 방법론 (예 : 스크럼)을 따르지 않고 팀이 제대로 작동합니까?

지난 9 년 동안 여러 소규모 팀에서 근무했습니다. 각각은 짧은 회의, 개정 관리, 지속적인 통합 소프트웨어, 이슈 추적 등과 같은 명확한 모범 사례를 가지고있었습니다.

이 9 년 동안 개발 방법론에 대해 많이 들어 본 적이 없습니다. 예를 들어, "우리는 스크럼을하고있다"또는 "민첩하게하자", 또는 지나가는 참조 이상의 것이 없었습니다. 모든 팀은 많은 과정을 거치지 않고 잘 작동하는 것처럼 보였으며 우리는 자유롭게 흐르고 자연스럽게 잘 작동했습니다.

스크럼 / 애자일 / 등을 겪지 않고 오랜 시간 동안 다른 사람이 있습니까?

이것에 대한 유일한 노출은 이와 같은 사이트를 통해서입니다. 나는 Sprint Meetings-What to Talk에 대한 질문을 읽었습니다. 모든 대화는 방법론 유한 상태 기계를 따르는 사람들과 거의 같은 로봇을 묘사하는 것 같습니다. 정말 그렇게 과장된 것입니까? 인터넷에 글을 올리는 사람들이 비슷한 교과서 적 견해를 가진 "모범 사례"를 크게지지하는 사람인지, 사람들의 작업 방식을 실제로 반영하지 않는지 궁금합니다. 또는 일부 팀이 자연스럽게 프로세스를 구성하는 것을 경험했습니다.

또한 (나는 영국에 있는데, 관련성이있을 수 있습니다.) ... 내가 작업하고있는 팀에 방법론을 도입했다면 어리 석고 불필요하다고 거부했을뿐입니다. 의 위에. 동의하는 경향이 있습니다. 다음 과정은 다소 부자연 스럽습니다. 이것이 일반적인가요?

20 년 이상의 개발 경험이 있으며 공식적인 방법론을 사용한 적이 없습니다. 그것들을 필요로하지 않았으며 앞으로는 사용할 계획이 없습니다. 일부 사람들에게는 방법론이 좋을 수도 있지만 테스트를 거친 훌륭한 코드를 작성하는 숙련 된 프로그래머를 대신 할 수는 없습니다.

개인적으로, 나는 많은 사람들이 가장 뜨거운 새로운 방법론을 따르는 것에 대해 신경 쓰지 않고 코드 품질에 더 집중해야한다고 생각합니다.

솔직히 소규모 팀이 프로세스를 생각하지 않고 지난 몇 년간 큰 사건없이 잘 일했다면 아마도 어떤 형태의 민첩성을하고 있었을 것입니다. 모든 민첩한 프로세스는 반복, 스토리 보드 등에 대해 말할 것도 거의없는 "애자일 선언" http://agilemanifesto.org/ 를 준수한다는 것 입니다. 민첩의 첫 번째 임차인은 "개인과 프로세스와 툴에 대한 상호 작용 ". 함께 일하는 팀이 프로세스에 대해 열심히 생각할 필요는 없습니다.

스크럼 등과 같은 다양한 브랜드의 애자일은 서로 협력하는 데 익숙하지 않은 새로운 팀이있는 경우 매우 유용합니다. 이들은 응집력있는 팀을 구성하는 방법에 대한 프레임 워크를 설정하여 응집성있는 제품을 만듭니다.

당신이하고있는 일이 작동하는 경우 계속하십시오. 결과물에 지속적으로 늦거나, 초과 근무 시간을 잡아 당기거나, 무언가를 배치 한 후 주요 버그를 수정해야하는 경우 무언가 잘못되었습니다. 이때 문제를 해결하기 위해 일련의 작은 변경 작업을 수행해야합니다.

모든 것이 좋고 항상 괜찮다면 아무 문제가 없습니다. 따라서 새로운 (팀이 공식적인 방법이든 다른 방법이든 따를 것입니다) 방법론을 도입하는 것은 실제로 시간 낭비입니다.

그러나 방법론이 실제로 도움이되는 부분은 팀이 문제를 겪거나 외부 소스에서 문제가 발생했을 때입니다. 방법론은 단지 좋은 방법을 소개하는 것이 아니라이를 보호 하는 데 도움이 됩니다. 의식적으로 행할 때 좋은 관행을 유지하는 것이 훨씬 쉽습니다. 그렇지 않으면 신속하게 짜낼 수 있습니다.

공식적인 방법론이 반드시 필요한 것은 아니라고 생각합니다. 그러나 모든 팀은 효과적인 IMHO가되기 위해 업무에 영향을 줄 수있는 일종의 패턴이 필요합니다 (반복 될 필요는 없으며 이벤트 중심 일 수도 있음).

해결할 문제가 없다면 운이 좋다.

많은 팀 (특히 소규모 회사)이 정의 된 방법론없이 잘 작동하는 것을 보았습니다.

재미 있거나 인터넷에서 블로그 게시물을 읽었 기 때문에 방법론 (또는 기술)을 구현하는 것은 매우 위험합니다.

괜찮다면 아무 것도 바꾸지 마십시오. 가능한 경우 최적화를 시도하십시오.

그것들의 일부는 상당히 현명하고 일부는 미친 듯이 경계가 있습니다. 그들은 모두 상식 을 체계화 하고 재미있는 이름 을 부여한 다음 많은 책 / 세미나 등을 판매합니다.

이제 경영진 또는 실제로 팀에 상식이없고 유기적으로 자신의 현명한 방법론 (의식적이든 아니든 상관 없음)이 없다면 연구 할 가치가 있고 방법론의 일부를 수행 할 가치가 있습니다. 해당 팀의 경험과 관련이 있습니다 .

최신 <insert-buzzword-here>작업 관행 의 담요 부과는 해결하려는 것보다 더 많은 혼란을 야기 할 수 있습니다. 그러나 일반적으로 비 코딩 라인 관리자가 열성적으로 체크 할 수있는 많은 확인란 메트릭을 제공 할 수 있습니다.

어쩌면 민첩하거나 스크럼이라고 부르지 않았지만 프로세스가없고 사용하지 않았다는 의미는 아닙니다.

소프트웨어 개발 자체처럼. 이름으로 명시 적으로 생각하지 않아도 여러 디자인 패턴을 사용하게 될 것입니다.