"실패 중심 개발"에 대해 어떻게해야합니까?

우리 가게에서는 민첩 해 지려고 노력합니다. 그리고 우리가 큰 걸음을 내딛고 있다고 말하고 싶습니다. 즉, 우리 중 일부는 "실패 중심 개발"이라고 부르기 시작한 패턴을 발견했습니다.

실패 주도 개발은 기본적으로 버그 / 기능이 작업 및 스토리가 아니라 승인 기준을 통해 결함 추적 소프트웨어에 입력되는 민첩한 릴리스 / 반복 주기로 설명 될 수 있습니다.

Google 팀에는 훌륭한 프로젝트 관리자가있어 고객으로부터 합격 기준을 얻으려고 노력하지만 항상 가능하지는 않습니다. 내 개발 의장에서 이것은 고객 이 원하는 것을 정확히 알지 못 하거나 고객의 본사에서 서로 다른 두 가지 "캠프"가 스토리 구현 방법과 충돌하기 때문입니다. 캠프 A는 느슨하게처럼 그 기능 X 작업 지시 할 것이다 이 다음 캠프 B 인한처럼 작동하지를 실패 하는 . 따라서 "FDD"라는 용어입니다. 프로세스는 "실패"에 의해 진행됩니다.

이것은 내 질문으로 이어진다. 다른 사람이 이것을 만났고, 그렇다면 그것을 다루는 데 도움이되는 팁 / 제안이 있습니까?

물론 우리는 캠프 A와 B가 사전에 동의하도록했지만, 모두가 항상 그런 것은 아니라는 것을 모두 알고 있습니다.

감사

기업 세계에서 격렬하게 상충되는 요구 사항은 드문 일이 아닙니다. 그리고 이것이 종종 비즈니스 프로세스 자동화 프로젝트가 "실패"하는 이유입니다. 실제로 "작업을하는 사람들은 Y를하는 것과 같이 정책과 절차 매뉴얼에서 말하는 것처럼"간단 할 수 있습니다. 원근법. 소프트웨어를 X로 만든다는 것은 실제로 작업을 수행하는 사람들이 작업을 수행 할 수 없음을 의미합니다.

일반적으로 대부분의 개발 회사는 관리자가 근로자의 진술에 대해 말하는 것을 선택합니다. 이상적인 세계에서는 서면 정책과 실제 정책간에 임피던스 불일치가 없습니다. 현실 세계에서 많은 사무는 비공식적으로 분할되고 문서화되지 않았습니다.

캠프 A는 기능 X가 이와 같이 작동한다는 것을 잃어 버릴 것이며, 캠프 B는 그렇게 작동하지 않아 실패 할 것입니다.

CampA와 CampB의 불일치는 정치적 문제이며 소프트웨어 문제가 아닙니다. 문제를 해결하려면 사람들과 대화하고 분명한 승자를 얻으십시오.

반복 개발 을 사용하는 주된 이유 중 하나는 원하는 것을 잘 모르는 고객 그룹이 있기 때문입니다.

이것은 실패가 아닙니다. 많은 고객은 손에 무언가를 얻을 때까지 필요한 것이 무엇인지 정확히 알지 못합니다. 그렇기 때문에 고객이 처음으로 시스템을 장착하고 마무리 한 후에 시스템을 사용해서는 안된다는 것을 알게됩니다. 그들이 자주 그리고 자주 그것을 보게하십시오.

다시 말해, 이것이 유일한 문제라면 끝없는 재 시도를하지 않는 상황에 빠지지 않는 한 당황 할 필요가 없습니다.

고객 단체 간의 의견 차이 문제는 사용자에게 유출되어서는 안되는 제품 관리자 문제입니다. 가장 많이보아야 할 것은 백 로그 / 작업 / 무엇이든입니다. 물론, PM은 개발할 수있는 유일한 장소이기 때문에 종종 개발 범위에 영향을 줄 것입니다. 그러나 그것은 당신에게 영향을 미치지 않아야합니다.

관리 방법은 캠프 A와 캠프 B가 누구인지에 따라 크게 다릅니다.

캠프 A와 캠프 B가 두 개의 상위층을 대표 할 경우 실제로 시스템을 사용할 사람을 데려와 필요한 것을 알려줍니다. 때로는 관리 토지에서 희귀 한 공기가 유입되어 현실과 단절되는 경우가 있습니다. 실제로 누군가가 이상주의를 극복하고 실제로 필요한 것을 지적 할 수 있습니다.

반면에 A와 B가 사용자 그룹 인 경우, 다른 사람을 경영진으로부터 법을 정하도록하는 반대 방법을 사용합니다.

모든 경우에 완전은 선의 원수입니다.

당신이 묘사하는 것은 전형적인 애자일의 잘못된 구현입니다. 당신은 변화를 받아들이지 않습니다 . 당신은 노예 입니다.

제품 소유자가 있습니까? 필요에 따라 그들과 대화 할 수 있습니까? 사용자와 스프린트 검토를하고 있습니까? 스프린트 계획에서 사용자는 제품 소유자를 통해 프로세스에 참여하고 있습니까? 메인 팀에 테스터가 있습니까?

Agile 코치를 고용하거나 팀을 훈련에 파견하는 것이 좋습니다.

또 다른 해결책은 애자일 수행을 중단하는 것입니다.

그들이 탁구를하고 있다면 (A는 x를 말하고, B는 거절하고, y를 말하고, A는 거절하고, x로 되 돌린다.) .

첫 번째 시도가 필요를 충족시키지 못하면 (이것의 요점은 볼 것을 제공하는 것입니다), 그들이 거기에 앉아서 후속 반복에서 앞뒤로 흔들면 결코 끝나지 않을 것입니다.

여기서 문제는 "내가 볼 때 알게 될 것"이 아닌 것 같습니다. 와이어 프레임은 특정 문제에 도움이 될 수 있습니다.

여기서 문제는, 내 고객에게있는 두 개의 경쟁 파벌 인 것 같습니다. 이상적으로 캠프 A와 B는 그들이 당신에게 제시 할 수있는 협상 된 공유 비전을 제시 할 것입니다.

아마도 A가 B에게 요청한 것을 다시 (또는 그 반대) 다시 실행함에 따라 싸움에 소요되는 비용이 얼마나되는지 설명함으로써 테이블에 강제로 배치 될 수 있습니다.

시간 지출에 대한 자세한 메모를 유지하면 여기에 도움이 될 것입니다. (저의 작업은 사용하기 쉽고보고하기 쉬운 간단한 시간 추적 응용 프로그램을 작성했으며 15 분 단위로 시간을보고합니다. "특징 X에 n 시간을 소비했습니다."

그것은 당신이 클라이언트를 화나게하거나 당신이 무엇을하든 나쁘게 보일 위험이 있다는 것을 의미합니다. 왜냐하면 당신이 B를 위해하는 것이 A를 화나게 할 수 있기 때문입니다.

바라건대 당신은 당신을 위해 투쟁을 돌볼 수있는 고객에서 챔피언을 찾을 수 있습니다.

내가 알다시피, 문제는 고객의 한 곳에서만 효과적으로 해결할 수 있으며, 이는 어려울 것입니다.

당신은 애자일을 위해 노력하고 있다고 언급하고 있습니다. 저는 스크럼의 관점에서 제가 가장 잘 알고있는 민첩한 프로세스 인 스크럼을 고려할 것입니다.

스크럼에 따르면 사용자 스토리 / 버그 / 릴리즈 등의 우선 순위를 결정하는 특정 역할, 제품 소유자가 있습니다. 이는 이상적인 사람이어야합니다. 동일한 소프트웨어에 대해 다른 견해를 가진 많은 이해 관계자가있는 경우, 제품이 모든 이해 관계자를 만족시키는 것은 제품 소유자의 책임입니다.

프로젝트 관리자에게이 역할이 있다고 들립니다. 그러나 그는 제품 관리자가 아닌 프로젝트 관리자라고 불리우 기 때문에 다른 업무 (전통적, 비 민첩성, 관리 업무)에도 부담이 있으며, 제품 소유자 역할.

따라서 고객의 서로 다른 팀간에 요구를 조정하고 개발자에게 전달되는 요구 사항 / 사용자 스토리가 고객의 두 팀에 의해 확인되도록하는 책임이있는 사람이 필요하다고 생각합니다. 이 역할을 추구하는 것은 특히 당신이 가진 고객과 함께 쉽게 풀 타임 직업이 될 수 있습니다.

실제로 이상적인 것은이 책임을 고객에게 옮기고 고객의 직원 중 하나가 제품 소유자 역할을 갖도록하는 것입니다. 고객이이 역할을 수행하지 않는 한 고객은 자체 내부 불일치를 해결하기 위해 최선을 다하지 않으며이를 해결하기 위해 고객에게 맡겨야합니다. 그렇기 때문에 유일하게 효과적인 해결책은 고객에게 이러한 책임을 부여하는 것입니다.

그러나 이미 공동 작업을 시작했다는 사실을 감안할 때 변경 사항을 구현하는 데 어려움을 겪을 것이라고 생각합니다.

고객이 소프트웨어를 승인 받으려면 승인 기준에 따라 고객이 설정 한 요구 사항을 충족해야합니다.

스토리 및 승인 기준의 형태로 사용자 요구 사항 세트가 있지만 고객 조직 의 일부는 사용자 스토리에 대한 해석 이 다르 므로 모호합니다.

기능 설계 및 구현 된 비즈니스 규칙을 설명하고이를 고객이 서명함으로써이 상황에서 벗어날 수 있습니다. 그런 다음 수락하는 동안 테스트됩니다. 이후 모든 문서의 의미에 대한 논의를 방지하기 위해 고객과 사전에 합의해야합니다.

두 그룹이 동의하는 방식으로 귀하의 그룹이 귀하가 구축하는 소프트웨어를 설명 할 수없는 한, 귀하는 여전히 프로젝트의 요구 사항 분석 단계에 있습니다.

프로젝트 관리자는 기능 요구 사항의 모호성을 해결하기 위해 프로젝트의 일부로 유료 컨설팅을 제공 할 수 있습니다.

우리는 모두 사용자로부터 세부적인 요구 사항을 얻고 구현 한 다음 사용자가 "잠깐만 요, 저에게는 효과가 없을 것입니다"라는 말을 듣는 사례를 모두 본 것 같습니다.

도움이 될 수있는 한 가지는 사용자에게 예상되는 시스템 동작에 대한 자세한 예를 제공하여 요구 사항에 대한 QA 형식을 수행하는 것입니다. 예를 들어, "여기에 사례가 있습니다. X를 구현하면 Y가 결과이고 Z가 결과 중 하나입니다." 그렇게하면 나중에 코드 대신 코드를 작성하기 전에 "잠깐만 요, 작동하지 않을 것"으로 갈 수 있습니다.