민첩한 선언 원칙의 특정 요점을 이해할 수 없음

24

나는 민첩한 선언 원칙 을 읽고 있었다 . 한 가지 점을 제외하고는 모든 것이 명확하고 합리적으로 보입니다.

완료되지 않은 작업량을 최대화하는 기술인 단순성은 필수적입니다.

나는 이것을 이해하지 못한다. 이것이 이루어지지 않은 작업이 어떻게 든 과장되어야합니까? 그렇다면 실제로 냄새가 나지 않습니다.

agile management

— 최고
소스

2

다운 투표에 반대 +1-당신은 놀랍게도 흥미로운 질문이 있습니다.

1

또한 Wu Wei를 참조 하여 소프트웨어 개발에 일반적으로 어떻게 적용 할 수 있는지 상상 하십시오 . 그것은 당신의 질문에 표현 된 철학의 자연스러운 진보입니다.

30

괄호를 제거하십시오. 남아있는 것은 "단순함은 필수적이다"인데, 그것은 원칙 자체를 표현 자체에 적용하는 것이다.

단순함은 필수적입니다. 실제로 필요한 것을 증류하고 작업을 더 무겁고 덜 우아하게 만드는 것을 제거했기 때문에 복잡합니다.

나는 항상 파스칼의 테이크의 의미로 해석 한 간결 " 나는 짧은 편지를 쓴 것입니다,하지만 난 시간이 없었다. "당신은 (코드에서, 편지에서) unneded되는 것을 방지해야하고이입니다 활성 작업 , 그리고 쉬운 일. 그것은 스스로 일어나는 일이 아닙니다.

— 프란체스코
소스

35

아이디어는 필요하지 않은 작업, 즉 " 완료 되지 않은 작업량을 최대화"하는 것을 피하는 것 입니다.

따라서 전통적인 프로젝트에서 나중에 가능한 모든 요구를 충족시킬 수있는 훌륭한 추상 기본 시스템을 계획하고 구축한다면,이를 건너 뛰고 현재 요구 사항에 대해 가능한 가장 간단한 것을 구축하면 됩니다. 필요없는 물건을 만들지 마십시오.

YAGNI 는 관련 개념입니다.

— 요아킴 사우어
소스

5

우연히도, 이것은 아마도 내가 가장 동의하지 않는 민첩한 원칙 일 것 입니다. 극단적 인 추상적 예측은 우리를 다른 동물들과 분리시켜주는 것입니다. 가능할 때마다 그것을 사용해야한다고 말합니다. 물론 나는 그 원칙이 어떤 종류의 잔학 행위에 반응해야하는지 알고 있지만, 약간 의 예언은 아프지 않을 것입니다. 때로는 YAGNI이지만 일부 개발자는 너무 독단적이어서 몇 시간 앞선 생각조차 멈추지 않을 것입니다 (현재 구현하는 단순성이 4-8 시간이면 충분하지 않음을 인식하십시오).

— 최대

2

@Max, 향후 가능한 변경 사항을 예측할 필요가 있다고 생각합니다. 여기에 선견지명이 큰 도움이됩니다. 그리고 당신이 묘사하는 개발자는 모래에 숨어있는 타조와 더 비슷합니다.

— superM

7

@Max 고객이 어떤 비용을 지불하지 않으려는 생각 들이 있습니다 미래에 필요, 그들은 어떤 비용을 지불하고 싶지 이제 가능한 한 빨리 바로 필요 . 이 "이 나중에 너무 많은 시간을 절약 할 수"의 좋은 의도에 낭비 노력 $$$ 수십억 매월는 것을는 "나중에"실제로 제공하지,하지만 일이, 버그 늦은 때문에 모든 것을 "선견지명"의 복잡

15

@Max : YAGNI는 마지막 책임있는 순간 까지 의사 결정을 지연시키는 것 입니다. 무슨 얘기하는 것은 마지막에 결정 지연이다 가능한 참 나쁜 아이디어 ™입니다 순간. 문제는 지금보다 의사 결정에 근거한 정보가 적다는 것입니다. 최악의 경우 내일 같은 정보를 얻게됩니다. 그러나 대개는 그때까지 무언가를 배웠을 것입니다. 당신이 언급 한 경우, 당신은 당신 이 그것을 필요로 한다는 것을 알고 있으므로 YAGNI는 단순히 적용되지 않습니다. 이 경우에 적용하는 것은 실제로 어리석은 일입니다.

— Jörg W Mittag

2

@Max : 여기서 설명하는 것은 수행되지 않은 작업량을 최대화하는 것과 정반대입니다. 두 배나 많은 일을하고 있습니다.

— pdr

5

우리는 이것을 "골드 도금"이라고 불렀습니다. 망치에 대한 요구 사항은 못을 나무 조각에 부딪 칠 수 있다는 것입니다. 금도금 망치로 더 잘 작동하지 않습니다.

많은 경우 개발자는 새로운 멋진 프레임 워크를 사용하거나 시원하지는 않지만 기능을 추가 할 것을 제안합니다. 우리는이 아이디어를 적어 두 겠지만이 버전에서는 그렇게하지 않을 것입니다. 우리는 수행하지 않은 작업을 극대화 할 것입니다. 소프트웨어를 정시에 제공하는 것은 어렵 기 때문에 필요한 것보다 더 많은 코드를 제공하지 마십시오. 완료해야 할 경우 결국 계획에 들어가 적절한 시간에 완료됩니다.

— 스튜어트 우드워드
소스

4

이 아이디어는 Toyota Production System (TPS) 의 개념과 매우 유사 하여보다 일반적인 Lean Manufacturing 을 도입 한 다음 이러한 기술을 Lean Software Development에 적용했습니다 . TPS는 1950 년대 후반 제조에 뿌리를 둔 민첩한 움직임을 크게 앞섭니다.

수행되지 않은 작업량을 최대화하는 개념은 폐기물을 제거하는 것과 유사합니다. 제조 환경에서 폐기물에는 제품의 과잉 생산, 자원 대기, 불필요한 사람이나 제품의 이동, 너무 많은 재고 및 결함있는 제품이 포함됩니다. 린 소프트웨어 개발 (Lean Software Development)에서 이러한 낭비는 불필요한 기능, 개발 프로세스 지연, 소프트웨어 생산 속도를 늦추는 불확실한 요구 사항, 테스트 부족 및 통신 지연으로 변환되었습니다.

두 개념의 전반적인 아이디어는 동일합니다. 가치를 추가하지 않는 것은 낭비이며 최소화해야합니다. 궁극적 인 목표는 품질을 높이면서 생산 시간과 비용을 줄이는 것입니다.

— 토마스 오웬스
소스