애자일은 개발자가 실제로 작업하는 데 더 많은 시간을 보내도록 강요합니까?

일반적인 애자일 관행을 살펴보면 (의도적이든 의도적이지 않든) 개발자가 블로그 / 기사 읽기, 채팅, 커피 브레이크 및 평범한 미루지 말고 실제로 작업하는 데 더 많은 시간을 소비하게 만드는 것 같습니다.

특히:

1) 페어 프로그래밍-가장 큰 노동력. 두 사람이 함께 앉아있을 때 모든 지연을하는 것이 불편하기 때문에.

2) 짧은 이야기-예를 들어 한 달에 수행해야하는 거대한 작업 덩어리가있는 경우 처음 3 주 동안 느슨해져 마지막 한 달 동안 OMG DEADLINE 모드로 전환하는 것이 일반적입니다.

그리고 작은 덩어리 (하루 이내에 완료되어야 함)와는 정반대입니다. 시간이 빡빡하고 기동 할 공간이 없으며 곧 작업에 대해 책임을 져야하므로 시작합니다. 즉시 작업.

3) 팀 커뮤니케이션 및 응집력-느리고 먼 거리에서 조용한 환경에서 성능이 저하되면 기분이 좋아질 수 있지만 스크럼 회의에서 하루가 끝나면 모든 사람들이 성취 한 것을 자랑스럽게 생각하며 실제로 느끼게 할 말이 없습니다. 부끄러워.

4) 테스트 및 피드백-마감 시간이 갑자기 발생할 때까지 작업을 "99 % 준비"(실제 20 % 인 경우)로 유지하지 못하게합니다.

애자일에서는 "기존의"방법론보다 더 많은 일을하고 있다고 생각하십니까? 이 압력은보다 편안한 환경과 실제로 올바른 일을 신속하게 수행한다는 느낌으로 보상됩니까?

민첩한 방법의 기본 아이디어는 긍정적 인 의미에서 생산성을 높이는 것입니다. 마감일을 지키면 매일 한 시간 씩 서핑을해도 아무도 신경 쓰지 않습니다. 매일 30 분 동안 서핑을하지만 마감일을 놓치면 모두가 화를냅니다. 해결책 : 마감일을보다 쉽게 ​​충족시킬 수 있습니다.

알다시피, 페어 프로그래밍은 기술 / 지식 확산 개선, 코드 개선, 버그 감소, 균일 한 디자인 등과 같은 다른 모든 장점 중에서도 집중력을 유지합니다.

나는 징계가 항상 힘들다는 것을 알았습니다. 내가 누군가와 짝을 지으면, 우리 중 한 명이 오늘 어떤 일을하고 싶어하고 다른 한 사람을 끌어 당길 가능성이 있습니다. 따라서 "한 달 동안의 작업"은 종종 "일주일 동안 함께 작업"으로 바뀌며 결국 엄청난 양의 작업이 해결되고 하루를 보내거나 복구 (리팩토링, 코드에서 TODO 수정, 두 번의 테스트, 명확한 양심을 가지고 서핑)하고 다음 달의 일을 잡습니다.

결과 : 나는 훨씬 더 편합니다. (상시적인 감독에도 불구하고) 팀 응집력이 훨씬 뛰어납니다. 작업이 더 빨리 완료됩니다. 사람들은 몇 시간 또는 며칠 동안 사소한 문제를 해결하지 못합니다. 문제를 훨씬 빨리 발견하십시오).

"실제로 부끄러워 할 수 있습니다"라고 말할 때 좋은 일이 아닙니까? 그것은 당신이 잘못했다고 느낀다는 의미입니다. 아무것도하지 않아도 돈을받지 않습니다. 아무것도하지 않으면 무력감, 불행 함, 합당하지 않음, 비참함을 느끼게됩니다. 부끄러워하는 대신, 물러서서 "오늘 왜 아무것도 달성하지 못했습니까?" 도움이 필요하십니까? 이해하지 못하는 것이 있습니까? 현재 작업이 너무 어렵습니까? 당신은 그것을 좋아하지 않습니까? 다른 사람과 작업을 전환 할 수 있습니다. 다른 누군가가 도와 줄 수 있습니다. 민첩한 수단 : 현의 꼭두각시처럼 미세 관리되는 대신 책임을 져야합니다. 도구가 필요하십니까? 상사에게 가서 물어보세요. 논쟁하는 법을 배우십시오. 필요할 때 일어 서서 외치는 법을 배우십시오.

테스트와 관련하여 코드가 갑자기 "좋은"것에서 "완벽한"것으로 넘어갈 때 좋은 지점이 있습니다. 그것은 당신이 기능 X를 구현할 필요가 있고 그것이 악몽이 될 것이라고 생각하고 갑자기 코드가 거의 있다는 것을 깨닫는 순간입니다. 여기저기서 작은 리팩토링. 새로운 수업과 완료. 4주의 일이 갑자기 하루가되었습니다. 승리! 승리!

동의한다.

페어 프로그래밍

매우 강렬하고 철저한 작업 방식이며 다른 개발자의지도를 받아야하는 개발자가없는 한 (예 : 새로운 출근 자) 적용하지 않습니다.

짧은 이야기

팀 커뮤니케이션 및 응집력

테스트 및 피드백

예 민첩하고 구체적으로 Scrum 은 엄청난 생산성 향상 도구입니다. 올바르게 적용하면 전환율은 최대 20 %가 될 수 있습니다 (5 명의 개발자 1 명은 회사를 떠남).

그 이유는 간단합니다. 스크럼 은 it provides the whole company with much more visibility on what's going on(물론 관리를 포함하여) 더 많은 생산성을 제공하지 않습니다 .

• 개발자가 최소한으로 만 할 수는 없습니다. 베어 미니멀은 이제 팀 평균입니다!

• 경영진이 제대로 협업하지 못하도록합니다.

이것이 내가 비슷한 질문에 대한 다른 답변에서 Agile이 모든 조직 (및 모든 사람)을위한 것은 아니라고 말한 이유 입니다.

예를 들어 공공 부문은 애자일에 적합하지 않습니다.

민첩성 도구로 사용 되는가? 물론, 나는 여러 번 보았다. 그것은 단지 상황을 훨씬 더 악화시킵니다.

애자일에서는 "기존의"방법론보다 더 많은 일을하고 있다고 생각하십니까? 이 압력은보다 편안한 환경과 실제로 올바른 일을 신속하게 수행한다는 느낌으로 보상됩니까?

그것은 더 많은 일을하게하지만 무엇보다도 올바른 일을하게 만듭니다. 주어진 순간에 나는 무엇을해야하는지 안다 .

그것은 일종의 긍정적 인 압력입니다. 그것은 "외부 일정이 이미 지났고, 더 많은 일을하고, 코드 초과 근무입니다!" 압력의 종류.

사실, 나는 기존의 방법을 사용할 때 훨씬 더 생산적입니다. 기존의 방법을 사용하면 몇 개월 이내에 세부 요구 사항 분석, 타당성 조사, 기능 사양, 기술 사양 및 수많은 회의 프로토콜 등을 만들 수 있습니다. 영향 분석이 완료되면 몇 줄의 코드를 만들 수도 있습니다!

애자일, 내가 만드는 것은 몇 가지 결과물이다.

우리 회사에서는

페어 프로그래밍-무언가가 복잡하고 광범위한 분석이 필요한 경우에도 우수한 인재 두 명을 모아 빠른 시간 안에 작업을 수행 할 수 있습니다. 여기서 작업의 복잡성은 페어 프로그래밍의 필요성을 결정합니다.

짧은 이야기-그런 다음 개발자로서 3 주간 (매일 약 5-6 시간) 휴식을 취하고 마지막 순간 (하루에 약 12 ​​~ 14 시간)을 서두르고 있습니다. 하루에 약 8 시간 일하고 일정을 안정적으로 유지하면 항상 차갑게 보입니다.

팀 커뮤니케이션 및 응집력-스크럼 회의에서는 작업 상태뿐만 아니라 장애물도 공유합니다. 누군가가 실제로 도움을 필요로 할 때 다른 회원들이 실제로 그를 도울 아이디어를 생각해 낼 것입니다. 그러나 확실히 당신은 이것을 위해 훌륭한 팀이 필요하며 우리는 :)

테스트 및 피드백-확실히 개발자로서 나는 마침내 버그로 인해 부담을 느끼지 않기를 원합니다. 버그를 발견 한 다음 순간에는 버그를 수정하는 것이 좋았습니다. 다음에 완료하고 필요에 따라 마감 시간을 조정하십시오.

따라서 개발자로서 나는 취한 종류의 작업에 매우 만족하며 마감 시간의 실제 압력을 느끼지 못했다고 말할 수 있습니다.

애자일에서는 "기존의"방법론보다 더 많은 일을하고 있다고 생각하십니까?

• 애자일 환경에서 생산성이 더 높다고 생각한다면 그 기능에 따라 다릅니다 .
   
  _{나는 보통 페라리 (기존)와 랜드 로버 (스크럼)의 관점에서 생각합니다. 고속도로에서 운전할 때 페라리는 랜드 로버에서 지옥을 이깁니다.
   
  스포츠카가 아닌 지프가 필요할 때 오프로드입니다. 요구 사항이 불규칙하거나 팀 작업 및 관리 경험이 좋지 않은 경우 스크럼을 선택해야합니다. 페라리가 오프로드에 갇힐 것입니다.}

"더 많은 일"에 관해서는 , 프로그래머의 IQ와 다양한 형태의 관리 치매 에 적응하는 능력을 과소 평가할 가능성이 높다고 생각 합니다.

지금까지 두 회사에서 서로 다른 프로젝트를 수행하는 두 개의 Scrum 팀에 참여했습니다. 두 팀 모두 폭포 / 반복과 비교할 때 습관이 바뀌지 않았습니다.

나는 이것이 매우 특별하고 무적이지만 솔직히 말해서, 팀의 다른 모든 사람들의 습관도 무적임을 보았다는 것을 자랑스럽게 생각합니다.

애자일 개발의 다양한 기술이 바쁜 작업과 불필요한 작업을 제거하기 때문에 애자일은 프로그래머가보다 유용한 작업을 수행하도록합니다.

두 사람이 함께 앉아있을 때 모든 지연을하는 것은 불편합니다.

동의하지 않습니다. 나는 흡연자 그룹과 함께 일했고 그들은 모두가 일을하고 있었기 때문에 오랫동안 휴식을 취했습니다.

처음 3 주 동안 느슨해 짐

이것은 방법론에 관계없이 관리가 제대로되지 않음을 나타냅니다. 한 달에 큰 덩어리가 생겨도 첫 주가 끝날 때 무언가를 볼 것으로 예상됩니다.

당신은 실제로 부끄러워한다고 말할 것도 없습니다.

3 주 동안 기꺼이 뛸 생각이라면 헛소리가 떠오를 것입니다.

4) 테스트 및 피드백-마감 시간이 갑자기 발생할 때까지 작업을 "99 % 준비"(실제 20 % 인 경우)로 유지하지 못하게합니다.

폭포 프로젝트는 테스트 및 일일 빌드를 가질 수 있습니다.

개인적으로, 나는 코드를 작성하는 것을 싫어하고 한 달 동안 아무것도하지 않았습니다. 코드 검토 또는 사용자 사인 오프 여부에 관계없이 코드에 더 짧은 피드백 루프를 선호합니다. 다른 사람들이 내 작업을 승인하게하는 것은 보람있는 일입니다. 마치 고양이가 자신의 일을하고 있다는 것을 알려주기 위해 문앞에 마우스를 떨어 뜨리는 것과 같습니다.

애자일은 개발자들에게 더 많은 일 을하도록 강요하지 않고 더 효율적 으로 일하도록 합니다

'개발자에게 더 많은 일을하도록 강요한다'라는 질문을하는 것은 약간 부정적인 것이지만, 실제로 더 많은 일을하고 덜 미루면 더 긍정적인가?

좋은 지적입니다. 올해는 민첩한 느낌이 들었지만이 사실은 인정하지 않은 큰 미기록의 이점입니다.

민첩성이 개발자의 생산성 향상으로 이어질 수 있다는 데 동의합니다. 가시성, 책임 성 및 미루는 경향에 대한 당신의 요점은 모두 사실입니다.

그러나 애자일은 긍정적 인 이유로 당근과 스틱을 개발하는 개발자로 이끌 수 있습니다. 민첩하게 수행하면 개발자는 사용자와의 상호 작용을 강화하고, 관료주의를 줄이고, 업무를보다 효과적으로 통제 할 수 있으며, 이로 인해 팀에서 더 많은 것을 얻을 수 있습니다.

더 많은 작업 이 의미 적으로 정확하거나 애자일과 관련이없는 경우 목표는보다 생산적 입니다. 그것은 구체적으로 잘못된 일에 덜 집중하는 데 초점을 맞추고 올바른 일 에 대한 정상적인 일 에 더 집중하는 것입니다. 이는 작업을 의미하지 않는다 더 단지 더 생산적 .

부작용은 슬랙 커와 비효율적이거나 유능한 사람들을 매우 빠르게 노출 시킨다는 것입니다. 당신이 얻는 것과 더 비슷한 소리.

방법론은 개발자가 작동 하지 않는지 여부와 관련이 없습니다 . 프로세스는 워터 폴에서도 관리 검토 및 코드 검토를 통해 대부분의 애자일 방법론만큼 투명하지 않고 아무것도하지 않을 수 있습니다.

"총은 사람을 죽이지 않는다. 사람들은 사람을 죽인다!" 애자일도 마찬가지입니다. 애자일은 사람들이 더 많은 일을하도록하지 않고, 관리자는 사람들이 더 많은 일을하도록합니다.