신속한 프로토 타이핑은 민첩한 방법론에 어떻게 적합합니까?

민첩한 프로세스의 사용을 지시하는 대기업에서 일합니다. 예를 들어, 프로젝트에는 민첩한 개발 관리를 목표로하는 클라우드 기반 서비스를 사용합니다.

내가 일하는 특정 엔지니어링 그룹은 전통적으로 소프트웨어를 개발하지 않았으며 (대신 훨씬 더 조망적인 관점에서 프로젝트를 추진하는 데 도움이 됨) 변화하고 있습니다. 데이터 중심의 다가오는 예정 / 예정 소프트웨어 프로젝트가 다양합니다. 예를 들어, 데이터 모니터링, 수집, 집계 및 일부보고를 수행 할 것입니다. 다른 작업에는 특수 하드웨어 및 다양한 유형의 클라이언트 / 서버 (멀티 티어) 아키텍처를 사용한 자동화가 포함됩니다. 여러 사람을 고용하고 앞으로 나아갈 많은 계획을 세우는 과정을 지원해야합니다.

내 질문은 빠른 프로토 타이핑 (throwaway code)을하는 것이 민첩한 철학에 맞는지 여부입니다. 예를 들어, 나는 파이썬과 그 광범위한 패키지를 좋아합니다. 파이썬 기반 워크 플로로 많은 아이디어를 매우 빠르게 구현할 수있는 가능성을 봅니다. 그러나 파이썬이 "엔터프라이즈 품질"이 아니라는 인식이 많이있을 것이라고 생각하며,이 작업의 대부분은 Java 또는 C ++로 다시 작성해야합니다.

그러나 파이썬 프로토 타입을 만들면 실제 결과를 신속하게 제공 할 수있게됩니다.

파이썬에서 빠른 프로토 타입을 엔터프라이즈 환경의 탄탄한 민첩한 워크 플로우에 통합 할 수 있었습니까?

RAD 에서 의도 한 "프로토 타이핑" 의 개념은 민첩한 개발에 다소 이질적입니다. 그렇다고해서 할 수 없다는 뜻은 아닙니다.

탐색해야 할 다른 경우가 있습니다.

1. 프로토 타입은 제품의 모양에 대한 아이디어를 제공하기 위해 제작 된 모형 또는 데모 인 "빈 쉘"입니까? 하나 이상의 이야기로 확실히 할 수 있지만 실제 피드백으로 제품을 만드는 것이 아니라 자신의 상상력으로 무언가를 만드는 것입니다. 사람들은 제품을 평가하는 것처럼 데모를 평가하지 않습니다. 예를 들어 상단 막대 프로토 타입 과 실제 상단 막대 구현에 대한 피드백을 참조하십시오 .

2. 문제 공간을 더 잘 이해하기 위해 프로토 타입을 제작해야합니까? 그런 다음 spike 로 다루어야 하고 결과 만 유지됩니다 (소스 코드는 일시적입니다).

3. 프로토 타입은 버전 0.x입니까? mininimum 가능한 제품 ? 그런 다음 원하는 민첩한 프로세스를 사용하십시오. 다른 언어로 다시 작성해야 할 경우 다른 제품을 취급하면 더 나을 것입니다. 때때로 이것은 스펙 작성을 바로가는 방법으로 취급되기도합니다 ( "프로토 타입과 동일해야합니다!"). 그것은 제품을 문서화하는 매우 나쁜 방법이지만, 아마도 별도의 질문과 답변으로 더 잘 설명 될 것입니다 :-)

아닌가 신속한 프로토 타입 (즉, 반복 및 증분 개발) 종류의 애자의 전체 포인트는?

조직에서 "인식은 현실입니다"라는 문제가있는 것 같습니다. 애자일 (Agile)이 "모든 계획을 버리는 것"을 의미하는 것이 아니라 테스트 주도 개발 (Test-Driven Development)이 "모든 아키텍처를 버리는 것"을 의미한다는 것을 모든 사람들에게 상기시킬 수 있습니다.

그리고 파이썬은 장난감 언어가 아닙니다. NASA와 계약자는 Python을 사용 하며, 그것이 충분하다면 나에게 충분합니다.

익스트림 프로그래밍 에는 스파이크 (Spike) 라는 꽤 체계적인 방법이 있습니다. 이것은 그것이 버리기 코드임을 의미합니다. 특별한 것은 없습니다. 예상되는 결과가 폐기 코드에 대한 지식인 스프린트입니다.

위 링크에는 우수 사례, 스파이크의 함정에 대한 충분한 정보가 있습니다.

특정 사용 사례가 좋은 예인 것 같습니다. 인터페이스를 디자인하고, 유틸리티를 검증하고, 일부 사용자에게 보여주는 것이 도움이 될 수 있습니다.

코드를 버리고 프로덕션 환경에 두지 말고 (모든 사람에게 완벽하게 명확하게 함) 민첩하거나 중요하지 않은 것은 중요하지 않습니다. 스프린트, 번 다운 (burn-down), 테스트, 페어 프로그래밍 또는 사용하려는 다른 모든 프로토 타입의 경우 민첩한 방법이 선택 사항입니다.

제품 소유자 및 기타 의사 결정자가 프로젝트를 개념화하는 데 도움을주기 위해 Python으로 기능 모델을 주로 구축하려는 경우 엔터프라이즈 준비가되어 있지 않아도됩니다. 그러나 개념 증명을 작성하거나 특정 성능 레벨을 처리 할 수 ​​있는지 확인하려는 경우 프로덕션 언어를 고수해야합니다. 그렇다고 파이썬에서 시도 할 수 없다는 것을 의미하지는 않습니다.

어쨌든, 당신은 코드를 버릴 것이지만, 소유자가 원하는 것에 대한 더 나은 이해와 함께이 작업을 수행 할 수 있다는 지식을 가지고 있습니다. 이제 원하는 방법을 사용할 수 있습니다.

프로토 타입은 학습과 애자일 정신에 매우 중요하다고 덧붙였습니다. 프로토 타입을 통해 특히 빠른 피드백주기 내에서 학습 할 수 있다면 계속 진행하십시오. 학습을 극대화하고 팀과 학습을 공유하는 것이 중요합니다.

학습 측면에서 프로토 타이핑을 통해 더 빨리 학습 할 수 있습니다. 이렇게하면 사람들이 해결하려는 문제에 대해 신경을 쓰는지 여부를 확인할 수 있으며, 마음에 드는 솔루션이 원하는 결과에 해당하는 경우 전체 솔루션을 구축하는 데 많은 시간을 낭비하지 않고도 결국 고통스럽고 충분한 문제를 해결하지 않거나 올바른 방법으로 해결하지 마십시오.

애자일의 진정한 정신은 상호 작용과 의사 소통에 관한 것입니다. 프로토 타입이 의사 소통을 돕는 도구로 잘 작동한다고해도 애자일 세계에서는 프로토 타입을 사용하는 데 아무런 문제가 없습니다. 우리 팀 (우리는 5 년 이상 애자일을 연습 해 왔습니다)에서 때때로 사용했습니다. 그리고 내가 볼 수있는 몇 가지 이점이 있습니다

1) 커뮤니케이션 지원

2) 사용자를 솔루션 인터뷰에 참여 시키고 조기 피드백을받습니다.

경고:

UX와 엔지니어 간의 직접적인 커뮤니케이션은 프로토 타이핑 아티팩트로 대체되어서는 안됩니다. 가능하면 엔지니어와의 페어링은 중재자 (프로토 타입)를 통한 통신보다 더 효과적입니다.

다른 사람들은 이미 스파이크의 학습 목적을 언급했습니다. 빠진 것은 그것의 기본 민첩성 원칙인데, 그것은 빠르게 실패합니다 .

민첩한 개발의 기둥 중 하나는 어려운 부분을 인식하고 개념 증명을 위해 노력해야한다는 것입니다. "논리적"순서로 모든 작업을 수행하는 고전적인 방법은 프로젝트에서 늦게 작업을 수행 할 수없는 경우 실제로 비용이 많이들 수 있습니다. 지금까지의 모든 일은 낭비 일 수 있습니다.

그런 식으로 끝내야한다면 최대한 빨리 알고 싶어합니다. 그런 다음 이해 관계자는 아직 불타 지 않은 상태에서 돈 버는 것을 멈추고 원하는 것을 실현할 수 없거나 새로운 성공 가능성이있는 문제에 대해 근본적으로 다른 접근법을 시도하도록 선택할 수 있습니다. 프로토 타입이이 목적에 부합하는 경우 가장 민첩합니다.