수락 기준없이 소프트웨어를 어떻게 개발합니까?

테스터가 무엇을 테스트 할 것인지, 제품 소유자 역할을하는 여러 (2-3) 명의 사람들과 함께 수용 기준없이 4-5 명의 개발자 팀에서 소프트웨어를 공동으로 개발하는 방법

우리가 가진 것은 스크린 샷과 총알 점이 몇 개있는 스케치 '스펙'입니다.

우리는 이것이 쉬울 것이기 때문에 이런 것들이 필요하지 않다고 들었습니다.

진행 방법에 대한 손실이 있습니다.

추가 정보

우리는 어려운 마감일을 받았습니다.

고객은 내부에 있으며 이론 상으로는 제품 소유자가 있지만 소프트웨어를 테스트하는 최소 3 명은 소프트웨어가 제대로 작동한다고 생각하는 방식으로 작동하지 않아서 작업 항목이 실패 할 수 있으며 기대하거나 투명하게 투명하지 않습니다. 그들이 실제로 실패 할 때까지 테스트하고있는 것.

제품 소유자는 질문에 대답하거나 피드백을 제공 할 수 없습니다. 정기 회의 나 회의가 없으며 피드백은 며칠이 걸릴 수 있습니다.

나는 우리가 완벽한 스펙을 가질 수는 없다는 것을 이해할 수 있지만 실제로 각 스프린트에서 작업하는 것들에 대한 수용 기준을 갖는 것이 '정상적'이라고 생각했습니다.

반복 프로세스는 상세 사양없이 훌륭하게이를 달성한다.

스케치 프로토 타입을 만들고 고객에게 피드백을 요청하고 피드백을 기반으로 변경 한 다음 응용 프로그램이 완료 될 때까지이 프로세스를 반복하면됩니다.

고객이 이런 식으로 할 수 있을지 인내심은 다른 질문입니다. 일부 클라이언트와 개발자는 실제로이 프로세스를 선호합니다. 고객은 항상 실습을하기 때문에 (결국) 원하는 것을 정확하게 얻을 수 있습니다.

이런 식으로 고정 비용 또는 고정 시간 계약을하지 않을 것이라는 것은 말할 것도 없습니다.

당신이 말하는 것이 사실이고 사양이 당신이 시작조차 할 정도로 충분히 좋은 곳이 아니라면 (그리고 당신은이 평가에 정직한 경우), 나는이 aproach를 추천합니다 :

1. 주어진 스케치와 "스케치"사양을 읽으십시오.
2. 하는 수준으로 자신의 스펙을 쓰기 충분히 당신이 코드를 할 수 있으려면. 당신은 많은 추측을해야 할 수도 있습니다.
3. 검토를 위해 고객에게 사양을 보여주십시오. 그들이 좋아하는 부분을 기록하고 잘못 생각한 부분에 대한 자세한 정보를 얻으십시오.
4. 귀하와 고객이 동기화 될 때까지 2 단계와 3 단계를 반복하십시오.
5. 이제 적절한 사양을 갖추 었습니다.

"쉽게 될 것"이라고 말했을 때 고객이 옳았다면,이 연습은 케이크 한 조각이어야합니다.

고객이 잘못하고 실제로 요구 사항에 모든 종류의 문제와 격차가있는 경우 초안 사양은 문제를 신속하게 설명하고 문제가 있기 때문에 고객이 잘못했음을 알려줍니다 (손가락을 가리 키거나 논쟁하지 않아도 됨) 바로 앞에 있고 분명합니다. 또한 귀하의 사양은 이러한 모호성을 해결하기위한 훌륭한 토론 도구 역할을하며 피드백을 통해이를 수정함에 따라 주요 결정에 대한 기록 역할을합니다.

제품 소유자가 프로토 타입을 건네주었습니다. 더 나은 사람을 돌려주십시오 (완료 될 때까지)

프로젝트를 시작하기위한 종이 프로토 타입을 제공받은 것 같습니다. 그것은 끔찍한 시작이 아닙니다. 점진적으로 유능한 프로토 타입을 제공 하여 동일한 언어로 비즈니스 소유자에게 다시 연락 하시기 바랍니다 .

프로토 타입은 종이로 시작하여 디지털 모형으로 이동 한 다음 "실제"기술로 구축해야합니다.

Treehouse 에는 이에 대한 훌륭한 가이드가 있습니다.

프레임 워크를 사용한 프로토 타이핑의 훌륭한 점은 구조와 스타일이 이미 적용되어 있기 때문에 프로토 타입이 종종 실제 사이트가된다는 것입니다. 동일한 프레임 워크를 사용하는 경우 사이트를 처음부터 다시 만들 필요가 없습니다.

특히 나쁜 결과로 인해 비난을받을 우려가있는 경우 공식 사양을 제공 할 수도 있습니다. 그러나 프로토 타입에서 더 많은 피드백을 얻을 수 있습니다.

마감일을 맞추십시오

나중에 할 수있는 노력은 일회용이 아니기 때문에 고전적인 "시제품"이 될 수 없습니다. 최종 기한이 결과물이되기 전에 완료 한 가장 유능한 반복.

마감일은 가장 잘 정의 된 요구 사항입니다. 정시에 제공 할 수있는 완전하고 일관된 것을 준비하십시오.

테스터와 공동 작업

이 느슨한 프로세스가 회사에 새로운 일이라면 테스터는 아마도 당신보다 더 많은 손실을 입었을 것이며, 당신 에게지도를 구할 수도 있습니다 . 프로세스 초기에 시간을 가져야합니다. 공식적인 합격 기준을받지 않고 의미있는 시험을하도록 도와 주려고 상사에게 알리십시오.

테스터에게 제공 할 수있는 확고한 증거 (예 : "돌아갈 수있는"문서)가 있는지 확인하십시오.

시도 테스트 먼저 디자인

공식적인 요구 사항이 없기 때문에 테스트 케이스를 개발하기 위해서는 약간의 구조가 필요합니다.

Test First Design 및 / 또는 테스트 중심 개발에 대해 잘 알고, 테스터에게 프로세스에 대한 지침을 제공하십시오. 이와 같은 빠른 프로젝트를 위해 프로세스 전문가가 될 필요는 없습니다. 그러나 입증 된 방법을 사용하면 귀하와 테스터에게 잘 반영됩니다.

특히 UI를위한 표준 준수

모양과 느낌에 대한 요구 사항은 없지만 마감일이 있습니다. 다른 사람의 디자인 작업을 사용하여 전문가 수준의 유물을 제작하는 데 필요한 작업을 최소화하십시오.

사이트의 표준 UI를 선택하고 지시하지 않는 한 사용자 정의하지 마십시오. 어떤 플랫폼을 개발하고 있는지 모르겠지만 부트 스트랩 또는 Google Material Design 이 두 가지 예입니다.

의사 소통하지 말고 의사 소통하지 마십시오

하루에 하나의 이메일을 제품 소유자에게 보내는 것이 좋습니다. 응급 상황 인 경우에만 그 이상을 보내십시오.

질문이있는 경우 지침을받지 못한 경우 어떻게 진행할 것인지 설명하십시오. 예를 들면 다음과 같습니다.

이 앱의 사용자가 휴대 기기로 액세스해야합니까? 지금 우리는 이것이 데스크탑 / 랩탑 전용 시스템이라고 가정합니다.

당황하지 마십시오

나는“요구 사항”이라는 용어를 모르는 사람들을 위해 많은 프로젝트에 참여했습니다. 대부분 성공했습니다. 실제 제품 소유자는 훌륭한 솔루션을 구축 할 수있는 위도를 제공합니다.

이 프로젝트의 일부 프로젝트 소유자는 자신의 무능력에 대한 변명으로“나는 너무 바빠서…”라고 숨길 수 없었습니다. 그러나 대부분은 최종 결과로 "기뻐했습니다".

프로젝트는 확실성이 달성 될 때까지 불확실성을 줄이는 행위입니다 .

• 처음에는 항상 어느 정도의 불확실성이 있습니다. 때로는 요구 사항이 약간 모호합니다. 때때로, 그것은 매우 스케치적인 것입니다. 당신은 일의 일부로 운동해야합니다.
• 비결은 이러한 불확실성 (분석, 설계 및 구현의 결합)을 반복적으로 줄이고 사용자 스토리를 개선하며 시스템을 구현하는 것입니다.
• 사례 / 시나리오를 테스트하고 승인 기준도 같은 방식으로 설명해야합니다. 품질과 정확성에 대한 불확실성을 줄이는 데 기여할 것입니다.
• 결국 충분한 확실성에 도달합니다. 고객은 자신의 요구에 맞는 테스트 제품을 받고 사용할 수 있습니다.

그것이 점진적인 정교화의 원칙입니다. 요구 사항, 기준 및 결과는 단계적으로 정교해질 것이며, 개발 프로세스에 대한 참여를 통해 고객이 자신의 기대 및 요구 사항을 이해하는 것처럼 단계적으로 정교해질 것입니다.

이것이 문제입니까?

초기 요구 사항을 스케치하면 불확실성이 높아지고 작업을 수행하는 데 필요한 시간이 길어집니다. 따라서 추가 작업을 수행 할 사람과 비용을 지불 할 사람이 문제입니다.

이 두 가지 질문에 대한 답은 계약서에 있어야합니다. 또는 협상의 대상이 될 것입니다. 그리고 고객은 추가 개입을 수락해야합니다 (주요 주장은 "쓰레기 수거, 쓰레기 수거"가 될 것입니다. 그러나보다 외교적 인 방식으로 제시 할 것을 강력히 권합니다.)

" 정기적 인 미팅이 없습니다 ". 그렇다면 정기 회의 일정을 잡는 것으로 시작하는 것이 어떻습니까? 제품 소유자가 여러 명이라는 사실만으로도 각 이해 관계자와 직접 논의해야하는 상충되는 요구 사항이 있기 때문에 프로젝트가 쉽지 않을 것입니다.

또한, 나는 정말로, 정말로 당신 이 자세한 결정 로그 를 유지하는 것이 좋습니다 . 최소한 결정한 날짜와 날짜를 포함하여 누군가가 결정한 모든 것을 적어 두십시오. WHY를 적어 놓을 수 있다면 더 좋을 것입니다. PC의 파일인지, 인트라넷 위키의 페이지인지, 책상의 노트북인지는 중요하지 않습니다. 로그는 사용자와 프로젝트를 보호합니다. 테스터가 일부 항목에 "실패"를 표시하면 해당 사람들과 함께 그렇게 결정된 것으로 지적 할 수 있으며 문제는 아니지만 그들과 테스터 사이에 있습니다. 이로 인해 사양이 변경되는 경우에는 문제가 없지만이 시점에서 그들이 생각한 마감일을 충족 할 것으로 기대할 수 없거나 다른 곳에서 범위를 줄여야합니다.

명확한 요구 사항이없는 프로젝트, 느슨한 리더십, DoD (정의되지 않음), 적시에 업무를 수행 하고 마감일을 맞추는 데 필요한 정보를 보유 할 책임 이있는 사람은 프로젝트의 레시피입니다. 실패.

반복 개발은 나쁜 제안은 아니지만 제품 소유자와 개발자 간의 긴밀한 협력이 필요합니다. "우리는 궁금한 점이 있다는 것을 알고 있습니다. 누가 프로젝트 전달이 지연되지 않도록 정기적으로 응답 할 수 있습니까?" 진행 상황을 검토하고 장애를 제거하기 위해 다른 사람과 정기적으로 시간을 예약하십시오. 그들이 보여 주거나 거절하지 않으면, 공손한 서면 서신과 문서 지연 또는 무응답으로 후속 조치를 취하십시오. 제품 소유자를 사용할 수없는 경우 가능한 담당자를 제공하도록 요청하십시오.

또한 반복 개발의 또 다른 특징은 요구 사항을 변경하면 타임 라인을 변경해야한다는 것입니다. 타임 라인을 개발할 수없는 경우 마감일을 지키겠다고 결심 할 수 없으며 수행해야 할 작업에 대한 아이디어가 없으면 타임 라인을 개발할 수 없습니다. 교묘히 사양을 요구하는 대신, 현재 사양을 검토하고, 사양이 어떻게 작동해야하는지에 관해 귀하 또는 팀이 가지고있는 모든 질문을 문서화하고, 제품 소유자와 협의하여 시간을 예약하고, 답변을 문서화하십시오. 완료되면 의사 결정에 따라 사양이 지정되며,이를 통해 제품 소유자가 서면으로 동의하도록 할 수 있습니다. 스펙의 목적은 모호성을 제거하고 DoD를 작성하는 것인데, 이는 Q & A 세션이 제공 할 수있는 것입니다. 스펙에 반대되는 경우 스펙이라고 부르지 마십시오.

그들이 당신에게 쉬운 것이라고 말할 때 아무도 믿지 마십시오 . 때로는 정말 소리가 나는 것처럼 간단하고, 믿을 수있는 경우 (만 하면 나는 완전히 그들이 말하는대로 요구 사항은 정말 단순한 것을 믿을 충분히 제품 소유자를 알고), 및 사양은 내가왔다 설명이 필요하지 않습니다 (그렇지 않은 경우 Q & A 세션을 예약하고 문서화 함). 어디 너무 많은 상황에서왔다 쉬운 오퍼레이션 관점에서가 매우 어렵다개발의 관점에서 볼 때, 당신은 완전히 끝났다고 생각하고 절망의 말을 듣습니다 ( "아, 그건 그렇고, 우리는 잊어 버렸습니다 ..."). 예 ... "문서 저장소에서이 PDF 파일을 읽기만하면됩니다."승인 테스트 중에 "아,이 파일 중 일부가 완전히 일관성이없는 방식으로 옆으로 읽히는 것을 잊었습니다. 일부는 잘못된 페이지 크기를 정의하고 일부는이 세 페이지를 추가해야하며 모두 동일하게 표시해야합니다. 정말 고치기 쉬워요? ".

요점은, 실제로는 쉬울 수 있으며, 빠른 회의를 통해 모든 가정을 문서화하고 정확하고 정확한지 확인할 수 있습니다. 발가락을 밟는 지 여부에 관계없이 어쨌든 누군가가 아마 행복하지 않을 수 있기 때문에 기대에 맞는 작업 코드를 작성 해야하는 장애를 제거하기 위해 일어서는 것이 좋습니다. 질문에 대한 답변을 받고 누군가를 짜증나게하는 경우, 요구 사항을 충족하는 우수한 제품을 적시에 제공하면 질문을 잊게됩니다. 설명을 얻지 못하고 전달하지 않으면 아무도 버그를 말하지 않았다고 기억하지 않습니다.

사양이 없으면 팀워크가 있습니다. 민첩하게 가십시오.

PO와 함께 앉아 약간의 작은 시작 이야기 /들. "우리는이 버튼 만 '빙빙'으로 이동합니다." 일부 AC에 정착하십시오. 이야기를 전달하십시오. 이야기를 보여 주십시오. 버튼이 빨간색이어야합니다. 버그 나 새로운 이야기를 올리십시오. 봉과 쾅 이동 버튼을 제공합니다. 등등.

자주 시연되는 작은 수직 슬라이스를 공동으로 지정하고 제공합니다.

고객이 이런 식으로 당신과 함께 일하지 않으면 탈출구를 찾으십시오.

나는 당신이 설명 한대로 프로젝트를 수행하는 여러 가지 일을 보냈습니다. PO가 어떤 설계 결정을 내리고 왜 결정을 내려야하는지 알고 있다면 괜찮을 것입니다. 반면에, 디자인 결정을 이해하지 못하면 최소한 사용자 승인 테스트 문서를 작성해야합니다.

코드 작성을 시작하기 전에 상세하고 검증 가능한 사양이 필요합니다. 그것은 사실이며, 주변을 돌아 다니지 않습니다.

다른 사람이 그 사양을 기꺼이 쓰지 않는다면 개발자는 그 사양을 작성해야합니다. 따라서 불완전한 사양을 얻습니다. 당신은 그것을 완전한 스펙으로 바꾼다 (이것은 "다른 사람이 나에게 지시하지 않는 한 구현할 것이다"를 의미한다). 해당 사양을 이해 관계자에게 전달하고 사양을 수정할 수있는 기회를 제공하십시오. 예를 들어 "이 방식이 마음에 들지 않습니다"라고 말하여 스펙 을 수정 하지 않는 것이 좋습니다. 이 시점에서 사용자의 스펙이거나 다른 스펙을 제공 할 수 있지만 스펙을 제거 할 수는 없습니다.

사양을 개선 할 수있는 동료로부터 빠른 검토를받는 것이 좋습니다. 어쨌든, 당신은 사양을 가지고 있으며, 그에 따라 코드를 작성하고 테스터는 그에 따라 테스트합니다. 그리고 당신은 일을 끝냈습니다 : 당신은 스펙을 가지고 그것을 구현했습니다. 사양이 고객이 원하는 것이 아니라면 제품 사양이나 좋은 사양을 작성하는 데 방해가되지 않은 고객의 책임입니다.