복잡한 처리와 관련된 애플리케이션에 민첩성을 어떻게 적용 할 수 있습니까?


12

민첩성에 관한 대부분의 문헌은 사용자가 무대 뒤에서 무슨 일이 일어나고 있는지 거의 알고있는 CRUD 유형 비즈니스 응용 프로그램에 편향되어있는 것 같습니다. (작성되는 대부분의 코드가 아마도이 클래스에 속하기 때문에 좋습니다.)

이러한 유형의 응용 프로그램의 경우 사용자 사례 (요구 사항)와 개발 작업 간의 관계는 대부분 간단합니다. 사용자 사례를 몇 가지 작업으로 나누기 만하면됩니다.

그러나 대부분의 코드가 사용자가 직접 볼 수없는 복잡한 처리를 처리해야하는 다른 유형의 응용 프로그램이 있습니다. 예를 들면 다음과 같습니다.

  • 컴파일러
  • 자율 주행 자동차의 이미지 분석 시스템
  • 유체 흐름 시뮬레이션 시스템

여기서 작업과 사용자 스토리를 연관시키는 것이 실제로 어려울 수 있습니다. 이 문제를 극복 할 수있는 기술이 있습니까? 아니면 우리가 받아들이고 최대한 활용해야하는 것입니까?


6
downvoter는 아니지만 질문이 잘못된 전제에 기초하고 있기 때문이라고 가정합니다. IMO 복잡한 시스템 더 복잡 하다는 사실 때문에 애자일 스타일 개발에 더욱 적합합니다 . 시스템이 복잡할수록 새로운 요구 사항이있을 가능성이 높습니다. Agile SwDev는 새로운 요구 사항을보다 잘 처리하기 위해 개발되었습니다.
RubberDuck

4
@RubberDuck : "질문이 허위 전제에 기초하고 있다고 가정합니다."
Giorgio

사용이 논리를 이해하는지 여부는 민첩한 프로세스와는 전혀 관련이 없습니다. 사용자 스토리를 구현에 매핑하고 소요 시간을 추정하는 것은 팀의 책임입니다. 복잡하고 많은 작업이 필요한 경우 팀은 스토리를 더 작은 스토리로 나눌 수 있습니다. 논리 유형은 중요하지 않습니다.
Martin Maat

2
"애자일에 대한 대부분의 문헌은 CRUD 유형 비즈니스 응용 프로그램에 편향되어있는 것 같습니다."– Java에 대한 대부분의 문헌은 콘솔에 "Hello World"문자열을 인쇄하거나 다른 방법으로 n 번째 피보나치 수를 계산하는 편향되어 있습니다. 그렇다고 Java가 유일하게 좋은 것은 아닙니다. 그 이유는 두 경우 모두 동일합니다. 블로그 게시물이나 자습서에서 현실적인 예를 설명하기는 어렵습니다. [참고 : 이것은 허위 전제의 기초를 설명하려고하는 과장된 의견입니다.]
Jörg W Mittag

1
애자일에는 작업과 사용자 스토리가 필요하지 않습니다. 원하는 모든 형태의 사양을 사용할 수 있습니다. 요점은 유연성입니다.
Frank Hileman

답변:


9

이것은 내가 계획했던 것보다 길었던 것으로 판명되었지만 (설명으로 시작 했음) 추가 된 길이 / 세부 사항이 도움이 되었기를 바랍니다.

애자일은 CRUD 앱에만 국한되지 않습니다

민첩성에 관한 대부분의 문헌은 사용자가 무대 뒤에서 무슨 일이 일어나고 있는지 거의 알고있는 CRUD 유형 비즈니스 응용 프로그램에 편향되어있는 것 같습니다. (작성되는 대부분의 코드가 아마도이 클래스에 속하기 때문에 좋습니다.)

방법론이 그러한 종류의 시스템을 목표로하기 때문이 아니라,이 유형의 따르기 쉬운 예제를 만들기가 더 쉽기 때문이라고 생각합니다. 따르기 쉽지 않은 예제를 만들면 요점이 독자에게 민첩한 개념에 대해 가르치려고했을 때 예제를 이해하려고 시도 할 수 있습니다.

사용자 사례! = 요구 사항

이러한 유형의 응용 프로그램의 경우 사용자 사례 (요구 사항)와 개발 작업 간의 관계는 대부분 간단합니다. 사용자 사례를 몇 가지 작업으로 나누기 만하면됩니다.

사용자 스토리는 없는 요구 사항과 동일. 사실, 요구 사항이 얼마나 '높은 수준'인지에 따라 겹치는 부분이있을 수 있지만 일반적으로 동일하지는 않습니다. SVN 사용자가 Git으로 전환하려고 할 때와 비슷한 "요구 사항"의 동의어로 사용자 스토리를 생각하면 SVN의 관점에서 생각. (그런 다음 나쁜 시작 가정으로 인해 문제가 발생합니다.)

요구 사항과 사용자 스토리의 주요 차이점 인 IMHO는 요구 사항이 특정 시스템 구성 요소의 동작 방식을 자세하게 지정한다는 것입니다. 입력, 출력, 가정 / 사전 조건, 발생 가능한 예외 등을 포함 하는 사양 입니다 . 시스템의 기능 에 중점을 둡니다 .

OTOH의 사용자 사례는 시스템 구성 요소에 대한 자세한 동작 사양을 만들지 않고 최종 사용자의 예상 결과에 중점을 둡니다. 그들은 예상되는 사용자 경험 에 중점을 둡니다 .

내가했던 일은 팀에서 채택한 연습으로 사용자 스토리를 작업으로 나누는 것이 었습니다. 당신의 임무는 당신이 원하는 / 필요한만큼 구체적이거나 모호 할 수 있지만, 이야기를 완료된 상태로 만들기위한 실제 작업에 대한 진행 지표가 될 수 있습니다.

몇 년 전 사용자가 테스트 사례를 자체 할당해야했기 때문에 팀의 모든 직원이 중복 된 노력을 피하기 위해 작업중인 TC를 알 수있었습니다. UI는 내부 웹 애플리케이션이었습니다. 사용자는 버튼 만 보았지만 이야기는 기술적 구현 세부 사항 등을 포함하는 여러 작업으로 나뉩니다.

사용자 가시성

그러나 대부분의 코드가 사용자가 직접 볼 수없는 복잡한 처리를 처리해야하는 다른 유형의 응용 프로그램이 있습니다.

어떤 식 으로든 사용자에게 공개 할 수 있습니까?

GPS를 고려하십시오. 자신의 차례를 놓치면 실제 경로 재 계산 프로세스는 보이지 않지만 사용자는 유용한 피드백 (예 : "재 계산 ...")을받습니다.

컴파일러는 경고 나 오류를 표시하거나 GUI에 새로운 설정 / 옵션을 포함시켜 사용자가 새로운 것이 추가되었음을 알 수 있습니다. 컴파일러 사용자는 프로그래머라고 생각합니다. 새로운 표준에 대한 지원이 추가되지 않습니까?

새로운 표준을 지원하는 것은 기능 수준에있을 수 있으며 사용자 스토리로 세분화 해야 하지만, 경우에 따라 기능을 대신 사용해야 할 때 스토리를 사용하려고하지 않는지 확인 해야합니다. ?

자동차의 이미지 분석은 자동차 사고로 끝날 가능성이 줄어들 었다는 것을 사용자에게 알려주는 방식으로 표현 될 수 있습니다. 예를 들면 다음과 같습니다.

자율 주행 차의 승객으로서, 나는 더 안전하게 여행 할 수 있도록 인식 할 수없는 물체에 충돌 할 때 차량이 가능한 한 0에 가까워 질 가능성이 필요합니다.

미국은 보안, 안전 등 기능적 및 비 기능적 요구 사항의 조합을 사용하여 일반적으로 지정해야 할 사항을 높은 수준에서 포착합니다.

그러나 시스템에 대한 요구 사항이 더 많을 수 있습니다. 예 :

abc구성 요소의 기능 A은 이미지 비교 알고리즘에서 공차 임계 값을 줄여서 천천히 움직이는 물체를 더 잘 감지해야합니다.

나에게이 쉽게 될 제가 위에서 언급 한 사용자 스토리에 따라, 제목과 같은 : 기능의 감소 허용A.abc 한 다음 거기에 기타 관련 세부 사항을 포함한다.

유체 시뮬레이션 시스템의 경우 시스템이 수행하는 백그라운드 작업에 대한 피드백을 제공하는 진행률 표시 줄이있을 수도 있습니다. 스팸성이있는 것을 피하고 싶을 수도 있지만 항상 사용자에게 무언가를 알려주는 방법이 있습니다.

나는 당신이 언급 한 특정 도메인에 대해 더 잘 알고 더 현실적인 사례를 제시하는 것에 대해 충분히 알지 못하지만 여기서 테이크 아웃하는 경우 다른 방법을 사용하여 덜 눈에 띄는 것에 대한 사용자 피드백을 제공 할 수 있습니다 시스템이 수행 중일 수 있습니다. 즉, 보이지 않는 것을 조금 더 눈에 띄게 만드는 방법이있을 수 있습니다. (여러분의 노력 등으로 인해 시스템 성능이 얼마나 빨라지는지에 대한 릴리스 노트 세트를 작성하는 경우에도 마찬가지입니다.)

이야기와 과제의 관계

여기서 작업과 사용자 스토리를 연관시키는 것이 실제로 어려울 수 있습니다.

우리의 접근 방식은 사용자의 이야기에 초점을 유지하는 것이었다 것을 요청했다 이유 가했고, 될 어떤 것을 필요했던 사실 "완료"미국을 고려. 방법은 항상 미국의 탈락 및 개발자 (들)에 남아 있었다.

개발자는 미국에서 설명 된 문제를 그들이 수행 할 일련의 작업으로 분류 수 있습니다.

나는 이것을 백엔드 서버 측 프로그래밍을 한 사람이라고 말하고 있는데, 이는 최종 사용자에게 얻을 수있는 "보이지 않는"것일 것이다.

내가해야 할 일에 따라, 때때로 AJAX를 사용하여 간단한 "로드 중 ..."애니메이션 / gif를 표시하여 사용자가 잘못된 인상을받지 않고 다른 무언가가 완료 될 때까지 조금 기다려야한다는 것을 알았습니다. 때로는 이렇게 간단했습니다. 이에 대한 작업이 적절할 것입니다.

다른 패러다임, 실습 및 경험

이 문제를 극복 할 수있는 기술이 있습니까? 아니면 우리가 받아들이고 최대한 활용해야하는 것입니까?

패러다임의 변화를 받아들이고 실천하고 경험을 쌓는 것 외에는 말할 것도 없습니다. 나는 종종 사람들이 그 과정을 통해 지름길을 취하는 것을 보았습니다. 나는 특히 당신이 시작한다면 그것에 대해 충고 합니다. 더 많은 경험을 얻으면 약간의 유연성을 허용 할 수 있지만 자신을 약화시키지 마십시오.

당신이 이전에 한 말을하더라도, 당신은 여전히 ​​이야기가 마치 "이름이 바뀌었다"고 생각합니다. 그것은 잘못된 가정이라고 생각합니다. 이것이 민첩한 접근 방식과 민첩하지 않은 접근 방식의 근본적인 차이점에 관한 더 깊은 문제 의 증상 이라고 생각합니다 .

둘째, 민첩성이 폭포에 비해 패러다임 전환 이라는 점을 받아 들여야한다고 생각합니다. 즉, 프로세스의 목표는 비슷하지만 매우 다른 방식으로 진행됩니다. 도움이된다면 SVN과 Git을 생각하십시오.

요구 사항과 사용자 스토리의 개념적 차이에 대한 현재의 이해를 향상시키고 동일한 것이 아니라는 점을 인정하십시오.

스프린트에서 배우기-회고

내가 충분히 강조 할 수없는 것은 각 스프린트가 끝날 때마다 스크럼 마스터와 개발자 간의 회고 입니다. 그곳은 그들이 정직하고 투명한 방식으로 "잘됐다"거나 "잘 못 갔다"는 것들을 논의하는 곳이며 , 다음 스프린트가 "잘 못 갔다"는 점을 다루기 위해 어떤 가능한 변화가 시행 될 것인가 .

이를 통해 우리는 서로의 경험을 적응시키고 심지어 배울 수있게되었으며,이를 알기 전에 팀 속도의 일반적인 일관성으로 측정 한 결과 크게 향상되었습니다.


"User Stories! = Requirements": 두 사람이 동의어라는 의미는 아닙니다. 모든 요구 사항이 사용자 스토리는 아닙니다. 그러나 모든 사용자 스토리가 요구 사항이라고 생각합니다. 사용자 사례가 특정 수준의 세부 수준 인 계층 구조로 요구 사항을보고 있습니다. 동의하겠습니까?
Frank Puffer

@ FrankPuffer 사용자 계층이 요구 사항 계층에서 다른 수준 인 것처럼 보는 것은 기본적으로 다른 개념을 혼합하는 것입니다. 애자일 측면에서 계층 구조는 테마 >> 에픽 스 >> 기능 >> 사용자 스토리 >> 작업 과 비슷 합니다. 요구 사항은 일반적으로보다 일반적인 폭포 방식에서는 기능적 요구 사항과 비 기능적 요구 사항으로 나뉩니다. 그러나 실제 계층 구조는 다루지 않았습니다. 즉, 누군가가 요구 사항을 더 작은 "하위"요구 사항으로 재귀 적으로 분류 해야한다고해도 놀라지 않을 것 입니다. 어쨌든 다른 개념을 혼합하고 있습니다.
code_dredd

PTC Integrity와 같은 요구 사항 관리 시스템은 요구 사항을 계층 구조로 취급합니다. 요구 사항을 사양 문서에 매핑 할 때 이점이 될 수 있습니다.
Frank Puffer

@FrankPuffer 그래, 내가 놀라지 않을 것이라고 말했다. 즉, 나는 내 대답이 당신을 위해 무엇을 분명히했는지 궁금합니다. SVN vs Git 유추가 도움이 되었습니까? (소프트웨어 개발 환경에서 합리적으로 보였던 두 시스템에 모두 익숙하다고 가정합니다.)
code_dredd

좋아, 나는 "하지 않을 것"을 "할 것"이라고 잘못 읽었다. 그리고 네, 나는 당신의 대답이 매우 도움이되고 그것을 받아 들일 것입니다. 사용자 스토리를 요구 사항으로 고려하지 않는 아이디어에 익숙해지기 위해서는 시간이 필요할 것입니다.
Frank Puffer

4

이 경우 민첩한 원칙이 적용될 수 있습니다. 어떻게?

  • 컴파일러는 나중에 별도의 사용자 스토리에 새로운 언어 기능을 추가 할 수 있습니다
  • 이미지 분석 시스템은 다른 이미지 분류로 새로운 기능을 추가 할 수 있습니다
  • 유체 흐름 시뮬레이션 시스템은 시뮬레이션에서 다른 모델 측면을 고려할 수 있습니다

한 번의 입으로 전체 코끼리를 먹을 필요는 없습니다. 민첩한 다음 코끼리를 제공하기 전에 접시를 청소했음을 보여달라고 부탁합니다.


여전히 많은 소위 기본 기능이 필요한 하나 이상의 사용자 사례가 남아있을 것이라고 생각합니다. 그들은 종종 하나의 스프린트에 맞지 않을 것입니다. 이것을 어떻게 처리해야합니까?
Frank Puffer

1
고객이 테스트하거나 보거나 만질 수있는 실행 가능한 응용 프로그램으로 성공을 측정합니다. 그런 경우, 그러한 방식으로 진보 감을 생성하는 장난감을 그들에게주십시오. 예를 들어, 첫 스프린트에서 자율 주행 자동차를 출시 할 수는 없지만, 알고가 사람들을 정찰하는 방법에 대한 데모를 만들 수 있습니다. 나중에 어떻게 신호와 동물을 정찰 하는가. 나중에 거리, 크기 등을 측정하는 방법 ... 자율 주행 자동차는 원격 스프린트에서 멀리 떨어져 있는지, 누가 일어날 지 알 수 있습니다.
Laiv

2
@Laiv : 그것은 좋을 것이지만 그것이 작동하는지 확실하지 않습니다. 요컨대, 처음 몇 번의 스프린트 후에 소프트웨어는 고객이 관련시킬 수있는 어떤 것도 할 수 없습니다. 기술적 인 발전이 있지만 불가능하지는 않지만 고객에게 전달하는 것은 어렵습니다.
Frank Puffer

2
왜? 프로젝트 외부의 누군가가 Stone에 썼기 때문에? 애자일이 다른 요구가 아니라 내 요구에 적응할 것으로 기대합니다. 내가 4 주 안에 스케이트를 가르치고 5 일에 한 번만서도 실패한다고 가르치면 스케이트를 배우지 않는 것입니까? 아니면 그냥 조금 더 오래 걸리나요? 민첩한 선언문은 석재로 작성되지 않았으며 스크럼의 규칙은 경향이 있습니다.
Laiv

2
스프린트의 요점은 고객을 반복의 일부로 만드는 것입니다. 전달 된 코드를 사용하여 그들과 통신합니다. 계획과 약속이 아닙니다. 문제를 해결하는 데 집중해야합니다. 당신이 처음 배달하는 것을 돌로 만들 필요는 없습니다. 모든 스프린트를 지불 할 가치가 있음을 증명해야합니다.
candied_orange

1

나는 사용자 스토리를 엄격하게 준수하는 사람들은 백엔드 기술 변경이 사용자에게 영향을 미치는 방식을 가져 오는 매우 바보 같은 운동을 할 것입니다. 사용자와 데이터 분석 파이프 라인의 복잡한 변경 사항 또는 그와 비슷한 내용에 대해 이야기하고 있거나 "이 작업을 어떻게 구성 할 수 있습니까?!"

분명한 해결책은 더 실용적이라고 생각합니다. 작품이 본질적으로 매우 기술적이며 사용자에게 특히 눈에 띄는 영향을 미치지 않는다면 어떻게 작동하는지 설명하려고 잠을 잃지 마십시오. 사용자에게 혜택을 줄 수있는 명확하고 간단한 방법을 선택한 다음 개발자가 작업을 수행하는 데 필요한 세부 정보를 중심으로 스토리를 지향하십시오. PO가 절대적으로 필요할 때 이야기에 기술 정보가 없다고 주장 할 때 매우 실망 스럽습니다. 그것은 그 인공물 (이야기)이 실제로 무엇인지에 대한 매우 전적으로 견해가 아닙니다. 그들이 생각하는 것처럼, 대부분의 경우 엔지니어에게도 중요합니다.

이러한 기술 작업의 대부분에는 사용자 영향과 관련하여 효율성이 향상되어 향후 제공이 더 빨라지고 성능과 안정성이 향상되는지 여부에 관계없이 약간의 성과가 있습니다. 사람들이 '사용자 스토리'를 생각할 때 사람들이 실제로 생각하는 것은 아니지만 비즈니스가 기술 부채 또는 그 영향을받는 이유를 이해하려는 경우 일반적으로 이러한 설명이 가장 간단합니다.

tl; dr scrumnazi는 단순히 적응하기에 너무 많은 사각형이기 때문에 당신의 인생을 더 어렵게 만들지 않습니다. 적응하는 것은 결국 민첩성의 핵심 개념입니다. 스크럼이나 애자일에 대한 엄격한 준수는 대개 얼굴이나 실용주의와 실용성 (실제로 가장 잘 작동하는)에서 날아갑니다.


나는 융통성을 가지고 있지만 솔직히 사용자는 이야기가 만족되는 한 기술적 인 세부 사항에 관심이 없습니다. 좋은 요구 사항을 갖기 위해 "엄격하게 민첩"할 필요는 없습니다. 좋은 요구 사항이란, 요구 사항이 충족되었다는 것을 확실하게 입증하는 승인 테스트를 각각 수반하는 요구 사항을 의미합니다. "매우 어리석은 운동에 종사하는"사람들은 분명히 잘못하고 있지만, "엄격한 스크럼"이라는 개념을 따르고있는 것은 아닙니다.
Robert Harvey

@RobertHarvey 본인은 기술적 세부 사항이 사용자와 관련이 없음에 동의하지만, 제 요점은 사용자 스토리를 포함하는 아티팩트가 사물이 사용자에게 어떻게 작동하는지 의사 소통하는 것보다 더 넓은 목적을 가지고 있다는 것입니다. 순수한 사용자 스토리를 작성하는 경우 아키텍처, 확장 성, 성능 등과 관련된 요구 사항을 어떻게 적용합니까? 순수한 '사용자 스토리'접근 방식을 취하면 개발자는 품질이 낮은 코드를 작성하게됩니다. 또한 개발자와 qa 인 '사용자 스토리'를 읽는 사용자는 아닙니다. 기술적 인 정보이므로 관련 정보를 의도적으로 제외하는 것은 어리 석습니다.
evanmcdonnal

0

문제는 사용자 이야기에없는 의미를 부여하는 것입니다. 스크럼은 PBI 또는 제품 백 로그 항목이라는 용어를 사용합니다. PBI 종종 사용자 스토리 형식을 따릅니다. 예를 들어 "구독자가 구독 세부 정보를 볼 수 있어야합니다"와 같은 PBI를 가질 수 있지만 "구독자 세부 정보를 가져 오기 위해 저장 프로 시저 만들기"와 같은 PBI를 쉽게 가질 수 있습니다. ".

사용자 스토리는 도구 입니다. 그것들은 사용자의 입장에 서서 자신을 기반으로 기능 설명 및 요구 사항을 형성하는 데 도움이됩니다. 그러나 그림을 걸어야 할 때 렌치가 쓸모가없는 것처럼 사용자 스토리가 필요하지 않은 경우가 있습니다.

즉, 많은 팀이 실제로 "사용자"부분으로 빠르고 느슨하게 플레이합니다. "개발자로서 가입자 세부 정보를 얻기 위해 저장 프로 시저를 호출 할 수 있어야합니다"와 같은 "사용자 스토리"가있을 수 있습니다. 본질적으로 "개발자 스토리"입니다. 이것은 똑같이 유효한 옵션이지만 개인적으로 수행해야 할 사항을 설명하고 일련의 수락 기준을 제시 할 수 있다면 실제 사용자 스토리가 있는지 여부는 거의 중요하지 않습니다.


1
나는 매우 이상하고 드문 경우를 제외하고는 이것에 동의하지 않습니다. Scrum에서 HOW는 제품 소유자가 아닌 개발 팀의 범위입니다. 그러나 제품 소유자는 PBI를 책임 져야합니다. 따라서 "저장 프로 시저 생성"과 같은 PBI는 개발 팀에서 HOW를 선택할 수있는 권한을 빼앗습니다. 사용자 스토리 든 아니든 PBI는 PBI를 수행하는 데 비즈니스 가치가 무엇인지 설명해야합니다. 저장 프로 시저 작성은 비즈니스 가치가 아니라 구현 세부 사항에 관한 것입니다.
RibaldEddie

요점은 그것이 아니다. 그것은 단지 예일뿐입니다. "저장 프로 시저"를 "방법"과 같은 일반적인 것으로 변경할 수 있습니다. 요점은 반드시 사용자 스토리 일 필요는 없다는 것입니다.
크리스 프랫

예의 요점은 모범이되어야합니다. 귀하의 예가 "요점이 아닌 경우"예의 요점은 무엇입니까 ??
RibaldEddie

-3

이러한 유형의 응용 프로그램은 서로 다른 전문 지식이 존재하고 더 발전 할 응용 프로그램입니다. 팀원은 교육, 취미 프로젝트, 실무 경험이 다르기 때문에 기술이 다릅니다. 또한 누군가가 특정 코드를 개발하면 개발자는 코드를 가장 잘 아는 사람이 될 수 있습니다. 따라서 동일한 코드를 포함하는 추가 개발 작업을 동일한 개발자에게 제공하는 것이 좋습니다.

가장 인기있는 민첩한 프로세스 인 Scrum에는 각 작업에 난이도가 지정된 포커 계획이 있습니다. 난이도는 프로세스에 따라 해당 작업을 수행하는 사람에 의존하지 않습니다. 그런 다음 스프린트 동안 사람들은 동질적인 것으로 간주되어 각 사람이 모든 단일 작업을 선택하고 구현할 수 있어야합니다. 프로젝트와 같은 간단한 CRUD에서는이 가정이 적용됩니다. 그러나 매우 복잡하고 어려운 프로젝트에서는 그렇지 않습니다.

이런 종류의 프로젝트에는 민첩한 프로세스를 사용하지 않을 것입니다. 최선의 선택은 공식적인 프로세스를 피하고 좋은 프로젝트 관리를 사용하는 것입니다. 특정 기능을 구현하는 사람을 결정할 때는이 기능에 필요한 최고의 기술과 기존 코드에 대한 최고의 지식을 가진 사람을 고려하십시오. 이를위한 프로세스가 필요하지 않습니다. 모든 기능에 대해 좋은 디자인 문서를 작성하여 최신 상태로 유지하고 싶을 것입니다. 여기서 폭포 형 모델을 홍보하지는 않습니다. 프로젝트 시작시 디자인 문서가 모두 작성되지는 않습니다. 대신 새로운 기능이 필요할 때 새 디자인 문서를 작성합니다.


5
실제로 내 질문과 관련이 없지만 최고의 기술을 가진 사람이 기능을 구현하도록하는 것은 항상 위험 할 수 있습니다. 팀 내 지식 확산을 방해합니다. 유지 관리가 필요하고 전문가가 팀을 떠나거나 일시적으로 사용할 수없는 경우 문제가 발생합니다.
Frank Puffer

@FrankPuffer 귀하가 열거 한 일부 시스템 (예 :자가 운전 차량)의 경우 전문가가 팀을 떠나면 문제가됩니다. 기간. 코딩 이 중앙 집중화되어야 하는 경우는 아니지만 전문가가 적절한 시간 내에 짧은 시간 내에 교체 할 수 있도록 적절한 "지식의 확산"을 가정하는 것은 완전히 비합리적입니다. 이들은 문제를 연구하는 데 10 년 이상을 보냈을 것이며, 아마도 그 분야의 최상위에있을 것입니다. 다른 스킬 셋을 가진 이와 같은 여러 사람이 필요할 것입니다. 이러한 프로젝트는 본질적으로 위험합니다.
Derek Elkins
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.