저는 공공 기관에 의해 스크럼, 칸반 등의 용어와 개념을 설명하는 민첩한 개발 101에 관한 비공식 워크샵을 요청했습니다. 나는 지금 약 5 년 동안 민첩한 환경에서 일해 왔지만, 나는 스크럼 전도자라고 생각하지 않습니다.

워크샵 후 그들은 아이디어를 좋아했다. 그러나 외부 소프트웨어 회사에 소프트웨어를 개발하도록 위임해야하기 때문에이 방법이 적용되지 않을 것이라고 설명했습니다 (개발자 자신이 거의 없음). 이 액티비티는 결과, 가격 및 기간을 설명하는 공개 입찰 프로세스에서 수행해야합니다. 이것은이 조직 (공공 연구소)에 예산을 신청하기위한 법적 요구 사항입니다.

이러한 제약은 애자일 개발의 기본 원칙에 다소 모순되는 것처럼 보이지 않습니까?

이러한 환경에서 스크럼이 호환되지 않습니까?

이 조직에 무엇을 추천 하시겠습니까?

스크럼이이 조직에 적합하지 않을 수 있습니다.

Scrum Guide에서 "Scrum은 복잡한 제품을 개발, 제공 및 유지하기위한 프레임 워크입니다." 또한 제품을 개발하는 개발 팀 구성원 3-9 명, 제품 소유자 및 총 4-11 명으로 구성된 스크럼 마스터 (개발 팀에있을 수도 있고 없을 수도 있음)를 위해 설계되었습니다.

내부 개발과 관련하여 개발자는 소수에 불과합니다. Scrum 팀을 구성하기에 충분한 팀이 없으면 모든 Scrum을 사용하는 것이 이치에 맞지 않습니다. 그러나 일부 Scrum 사례는 조직에 유용 할 수 있습니다.

계약 개발의 경우 외부 당사자 중 하나가 Scrum을 사용할 수 있습니다. 이 경우 연구소가 스크럼 관행에 대해 알고 역할과 작동 방식을 이해하는 것이 유용합니다. 외부 개발 조직이 스크럼 관행과 다른 관행을 어떻게 사용하는지에 대한 구체적인 내용을 이해해야하지만 작동 방식을 이해하는 데 도움이 될 수 있습니다. 예를 들어, 제품 백 로그를 주문할 때 스프린트 리뷰에 참여하거나 조직 (아마도 제품 소유자)과 협력해야 할 필요성을 이해해야합니다.

미국 정부의 디지털 서비스 대행사 인 18F는 정부가 법에 부합하는 방식으로 민첩한 방법론을 사용할 수 있도록 계약을 작성하는 방법에 대해 많은 작업을 수행했으며, 작업 방법에 대한 자세한 요구 사항이 아닌 일반적인 결과를 명시했습니다. 해야합니다. 그들의 자원 중 일부는 다음과 같습니다.

• 민첩한 계약 형식을 통한 정부 성과 개선
• 민첩한 담요 구매 계약
• 모듈 식 계약 (애자일 개발을 통해 대규모 프로젝트를 소규모 모듈 프로젝트로 분리)
• 프로젝트가 "민첩성"을 사용하고 있습니까?

민첩한 작업 방법의 장점은 계약이 체결 된 후, 즉 15 항과 같이 세부적인 솔루션을 미리 지정하지 않고 사후 실행 중에 문제에 대한 솔루션을 발견하는 데 중점을 둔다는 것입니다. 민첩한 계약은 상세 솔루션이 필요한 문제를 종종 높은 수준의 계약 전달 영역을 설명하는 제품 백 로그 항목으로 지정하십시오.

이 문제를 이해하면서 관리 예산 국과 연방 조달 정책국은 기관이 SOW 사용을 중단하고 서비스 획득을 위해 성능 업무 명세서 (PWS) 사용으로 전환하도록 지시했습니다. PWS는“(방법)이 아닌 (결과) 수행해야 할 사항에 대한 일반적인 조건으로 요구 사항을 명시해야합니다.”훌륭한 계약 담당자는 전문가 서비스를 구매함으로써 대행사에게 조언을 제공합니다. "어떻게"작업이 이루어집니다. 미션 소유자는 "무엇을"달성해야하는지 전문가이지만, 둘을 합치면 미션이 위험에 빠지고 계약이 가치를 제공하기가 더 어려워집니다.

기본적으로이 접근 방식은 세부 사양 페이지를 미리 나열하는 대신 서비스 제공 업체가 솔루션을 설계 할 수 있도록 고용하는 것과 비슷합니다. 이 기관은 "건물은 지붕 높이가 37º 인 4 층 건물이어야합니다. 3 층에는 모션으로 제어되는 4 개의 형광등이 들어있는 237 평방 피트의 주방이 있어야합니다. 드롭 천장에 민감한 전등 스위치. " 오히려 건축가와 고객과의 협의를 통해 설계 서비스를 제공하고 현장 전문가 인 공급 업체를 통해 결과물을 산출하는 계약을 맺게됩니다.

세부 사항은 해당 기관 및 적용되는 조달 정책 및 법률에 따라 다르지만 대규모 정부 IT 프로젝트의 모든 실패 속에서 소프트웨어 개발을위한 공개 입찰을보다 현대적인 민첩한 방법론으로 옮기는 단체가 있음을 보여줍니다. 충분한 정치적 의지와 신뢰할 수있는 개발 파트너. 조직이 추구하는 데 관심이 있거나 없을 수있는 그러한 프로젝트를 계획하고 관리하는 방법 (프로세스 전반에 걸쳐 사용자 피드백을 제공하는 많은 지속적인 시간 포함)이 크게 변화합니다.

전형적인 소리입니다. 입찰이 작성되고 제안이 접수되고 경쟁자 중 한 명이 계약을 체결 한 경우 ... 공공 조직의 대표자에 관한 한 프로젝트가 완료됩니다.

그렇기 때문에 이러한 많은 프로젝트가 실패합니다. 예산을 초과 한 후

그들이 누락 된 점 (또는 적어도 느끼지 못하는 점은)은 회의와 데모에 참석해야하는 이해 관계자라는 점입니다.

따라서 애자일 또는 스크럼과의 충돌은 없습니다. 자신의 역할을 수행하지 않는 사람들입니다. 정부가 일하는 방식이 이것을 일으킨다.

"우리는이 시스템을 갖기를 원합니다. 우리는이 시스템에 약간의 노력을 기울이고 얼마나 멀리 갈 수 있는지 알고 싶습니다".

아닙니다. "당시 우리의 민주주의는 우리가이 제도를 갖기로 결정했습니다"와 같습니다. 한편으로는 100 % 성공과 다른 한편으로는 100 % 실패 사이에 여유가 없습니다. 처음부터 운명.

또한 어리석은 요금을 요구하는 시장에 초대합니다. 너무 비싸기 때문에 프로젝트를하지 않는 것은 옵션이 아닙니다. 입찰 결정을 내리기 전에 이미 결정을 내 렸습니다.

이해 당사자들이 자신의 역할을 맡아도 완전히 무력 할 것입니다. 그들 중 어느 누구도 같은 이유로 데모에 착수 할 수있는 확실한 입장을 가지지 않았습니다.

아니요, SCRUM은 공개 입찰과 호환되지 않습니다. 공공 입찰에서 구매하는 것을 명시 적으로 명시해야합니다.

"구매자는 5 명의 개발자와 인증 된 SCRUM 마스터 (구매자가 이해 관계자 역할을 맡게 됨)를 포함하는 숙련 된 SCRUM 팀으로부터 2 주에 걸쳐 2 주 개발 스프린트 10 개를 구매하려고합니다. 스프린트는 2018 년 3 월부터 2018 년 7 월까지 진행됩니다" 입찰의 시작. 물론 필요한 팀 기술을 나열하고 그들이 수행 할 프로젝트에 대한 아이디어를 제공해야하지만 팀을 고용하기 위해 입찰을하는 것은 완벽하게 허용됩니다.

물론 여기서는 "고정 범위"를 포기합니다. 결국 SCRUM에 일반적입니다. 입찰에서 약간 더 많은 문구를 사용하면 (여기서는 합법적 인 영역에 있음) 작은 범위 확장, 즉 소수의 추가 스프린트를 허용 할 수 있습니다. 그러나 처음 10 번의 스프린트 이후에 10 번의 스프린트를 추가로 원한다면 다시 입찰해야 할 것입니다.

가 어렵다.

당신은 분명히 개방형 예산으로 작업을 부드럽게 할 수 없습니다. 따라서 수행해야 할 작업과이를 위해 얼마나 많은 노력이 필요한지 살펴 봐야합니다.

이제 많은 소프트웨어 프로젝트가 실패하는 이유는 수정, 시간, 노력 및 범위를 미리 오류가 발생하기 쉽기 때문입니다. 예를 들어 입찰에 제공된 사양에는 거의 항상 모호성이 있습니다.

따라서 민첩성뿐만 아니라 소프트웨어 개발을위한 공개 입찰이라는 개념에도 근본적인 문제가 있습니다. 지정한 시간에 누군가 이탈하여 원하는 것을 정확하게 만들 가능성은 낮습니다.

약간의 유연성을 허용하면이를 개선 할 수 있습니다.

공공 입찰에 일을 처리하는 과정이 유연하지 않은 것처럼 들립니다. 그러나 계약이 성사되면 리글 룸이 있음을 알 수 있습니다. 예를 들어, 민첩한 작업을 허용 할 수 있지만 이것이 범위에 영향을 줄 수 있음을 수락하고 법적 허가를 받아야합니다.

이제는 초기에 무슨 일이 일어나고 있는지 확인하고 제품에 구워지기 전에 변경하기 때문에 더 나은 제품이 될 것이라고 믿습니다. 엄격한 피드백 루프와 반복적 인 개발로 실제 요구 사항에 더 잘 맞는 제품을 만들 수 있습니다 (부드럽게되었을 수도 있고 아닐 수도 있음).

그것은 가능하지만 아마도 그렇습니다.

IT 관련 프로젝트에서 정부와 함께 일한 모든 사람들이 실제로 입찰에 설명 된 '하드 한계'가 모두 충족되지 않는다는 사실을 알고 기꺼이 돈을 걸겠습니다. 예산이 초과되거나 지연되거나 범위가 변경되는 경향이 있습니다. 보통 그 중 여러 개입니다. 정부가 이것이 진실이라는 것을 기꺼이 인정하고 그들이 지침대로 취급 할 의향이 있다면, 스크럼은 실제로 잘 작동 할 수 있습니다.

개인적 경험 (나 자신과 전문 네트워크 모두)에서 나는 대부분의 정부 프로젝트에서 요구 사항이 자주 바뀌는 것을 알고 있습니다. 책임위원회는 또한 프로젝트의 마지막에 참여할 때 많은 피드백을받는 경향이 있습니다. 이러한 문제는 스크럼이 적합합니다.

그러나 정부와 기관의 사고 방식에 근본적인 변화가 필요하다. 대부분의 국가에서 이러한 변화가 일어날 가능성 은 매우 낮습니다. 그때까지 공개 입찰은 스크럼과의 작업에 계속 호환되지 않습니다. (그 문제를 들어, 내 개인적인 의견으로는 공공 입찰은과 호환이 될 것 어떤 ... 지속 가능한 소프트웨어 개발 관행,하지만 다른 시간에 대한 또 다른 문제이다)

이 조직에 무엇을 추천 하시겠습니까?

이 시점에서 아무것도 없습니다.

여기서 부족한 것은 현재 프로세스로 인해 어떤 문제가 발생했는지에 대한 이야기입니다. 스크럼은 맹목적으로 추천 할 것이 아닙니다. 요점이 있습니다. 모두 맞는 크기는 아닙니다.

현재 프로세스로 인해 어떤 문제가 발생했는지 물어보십시오. 들리다. 실제 문제를 해결하는 방법 만 권장하십시오. 그들은 현재 프로세스에 편향 될 것입니다. 틴더는 개발 프로세스를 지시하는 것처럼 보이지만 그렇지 않습니다. 그들은 배달 과정을 지시합니다. 그러나 그것은이 팀이 전에는 결코 할 수 없었던 차이입니다.

애자일은 프로젝트 수명 기간 동안 요구 사항이 3 % 이상 변경 될 때 가장 잘 작동합니다. 그렇지 않으면 폭포는 여전히 매우 효과적입니다. 오늘날에도 많은 곳에서 사용되고 있습니다. 물론 많은 성공적인 개발자는 프로세스를 공식화하지 않습니다. 비공식적 인 문제는 사람들이 아닌 어려운 문제가 기술적 일 때 효과적입니다.

따라서 현재 프로세스와 문제에 대해 이야기하십시오. 이들 방법이 어떤 도움을 주는지 알려주십시오. 그러나 그것이 깨지지 않으면 고치지 마십시오.