사용자 스토리가 너무 높고 개념적이며 경영진은 개발자가 공백을 채울 것으로 예상합니다.

저는 XP를 할 의도가있는 매우 훌륭한 회사에서 일하고 있습니다. 의사 소통은 양호하고 관리는 건설적인 논의에 개방적이지만 시간 제약으로 인해 RUP가 논의 되기에는 너무 어려운 것으로 간주됩니다.

현재 나는 이야기를 구현하는 동안 필요한 변화의 양에 약간 어려움을 겪고 있습니다. 이러한 많은 발견 (물론 시간과 노력이 필요함)은 개발자가 아닌 스토리 작가 (고객, 최종 사용자 및 제품 소유자)의 책임이라고 생각합니다. 간단히 말해서, 사용자 스토리는 너무 개념적이고 기본 의도를 전달하지만 충분한 세부 사항 (특히 전제 조건 및 사후 조건, 다른 이야기와의 관련성, 종속성 등)이 부족합니다. 개발자는 디자이너와 분석가 인 XP 개발자 덕분에 자신의 재량에 따라 빈칸을 채워야합니다. 문제는 추가 된 복잡성이 처음 예상했던 것보다 눈에 띄기 때문에 일부 잘못된 가정이 평가 시간과 코드로 들어간 후에 발견 된 것입니다. 그래도 채워야 할 올바른 것을 찾는 데는 초기 추정치와의 편차로 간주되는 시간이 걸립니다.

나는 불필요하게 일을 복잡하게 만드는 사람으로서 나를 해치지 않는 방식으로 경영진에게 이러한 의미를 전달하는 건설적인 방법을 찾고 있습니다. 나는 새롭고 아직 많은 신뢰성을 확립하지 못했습니다.

당신은 통찰력을 가장 환영합니다.

밀접하게 관련되어 있으며 어떻게 든 대답을 제공합니다. 개발자가 사용자 스토리에 대해 얼마나 자세하게 설명 할 수 있습니까?

비결은 공백이 생기지 않도록하는 것입니다. 트릭은 개발 과정에서 가능한 빨리 해당 공백을 채우는 것입니다.

개발자가 가정을하면 항상 잘못 될 것이며 나중에 소프트웨어를 다시 개발하는 데 시간이 걸리는 것이 맞습니다. 그러나 비즈니스 사람들이 원하는 것을 실제로 모를 때 완전한 사전 설계를해야한다면 같은 일이 일어날 것입니다.

고객이 실제로 알지 못하는 경우 고객이 원하는 것을 파악하는 것은 개발자의 일 중 큰 부분입니다.

먼저 질문하십시오. 답변이 만족스럽지 않은 경우 프로토 타입을 만드십시오. 고객에게 원하는 것을 보여주고 실제로 원하는 것이 아닌지 알려줍니다. 종이 프로토 타입으로 시작한 다음 코드가없는 HTML 기반 프로토 타입으로 이동하십시오. 그런 다음 거의 작동하는 제품을 생산하는 데 필요한 최소의 개발 작업을 수행하고이를 보여줍니다. 까다로운 비트는 가능한 한 늦게 처리하십시오.

이것은 시간이 많이 걸리는 것처럼 들릴 수도 있지만, 완제품을 재개발하는 것과 비교할 때 그렇지 않습니다.

또한 이야기를 가능한 작게 유지하십시오. 비즈니스가 원하는 것은 항상 서사시이며, 많은 결과물로 나눌 수 있습니다. 최종 릴리스 후보를 볼 때 너무 많이 개발하지 않았기 때문에 "더 나은 것은 아닙니다. 아뇨, 그건 우리가 찾고있는 것이 아닙니다."

그래도 채워야 할 올바른 것을 찾는 데는 초기 추정치와의 편차로 간주되는 시간이 걸립니다.

그것은 나에게 "XP"처럼 들리지 않습니다.

XP 전문가는 아니지만 XP의 AFAIK 아이디어는 프로세스에서 피드백을받을 때마다 사양과 평가를 지속적으로 조정하는 것입니다. 그리고 프로세스는 "작은 코드를 약간 디자인하고 약간의 코드를 약간 테스트 한 다음 가능한 한 빨리 잘못된 가정을 수정하기 위해 사용자 피드백 을 받습니다 . 예를 들어 사용자 피드백 을 더 빨리 받을 수 있습니다" , 소프트웨어의 일부 (예 : UI)를 종이나 화이트 보드에 디자인 한 후 이를 사용자 나 고객 과 논의한 후 "XP 방식"은 "XP 방식"이 " 사용자 사례 "

다음은 사양을 사용하여 피드백을 더 빨리 얻는 방법에 대한 좋은 기사 입니다. 이런 종류의 사고는 "방법론"에 독립적이라고 생각하며, 여기에 제시된 주장은 경영진과의 토론에 도움이 될 것입니다.

요약하면 다음과 같은 상황에 있습니다.

1. 당신은 새롭습니다.
2. 프로젝트 (당신이 실행중인 프로젝트에 대해 이야기한다고 가정합니다)에는 시간 제약이 있습니다.
3. 개발자는 자신의 판단에 따라 빈칸을 채워야합니다.
4. 당신이 일하고있는 회사는 XP를 연습하려고합니다. 그러나 사용자 사례는 XP 방법론에 적합한 방식으로 적용되지 않는 것 같습니다. 반면에 " 개발자는 자신의 재량에 따라 공란을 채울 것으로 예상됩니다 ".

포인트 4에 대해 생각하십시오. 제 의견은 민첩한 업무 방식이 회사 / 팀의 요구와 문화에 맞게 조정되어야한다는 것입니다 (다른 방식은 아님). 회사가 XP 방법론을 고수하는 곳과 벗어난 곳을 식별하십시오. 이것이 당신의 관심사에 대한 건설적인 접근의 토대입니다.

1과 2로 인해 회사가 XP를 합리적인 방식으로 적용 할 경우 현재 의문의 여지가 없습니다. 경영진과 논의를 시작하면 " 문제를 복잡하게 만드는"사람이 될 수 있습니다 . 그러나 동료 개발자와 문제를 논의하기 시작할 수 있습니다. 어쩌면 당신은 당신이 생각하는 일부 개발자를 찾을 수 있습니다. 어쩌면 고위 경영자가 개발자에게 우려 사항을 전달할 수도 있습니다. 그러나 특히 현재 프로젝트에서는 상황이 빠르게 변할 것이라고 기대하지 마십시오. 그러나이 프로젝트는 건설적인 접근 방식에 더 많은 물질을 추가하는 더 많은 데이터를 수집 할 수있는 좋은 기회를 제공합니다.

3 단계 : 고객 / 최종 사용자 / 제품 소유자 및 개발자 가 좋은 사용자 사례를 공동으로 작성했다고 생각합니다 . 일부 이니셔티브 표시 : 사용자 스토리 작성자에게 직접 요청할 수있는 기회를 찾으십시오. 이것이 가능하지 않은 경우 일부 선임 개발자 또는 경영진에게 사용자 스토리 작성자가 답변해야하는 공개 질문을 처리하는 방법을 문의하십시오. 어쩌면 당신은 적어도 서면 서신을 가질 수 있습니다. 자신의 재량에 따라 빈칸을 채워야하므로 고객 / 최종 사용자 / 제품 소유자를 적극적으로 참여시켜야합니다.

어느 시점에서 회사가 XP (또는 일반적인 민첩한 관행)를 적용하는 방법에 대해 충분히 생각하고 관찰했습니다. 아마 어느 정도 시간이 지났고 더 이상 그린 혼으로 인식되지 않을 것입니다. 고객과의 적극적인 참여가 긍정적 인 영향을 미쳤을 수 있습니다. 다음 프로젝트가 이미 시작되었을 수 있습니다. 어쩌면 당신은 이미 다른 개발자들로부터 백업을 받았을 것입니다. 어쩌면 당신은 그것이 작동하는 방식이 전혀 나쁘지 않다는 것을 알 수 있습니다. 요점은 회사 내 실제 경험과 데이터를 기반으로 경영진에게 우려 사항을 전달할 수있는 충분한 아이디어가 있다는 것입니다.

솔직히 말해서, 사용자 스토리에는 자세한 내용이 없어야합니다. "나는 소프트웨어가 Y의 비즈니스 요구를 충족하기 위해 X를하고 싶어" 한다 충분하다. 결국, 당신은 사업 사람들 이 그렇게하는 방법 을 지시 하는 것을 원하지 않습니다. 당신은 소프트웨어의 전문가와 그 안의 모범 사례입니다.

말했다 즉, 개발자는 또한 필요 질문 : "당신이 직장이를 기대하는 방법은", "어떤 일이 발생하면 기능 Z와 그 상호 작용?". 개발자는 요구 사항을 만들지 않고 구현합니다.

또한 구현과 평가 사이에 너무 많은 차이가있는 것처럼 들립니다. 이해 관계자는 며칠마다 반으로 완료된 코드로 프로토 타입을 검토해야합니다. 잡초에 너무 먼 길을 가기 전에 피드백을받을 수 있습니다.

자신에게 불완전한 이야기를 추정하도록 요청받은 경우, 이야기에 대한 질문이 있고 해당 질문에 대한 답변이 나오기 전에 적절한 추정을 할 수 없다는 사실을 알리십시오.

그런 다음 질문을하고 답변이 이야기의 일부가되도록하십시오.

질문에 모두 대답하지 않은 경우에도 추정을해야하는 경우 추정을 거부하거나 추정의 나머지 공백에 대해 최악의 결과를 가정하고 있음을 명확하게 표시하도록 선택할 수 있습니다 ( 아마도 귀하의 추정치를 더 높은 특이 치로 만들 것입니다).

당신이하는 일은 민첩한 개발 방식이 아닙니다. 대신 낮은 품질 요구 사항으로 작업하고 있습니다. 민첩한 개발 방식이 요구 사항을 지정하지 않는 것은 잘못된 일입니다.

대신, 처음에는 가능한 한 많이 지정해야하며 필요한 경우 나중에 변경해야합니다. 그런 다음 작업을 여러 부분으로 나누고 반복적으로 구현합니다. 각 반복 후에는 무언가가 완료되었습니다.

폭포 개발과의 차이점은 폭포 개발에 있으며 모든 것이 초기 요구 사항으로 구현되며 결국 변경됩니다.

개발자가 사용자 스토리 작성에서 완전히 제거 된 것 같습니다. 자세한 스펙처럼 읽고 처음으로 올바르게 작성할 수있을 것으로 기대하십니까? 그렇게 할 수 있다면 XP 나 다른 민첩한 방법론이 필요하지 않습니다.

이야기가 너무 모호한 경우 누군가 질문을해야합니다. 수락 테스트 는 어디에서 이루어 집니까?

사용자 스토리는 변경되어야합니다. 당신은 그것을 처리해야합니다.

개발자가 이야기 / 자세한 요구 사항을 작성할 수는 있지만 그것에 능숙한 많은 사람들을 보지 못했습니다. 우리는 문제를 지적하는 데 능숙합니다.

새로운 제품과 기존 제품에 대한 작업을 모두 수행했으며 5 줄만 요구하는 조건이 있었으며 빈칸을 채우고 '이해'하거나 더 정교한 문서를 작성해야했습니다.

프로젝트는 훨씬 나아졌고 우리는이 일을 도와 주었던 우리의 전문적인 서비스 담당자가있었습니다. 피드백이 다시 나오지 않고 마감일이 변경되지 않는 한 개발 시간 낭비입니다. 그래서 내 제안 : 자세한 내용을 요청하고, 더 많이 제공하고, 가정 및 문서에 대한 시간 제한 피드백을 요청하고 x 날짜 까지이 정보를 얻지 못하면 재 작업 및 지연이 발생할 위험이 있음을 진술하십시오.

개발 방법론에 관계없이 요구 사항을 정의하는 데 사용하는 것이 개발자가 가정을하는 경우 비즈니스 측면으로 되돌아 가야합니다. 나는 종종 어떤 대답을 선호하는지에 대한 좋은 생각을 가지고 있으므로 다음과 같이 다시 시작합니다.

XYZ는 확실하지 않습니다. ABC를 의미합니까? 아니면 뭔가 빠졌습니까? (XYZ가 요구 사항이라고 가정하고 ABC가 개발자로 만들고 싶은 가정이라고 가정)

재실행하는 것보다 잘못된 가정을하기 전에 정리하는 데 훨씬 적은 시간이 걸립니다. 자신의 추측이 옳다는 확인을받지 않고 요구 사항을 추측하는 개발자는 나쁜 개발자 인 경향이 있으며 회사에 많은 비용이 듭니다. 나쁜 관리자가 당신을 반발하지 못하게한다면, 시간과 돈의 측면에서 비용이 얼마나 비싼 지 설명해주세요. 그가 여전히 주장한다면, 그가 말한 것을 수행하고 UAT가 실패하면 다음에 무언가를 걷어차 고 싶을 때 그가 당신을 보내지 않을 때가 얼마나 비싼지를 상기시킵니다. 여전히 듣지 않으면 더 나은 상사를 찾으십시오.

반동의 또 다른 가치는 점진적으로 비즈니스가 필요한 것을 배우고 더 나은 요구 사항을 제공한다는 것입니다.

개발자로서

사용자 스토리의 세부 사항을 완전히 이해해야합니다.

자신있게 추정하고 구현할 수 있습니다.

다시 말해, 이야기의 특성을 이해할 때까지 질문을해야합니다. 이는 반복 계획에서 수행되며 결정 지점의 역할을합니다. 추정 할 수 없으면 작성할 수 없습니다.