신과 선포. 민첩한 관리.

그해는 2001 년이었습니다. 아직 젊지 만 성숙한 소프트웨어 개발 산업에 새로운 방법론이 등장했습니다. Agile Manifesto 와 함께 제공되었습니다. 새로운 방식 인 민첩한 관리 방식 은 개발자가 너무 멀리 떨어져 있던 이전의 엄격하고 좁고 깊은 계층 구조를 깨뜨 렸습니다. 소프트웨어 사용자로부터.

일부 사람들에게 빠르게 받아 들여지고 다른 사람들은 완전히 무시한 애자일 경영진은 지난 10 년 반 동안 인기를 얻어 오늘날 가장 트렌디 한 현상 중 하나가되었으며 의 회사는 원칙을 적용하고 적용했다고 주장합니다. 사실은 사실이지만 거의 항상 수정되고 때로는 부패한 방식입니다.

소프트웨어 개발 분야에서 우리 대부분은 다른 팀과 프로젝트에 속해 있습니다. 일부는 개발자로, 팀은 & amp; 다른 사람의 관리자. 우리는 킥오프 회의에서 고객과 대응하고, 수락 기준 및 와이어 프레임을 디코딩하고, MVP를 정의하고, 요구 사항의 변경 사항을 수락하고, 스프린트 중간에 범위를 수정했습니다. 우리는 실수를했고 어려운 방법을 배웠습니다. 다시는 저 지르지 말아야 할 실수. 그러나 때때로, 우리는 우리 팀에서 또는 우리가 협력 할 고객 또는 회의 팀 등을 방문 할 때 다시 발생하는 것을 볼 수 있습니다. 이것이 오늘 제 초점이 될 것입니다. 소프트웨어 개발자 팀의 관리자들 사이에서 가장 많이 보는 문제입니다.

애자일 관리의 일반적인 오류

팀에 추가 리소스를 추가하여 촉박 한 기한 충족

달리는 스프린트에 대한 예상치를 확인하고 현재 팀이 일정보다 16 시간 늦다는 것을 확인했습니다. 전혀 문제가없는 것 같습니다. 당신은 그의 프로젝트를 막 마친 개발자가 있고, 그는 이틀 동안 고군분투하는 팀에 합류 할 것이고, 당신들은 다시 궤도에 올 것입니다.

이렇게하면 팀이 마감일을 지키지 못할 수 있습니다. 왜? 여기서 실수는 개발자가 쉽고 자동화 가능한 작업을 수행한다고 생각하는 것입니다. 글쎄요. 그는 프로젝트에 사용 된 기술에 익숙하더라도 프로젝트의 내용, 이미 수행 된 작업, 모든 문서가 어디에 있는지, 아직 검토중인 와이어 프레임 및 매우 긴 목록에 대한 소개가 필요합니다. 다른 것들. 이 개발자의 생산성이 (적어도 처음에는) 낮을 것이라는 사실 외에도 나머지 팀의 도움을 받아 위에서 설명한 모든 내용을 배울 필요가 있습니다. 일반적으로 특정 사람에게 할당되는 작업입니다. 그 사람은 산만 해져 팀의 새로운 구성원을 돕고 훈련하는 데 몇 시간을 소비해야하므로 생산성도 떨어집니다.

파킨슨 법칙

처음에 Parkinson의 법칙은 다른 의미를 가졌습니다. 오늘은 작업이 완료 될 수있는 시간을 채우기 위해 확장된다고 말합니다. 특정 프로젝트에서 성능 문제가 있다고 가정 해 보겠습니다. 그래서 우리는 아마도 최고의 개발자 중 한 명에게 문제가 무엇인지 조사하고 병목 현상을 해결하도록 배정합니다. 이를 위해 일주일 동안 시간을 ​​할애하기로 결정했습니다.

Parkinson의 법칙이 개발자에게 항상 존재하는 것은 아닙니다. 때로는 더 강하고 때로는 더 약합니다 그러나 작업에서 시간의 자유, 특히 종료 지점이 명확하지 않은 경우 작업이 확장되어 가능한 모든 시간을 차지하게됩니다. 때로는 프로젝트에 불필요한 복잡성을 추가하는 과도한 엔지니어링으로 인해 솔루션이 어려움을 겪는 최악의 경우도 있습니다. 이러한 상황을 방지하려면 작업에 엄격한 목표와 허용 기준이 있어야하며 그렇지 않으면 지금까지 달성 된 결과를 확인하기 위해 자주 폴링해야합니다.

여러 프로젝트 및 분산 된 팀

분산 된 팀이 애자일을 적용하거나 애자일 관리를 따르고, 작업을 균등하게 분배하고, 시간과 문화적 차이를 이해하는 등의 작업을 수행하는 방법에 대한 수많은 기사를 찾을 수 있지만 모든 프로젝트가 좋은 것은 아닙니다. 그런 일을하기 위해. 특히 각 개발자가 동시에 다른 팀의 일부를 구성 할 때. 각 개발자를 ‘모든 지형’개발자로 만들려고 시도하면서 동시에 여러 프로젝트에서 작업하게됩니다. 인스턴스 당, 월요일 & amp; 프로젝트 A에서 화요일, 프로젝트 B에서 수요일부터 금요일까지

개발자의 초점에 대해 들어 보셨을 것입니다. 개발자가 가장 생산성이 높고 한 번 잃어 버리면 다시 찾는 데 시간이 걸린다는 말입니다. 글쎄, 프로젝트 사이를 전환하고 부재 중 놓친 것을 확인할 때도 똑같은 일이 발생합니다. Dailies, Jira 또는 Trello와 같은 일부 도구는이 효과를 완화하는 데 도움이되지만 여전히 생산성을 저하시킵니다.

이 주제에 대해 동의하지 않는 것은 쉽지만 기본적으로 저는 ‘공동 위치’와 ‘공동 시간’모두에 대해 Agile Manifesto의 6 번째 원칙을 옹호합니다.

“개발팀과 정보를 전달하는 가장 효율적이고 효과적인 방법은 직접 대면하는 것입니다.”

시간 압박으로 생산성 향상

동료와 전문 동료 사이에서 똑같은 어두운 경험을했다는 사실을 발견하는 것이 얼마나 흔한 일인지 놀랍습니다. 종종 스타트 업이나 소규모 회사에서 ‘자신과 제품을 믿게 만든’매우 재능있는 관리자가있는 경우가 많았는데, 이는 결국 무수한 추가 시간, 엄청난 스트레스, 맞추기 불가능한 마감 시간으로 끝났습니다. 개발자가 이러한 조건에서 작업하는 것을 수락하면 제공되는 기능과 시간의 비율이 믿을 수 없을 정도로 높기 때문에 관리자가 팀의 생산성이 매우 높다고 가정 할 수 있습니다.

실제로 수행 한 작업의 품질과 추가 (및 무급) 시간을 고려하지 않는 한 팀의 생산성이 높은 것으로 간주 될 수 있습니다. 이러한 조건은 필연적으로 두 가지 결과로 이어집니다.

첫 번째 는 코드의 품질입니다. 이는 더 많은 버그가 통과하고 (프로덕션의 버그가 처음부터 제대로 처리하는 데 필요한 시간보다 회사에 수백 배 더 비싸다는 것을 설명 할 필요가 없음) 테스트 커버리지가 실패하고 기능이 부분적으로 구현된다는 것을 의미합니다. .

시간의 압박을 받으면 개발자는 더 이상 작업하지 않고 더 빠르게 작업합니다. 기본적으로 품질보다 양입니다.

두 번째 , 특정 시점에서 개발자가 종료됩니다. 일이 변하지 않는다는 것을 깨닫고 회사에 대한 그의 워커 홀릭 태도와 헌신이 그에게 좋지 않다는 사실을 깨닫게되면 그는 분명히 자신의 운을 시험 할 다른 곳을 찾을 것입니다. 일반적으로 떠난 사람이 가장 많은 압력을 가한 사람입니다. 그가 다른 선택권이 있다는 것을 알고 있기 때문에 실제로 떠날 수있는 사람. 그리고 그거 알아? 당신이 놓아 줄 수없는 개발자입니다.

이 문서를 마치기 위해 개발자의 코드와 동기 사이의 연관성을 지적하고 싶습니다. 일반적으로 소프트웨어 개발은 ​​’비용을 지불하는’것이 아니라 누군가의 열정입니다. 개발자에게 양질의 코드를 작성할 기회가 있다는 것은 엄청난 동기 부여를 의미합니다. 그 기회를 버리면 동기가 사라집니다.

애자일 관리에서 관리자의 초점은 생산성을 유지하는 데 있으며 품질이 크게 향상되는 경우는 거의 없습니다. 그러나 품질에 초점을 맞추면 생산성이 급증하는 경향이 있습니다.

월간 뉴스 레터 를 구독하여 소프트웨어 세계의 최신 뉴스를 받아보세요!

원래는 https://apiumhub.com/tech-blog-barcelona/ 에 게시되었습니다.