기능 요구 사항이 민첩합니까?

요즈음 모든 사람들이 민첩 해지기를 원합니다. 내가 함께 일한 모든 팀에서 민첩한 모양이 달랐습니다. 일상적인 스탠드 업이나 계획과 같은 일반적인 일이 있지만 다른 부분은 크게 다릅니다.

현재 팀에는 방해가되는 세부 사항이 있습니다. 기능 요구 사항이 부족합니다. 예상되는 서면 형태는 물론 작업에서도 수행해야 할 작업이 모호하게 정의되어 있습니다.

프로젝트 목표는 새로운 기술을 사용하여 기존 시스템을 다시 작성하는 것입니다. 구식 시스템에는 합리적인 문서가 없습니다. 최신 버전이 존재하지 않는지 확인하십시오. 비즈니스 소유자의 요구 사항 설명은 이전과 동일한 방식으로 새로운 구현에서 수행하겠습니다. 합리적으로 보이지만 그렇지 않습니다. 오래된 시스템은 일종의 스파게티 코드이며 그로부터 비즈니스 요구 사항을 추출하는 데 많은 비용이 듭니다. 상황은 계획에 부정적인 영향을 미치는 것으로 보입니다. 새로운 구현에서는 실수와 버그가 발생하기 쉽습니다 (세부 사항은 생략).

따라서 나는 생각합니다-오래된 시스템을 다시 쓰는 경우 비즈니스 요구 사항이없는 것이 진정으로 민첩합니까?

기능적 요구 사항이 없는지 여부는 민첩하지만 재난을위한 레시피입니다. 해당 시스템의 작동 방식을 모르면 시스템을 재 구축 할 수 없습니다.

비즈니스 소유자에게 이전 시스템의 작동 방식을 모른다는 사실을 알려야합니다.

최선의 선택은 비즈니스 소유자 또는 경험이 적은 몇 명의 사용자와 협력하여 현재 진행중인 비즈니스 프로세스를 이해하고 자체 승인 테스트를 개발하는 것입니다. 일부 최종 사용자와 작업 할 수 있으면 이전 시스템의 작동 방식에 대한 추가 피드백을받을 수 있습니다.

실패하면 비 프로덕션 환경에서 자체 요구 사항을 수집하기 위해 탐색 테스트를 수행해야합니다. 비즈니스 소유자가 "오래된 것과 같이 작동하게"한다고 여러 번 말하면 제 시간에 제약을 받고 비즈니스 소유자처럼 도움을 줄 수 없습니다. 기존 시스템의 작동 방식을 이해하려면 숙련 된 사용자의 전문 지식이나 많은 수동 테스트가 필요합니다.

비즈니스 소유자에게 이전 시스템에 대한 요구 사항과 이해가 부족하면 시스템을 재 구축하는 데 걸리는 시간이 약 3 배 이상 증가 할 것이라고 알립니다. 시간과 비용이 증가함에 따라 비즈니스 소유자는 요구 사항을 더 빨리 수집하는 데 필요한 전문 지식을 제공하거나 현재로서는 재 작성이 경제적으로 실현 가능하지 않다고 결정합니다.

다음 중 하나가 제공됩니다.

• 적절한 요구 사항과 더 빠른 개발주기
• 요구 사항을 수집하고 소프트웨어를 재구성 할 시간
• 경력에 흑점을 남기지 않는 새로운 프로젝트

애자일은 기능 요구 사항의 필요성을 변경하지 않지만 일반적으로 요구 사항을 수집 하는 방식을 변경 합니다. 민첩하지 않은 방법은 누군가 긴 프로세스를 거쳐 시스템에 대한 모든 요구 사항을 포함하는 일종의 문서를 제공하는 것입니다.

요구 사항을 수집하는 민첩한 방법은 시스템의 작은 증분에 대한 요구 사항을 지정하고이를 구축 한 다음 피드백을 받고 다음 증분을 수행하는 것입니다. 비즈니스 소유자가 프로세스를 시작하는 데 어려움을 겪고있는 상황에서는 다음에 작업하려는 이전 시스템의 일부를 탐색하는 데 반나절을 투자하여 요구 사항에 대한 질문 목록을 생성합니다.

그런 다음 비즈니스 소유자와 함께 앉아서 질문하십시오. 어떤 질문은 대답하기 쉽고, 어떤 질문은 코드를보고 답하기 쉽고, 어떤 질문은 대답하기가 어렵습니다. 어려운 질문에 답할 수있을 때까지 작고 작은 조각으로 나눕니다.

목표는 무언가를 구축하고 피드백을 얻고 프로세스를 다시 시작하기 위해 충분한 질문에 답변하는 것입니다. 변경 사항이 작을수록 피드백주기가 짧을수록 잘못된 것을 구축하는 경우에 덜 중요합니다.

요구 사항 캡처는 (성공적인) 소프트웨어 프로젝트의 필수 부분입니다. 그러나 요구 사항 사양을 작성하는 것은 아닙니다.

• 문서 중심의 접근 방식은 Chinese Whispers 게임처럼 끝날 수 있습니다. 주제 전문가는 요구 사항을 말하고, 분석가는이를 작성하고, 개발자는 분석가의 설명에 맞는 것을 작성하려고 시도합니다. 소프트웨어는 그들의 문제를 해결하지 못했습니다.

  민첩한 기술은 개발자가 주제 전문가, 일반적으로 최종 사용자로부터 직접 요구 사항을 수집해야한다고 제안합니다. 이를 위해 다양한 기술이 있습니다 (예 : SME와 시나리오 예를 통해 대화). 개발자는 엣지 케이스를 파악하고 SME에게 엣지 케이스에서 소프트웨어의 작동 방식을 명확하게 요구합니다.

• 애자일 팀은 모든 요구 사항을 미리 수집하여 (오해가 큰 오해의 위험이 있음) 작은 요구 사항으로 시작하여 프로토 타입을 구축 한 후 다음 반복에 대한 피드백을 수집하는 데 사용할 것입니다.

• 요구 사항에 대한 이해가 시간이 지남에 따라 변함에 따라 정적 요구 사항 스펙이 오래되었습니다. 어떻게 방지 할 수 있습니까?

  요구 사항을 실행 가능한 테스트로 표현합니다. "읽을 수있는 사양"과 "실행 가능한 테스트"는 배타적 인 개념이 아니라 하나의 동일한 문서 일 수 있습니다. 예를 들어 BDD 공간에서 오이 및 기타 아이디어는 여기에 매우 도움이 될 수 있습니다.

기존 시스템을 다시 작성하는 경우 원래 시스템이 요구 사항의 큰 원천이 될 수 있습니다. 그러나 어떤 측면이 관련이 있습니까? 틈새 기능을 사용하고 있습니까? 호환성을 위해 어떤 버그를 다시 구현해야합니까? 일반적으로 최종 사용자와 대화 할 수있는 해결 방법이 없습니다.

작업 시스템을 배치하는 것도 새로운 소프트웨어를 테스트하는 데 매우 도움이 될 수 있지만 민첩한 문제와는 관련이 없습니다.

마감 기한이 정해진 고정 범위 고정 시간 프로젝트는 민첩성의 대립입니다. 일반적인 민첩한 접근 방식은 기능의 은색을 선택하여 먼저 제공 한 다음 반복하는 것입니다. 가장 중요한 것은 먼저 수행하고 덜 중요한 것은 나중에 수행합니다. 모든 것이 중요하고 최대한 빨리 완료되어야하는 경우, 아무 것도 중요하지 않으며 프로젝트는 아무 것도 전달하지 않을 것입니다.

현재 상황에서 요구 사항이 부족한 것은 민첩한 기능이 아니라 조직 기능 장애의 평균 사례입니다. 프로젝트를 성공 시키려면이 기능 장애를 극복 할 수있는 방법을 찾아야합니다. 예를 들어 비즈니스 소유자는 완전한 요구 사항 문서를 작성하지 말고 가장 중요한 기능에 대한 요구 사항을 설명하는 모임을 설정하십시오. 자세한 내용은 이전 시스템을 볼 수 있습니다. 그런 다음 해당 기능을 구현하고 반복하십시오.

우리가 한 방법은 다음과 같습니다. 우리는 주인과 이야기했습니다. 우리는 관리자와 이야기했습니다. 우리는 작업을 수행하는 사용자와 대화했습니다. 우리가 사용자의 책상에 앉아보고 (그리고 질문을하여) 찾은 것은 놀랍도록 유용했습니다. 관리자는 우리가 어떤 사용자와 함께 앉아 있어야하는지 알고있었습니다.

우리는 시스템의 일부 부분이 실제로 매우 잘 작동한다는 것을 발견했으며, 설계 및 코딩 및 테스트 사례 등을 시작하기에 충분한 요구 사항을 쉽게 작성할 수 있지만 다른 부분은 바닥에있는 사용자가 사용하는 불쾌한 해결 방법이 있었지만, 관리자와 소유자가 알지 못하는 기존 시스템의이 부분들에 대해, 우리는 비즈니스로 되돌아 가서 작은 작업이 무엇인지 파악하고 민첩한 방법으로 원하는 단위로 분류하기 전에 약간의 워크 플로우와 프로세스에 대해 이야기했습니다.

따라서 애자일은 시스템의 일부 부분을 신속하게 시작할 수 있지만 다른 부분은 시작하기 전에 좀 더 생각하고 문서화해야했습니다.

애자일 프레임 워크에서 요구 사항을 수집하고 아무도 사용자 사례를 언급하지 않았습니까? 사용자 스토리는 기본적으로 소프트웨어가 수행 할 수있는 작업에 대한 높은 수준의 정의입니다. 일반적으로 비즈니스 또는 최종 사용자의 의견이나 요청은 사용자 스토리로 작성 될 수 있습니다. ... 수용 기준을 사용자 스토리를 지원하는 기능 요구 사항으로 생각할 수 있습니다.

이 질문은 민첩한 움직임에 무엇이 잘못되었는지 암시합니다. 질문하는 사람의 잘못이 아닙니다. 수년간의 기업 생활이 저를 훈련 시켰기 때문에 저는이 함정에 빠졌습니다.

내가 말하는 함정은 일을 할 수있는 처방되고 올바른 민첩한 방법이 있다고 생각하는 것입니다. 사람들이 애자일이 존재한다고 생각하기 때문일 수 있습니다. 당신은 할 수 할 더 이상 당신이 할 수있는 것보다 민첩한을 할 실용.

"기능 사양"또는 기타 사항이없는 경우 걱정되는 것처럼 들리지만 그렇지 않을 수 있습니다. 얼마나 자세하게 시작해야합니까? 보안과 성능은 선구자 적이며 모든 과정에 적용되는 명백한 것입니다. 그렇지 않으면 옵션 가격 책정 엔진입니까 아니면 시계 앱입니까?

소프트웨어의 지속적인 출시, 토론, 학습, 돌아 가기 및 변경이 있습니까? 당신은 구축하고 소프트 웨어 또는 하드웨어를?

워터 폴 프로세스에서 일하는 개발자는 종종 후기 단계까지 참여하지 않기 때문에 문제가됩니다. 초기 또는 처음부터 그것들을 포함한다는 것은 그들이 불분명하고 정의되지 않은 반쯤 구운 것들에 사로 잡혀 있다는 것을 의미합니다. 실제로 그들의 일의 일부가 "무엇입니까? "우리가 만들려고하는 기능적 요구 사항?"

계획에서 허점을 찾는 것은 결함을 찾는 것이 아니라 소프트웨어 개발 만하는 것입니다.

이런 이유로 나는 Guy의 대답을 좋아합니다.