정부 프로젝트에 대한 민첩한 접근 방식에 대한 과제

이전의 민첩한 토론 여기가 무엇인지 지정하는 좋은 답변을했다 중요한 소프트웨어 개발에 애자일 방법론을 구현의 성공에. 대부분의 요점은 일반적인 조직 및 관리 문제 였지만 한 가지 요점이 걱정되며 클라이언트는 프로세스 전체에 참여해야합니다.

고객은 현실적으로 통제 할 수없는 것 중 하나입니다. 아마도 비즈니스 모델은 예를 들어, 엄격한 계약이 회사에 다음과 같은 의무가있는 정부 계약 업무에 적합합니다.

• 요청한대로 정확하게 X 기능 제공

• 기능 요청은 벽에 던져 질 것입니다. 우리가 듣고 싶지 않다고 귀찮게하지 마십시오.

• 고객의 마음에는 기능 우선 순위의 개념이 없으며 모두 중요하거나 요청하지 않았을 것입니다.

• 프로젝트는 초과 또는 마감 기한에 관계없이 Y 이상이 아닙니다.

• 모든 작업을 완벽하게 전달하기위한 절대적이고 엄격하며 최종적이며 협상 불가능한 마감일입니다.

우리는 이전에 그런 고객과 함께 일한 적이 없지만 프로젝트 비용은 너무 좋아서 지나칠 수 없습니다. 우리는이 일이 필요합니다.

내가 여기 와서 일 HARD을 애자일 개발쪽으로 이동에 내 변경 프로세스와 여기에 내가 화해하는 방법을 모르는 경우 우리의 새로운 과정에이 프로젝트에 맞 춥니 다. 필자는 개발 팀을 이끌고이 과정을 진행할 것을 믿었던 개방적인 수동 관리의 사치를 누리지 못했다. 이제 우리는이 프로젝트가 민첩한 방법. 경영진이이 길을 인도 할 것이라고 믿었고, 현재 상황이 매우 분명 해져 폭포를 요구하기 때문에 그들을 실망 시켰습니다. 지금 역 추적하면 신뢰를 잃을 까봐 두렵습니다.

여기의 답변과 같은 다른 답변 은 이러한 종류의 고객에게는 애자일이 불가능하다고 말합니다. 동의하십니까? 비슷한 상황에 처한 적이 있습니까? 애자일을 성공적으로 수행하기 위해 어떤 전략을 구현 했습니까?

가장 먼저 알아야 할 것은 민첩함과 민첩함의 차이가 있다는 것입니다. 교차 기능 팀, 적응 형 계획, 진화 / 증분 전달, 타임 박스 반복 및 린 (Lean)의 개념 도입과 같은 민첩한 기술과 특성을 느리게 구현하는 것은 Extreme Programming, Scrum 또는 Crystal을 도입하는 것과는 매우 다릅니다.

고객 참여를 명시 적으로 언급합니다. 예. 많은 애자일 방법론에는 고객의 참여가 필요하지만 민첩 할 필요는 없습니다. 모든 정부 / 방어 관련 프로그램에는 항상 고객과 접촉하는 프로그램이나 프로젝트 관리자가있었습니다. 이 사람은 「고객의 소리」가됩니다. 전화 회의 나 이메일 또는 전화를 걸고 명확하게하면 속도가 느려질 수 있지만 팀의 고객 담당자 인 한 사람 (또는 PM이있는 경우 그룹)도 가질 수 있습니다. 틀림없이, 그것은 동일하지 않습니다. 그러나 유연하고 변화에 대응하는 것이 민첩하지 않습니까?

또한 몇 가지 주요 개념 : 사전 정의 된 요구 사항, 기능 요청이 "벽을 넘어 설", "모두 중요"하기 때문에 우선 순위 부족, 고정 비용 및 / 또는 고정 일정 프로젝트 등이 언급됩니다. 이들 각각은 다른 방식으로 해결 될 수 있습니다.

모든 요구 사항이 사전에 있다고 생각되면 그렇지 않을 수 있습니다. 요구 사항이 변경됩니다. "완료 및 사인 오프"사양이 있다고해서 반드시 스톤으로 설정되어있는 것은 아닙니다. 요구 사항 문서가 무엇이든간에 계약에 지정된 방식으로 편안하고 /하거나 기분이 좋은 방식으로 캡처하고 요구 사항, 디자인 및 아키텍처를 제공하십시오. 또한, 당신이 이것들을 살아있는 문서로 취급 할 수 있는지 확인하십시오. 주어진 반복에서 얼마나 많은 TBD로 떠날 수 있는지 그리고 지금 얼마나 많은 것들을 정리해야하는지 묻습니다.

문서에 민첩하게 대응하십시오. "팀이 원하는 것"과 "고객이 원하는 것"사이에 노력을 중복하지 마십시오. 예를 들어 고객이 전통적인 소프트웨어 요구 사항 사양을 원하고 팀에서 사용자 스토리를 사용하려는 경우 기존 SRS에 적응하고 사용자 스토리 대신 액션 항목 및 롤링 액션 항목 목록을 사용하여 시간을 소비하지 않도록하십시오 "시스템은 ..."과 ""때문에 "공식화 할 수 있어야합니다." 그러나 팀 간의 차이에 적응하기 위해서는 팀 측에서 훈련이 필요합니다. 반사 문제를 포착하십시오.

일단 개발에 도달하면 5 회 또는 6 회 반복을 실행 한 다음 고객을 시설에 초대하여 구현의 서브 세트를 볼 수 있습니다. 이 과정을 헹구고 반복하십시오. 일부 방법론에서 요구하는 지속적인 참여는 아니지만 가시성이 높다는 장점이 있습니다. 고객이 거절하면 최소한 시도한 것입니다. 그들이 '예'라고 대답하면 민첩하게 할 수 있습니다. 제가 한 프로젝트에서 고객은 몇 개월마다 (보통 3-5 개월) 사이트를 방문했습니다. 그들은 우리가 QA 테스트를 거치는 것을보고 엔지니어와 문제를 논의하고 프로그램 / 프로젝트 사무실과 비즈니스를 논의 할 것입니다. 모두가 같은 페이지에 올 수있는 기회였습니다.

테스트 및 유지 관리는 다른 애자일 프로젝트와 동일하게 수행됩니다. 적절한 방법으로 테스트 절차를 작성하고 결함을 문서화하고 계약 의무 별 메트릭을 추적하며 테스트 결과를 문서화하십시오. TDD를 따르고 싶다면 가십시오. 지속적인 통합은 또 다른 좋은 아이디어입니다. 프로젝트 상태 회의 중에 프로젝트 관리자는이 정보를 사용하여 "N 요구 사항을 구현하고 M 테스트를 받았으며 X 테스트를 통과했습니다"라고 말하고 돈을 가진 사람들에게 프로젝트 상태 및 상태를 업데이트 할 수 있습니다.

돈에 관해서는 고정 비용 및 / 또는 고정 일정 문제가 있습니다.

고정 된 일정을 다루는 것은 매우 간단합니다. 요구 사항이 주어지면 완료 할 수있는 반복 횟수를 알 수 있습니다. 각 반복에 대한 워크로드는 구현, 테스트 및 통합 할 기능 측면에서 매우 중요합니다. 어려울 수도 있지만 기능을 미리 분리하여 반복에 할당하는 것은 불가능하지 않습니다. 이것은 고객 초대에 관한 요점으로 돌아갑니다. 1 년이 있고 2 주 반복을 사용하는 경우 고객을 분기별로 초대하고 분기마다 초대하고 이전 작업의 결과를 보여줄 수 있습니다. 고객에게 요구 사항의 우선 순위 지정, 향후 계획 및 예약 방법에 대해 알려주십시오.

고정 예산을 다루는 것도 비슷합니다. 당신은 당신이 가진 시간, 프로젝트에 필요한 자원의 수, 비용, 그리고 반복 당 모두가 몇 시간을 일할 수 있는지 알고 있습니다. 모든 사람이 이것을주의 깊게 추적하도록하는 것입니다. 회사에서 초과 근무 비용을 먹을 수 있다면 그렇게하십시오. 그렇지 않으면, 모든 사람이 적절한 시간 동안 일하도록하고 좋은 시간 관리 기술과 시간 복싱을 사용하여 모든 사람의 생산성을 유지하십시오. 보다 생산적인 시간은 비용을 낮추는 데 필요한 것입니다. 회의 및 오버 헤드 비용없이 더 많은 부가 가치 문서와 소프트웨어를 제공하십시오.

궁극적으로 반드시 애자일이 아니라 애자일을 좋게 만들고 민첩하게 만드는 것들을 적용하는 것입니다. 요구 사항의 변화에 ​​대응하고, 고객이 원하지 않더라도 빈번한 소프트웨어를 제공 할 수 있으며, (부가 계약에 따라 생성해야하는 내용과 함께) 부가 가치 문서 만 작성하는 등의 작업을 수행합니다.

그렇습니다. 민첩한 요구 사항은 이미 고가의 컨설턴트,위원회 회의 및 정치적 타협에 의한 수년간의 분석의 결과로 이미 완료되고 고정 된 것처럼 들리기 때문에 그러한 프로젝트에는 적합하지 않습니다. 고객이 너무 잘 훈련되어 고객이 원하는 것을 정확하게 서면으로 알려줄 수 있으면 Waterfall이 제대로 작동합니다. 그것들은 틀렸을 수도 있지만 적어도 당신은 그것을 서면으로 가지고 있으며 그것을 전달하면 돈을 받게 될 것입니다. (이것은 물론 고객 만족도를 말해주지 않습니다. 실제로 필요하지 않은 것을 제공 할 가능성이 있습니다.)

애자일은 요구 사항의 불확실성으로 인한 위험으로 인해 발생하지 않는 문제를 해결하기 위해 만들어졌습니다.

고객이 변경 요청을 할 수도 있지만 다음 두 가지 경로 중 하나를 따르십시오.

1. 돈은 너무 좋았으므로 프로젝트의 여러 단계에서 X 량의 새로운 기능을 흡수하고 셔츠를 잃지 않고 나올 수 있습니다.
2. 고객은 가격을 협상하기 때문에 각 새로운 기능 요청이 구매 주문서와 함께 고객이 승인해야하는 가격으로 변경 주문을 생성한다는 점을 고객에게 분명히 밝힙니다. 구현하기 위해 원래 구매 주문). 변경 순서는 기능 또는 일정에 영향을 미칩니다. 마감일을 옮길 수 없다고하면 프로젝트가 진행됨에 따라 변경 주문이 기하 급수적으로 비싸 질 수 있습니다.

관계는 상황 # 1에서 훨씬 친숙하게 느껴지지만 사실 가격을 압박하지 않는 구매 부서를 찾는 것은 매우 드물기 때문에 대부분의 경우 상황 # 2에 있습니다. 그것은 관계가 대립적이라는 것을 의미하지만, 비즈니스에서 살아남 으려면 관계를 잘 유지하면서 관계를 잘 관리해야합니다. 이것은 프로젝트 관리자 업무의 큰 부분입니다.

상황 1에있을 것 같습니다. 나는 정부 계약이 결국, 그들은 지출하지 않을 때문에, 그들은 돈에 대해 걱정하지 않는 유일한 장소 상상 그 돈을 그들이 지출하고 당신의 돈입니다.

... 예를 들어, 엄격한 계약이 회사에 다음과 같은 의무를 부과하는 경우 정부 계약 작업.

먼저. 엄격합니다. 그러나 융통성이 없습니다. 세부 사항과 길고 긴 변경 순서에주의를 기울여야합니다.

정부 기관은 실제로 느리고 비효율적 인 방식으로 민첩합니다. 공식적이고 세부적인 변경 명령을 항상 작성하고 협상해야합니다.

요청한대로 정확하게 X 기능 제공

변경 순서에 의해 수정 될 때까지.

기능 요청은 벽에 던져 질 것입니다. 우리가 듣고 싶지 않다고 귀찮게하지 마십시오.

커뮤니케이션 채널은 변경 순서입니다. 예산 및 일정 영향.

고객의 마음에는 기능 우선 순위의 개념이 없으며 모두 중요하거나 요청하지 않았을 것입니다.

해결하기가 어렵습니다. "요구 사항 분석"을 위해 많은 비용을 지출하는 비정부 사업체조차도 우선 순위와 트레이드 오프 정보에 의해 방해받지 않고 크고 평평하며, 급증하는 요구 사항이 불완전하다는 말을 원하지 않습니다. 그들은 모든 요구 사항 을 얻기 위해 좋은 돈을 지불했습니다 . 더 자세한 정보를 어떻게 원하십니까?

이것은 어려운 문제입니다.

프로젝트는 초과 또는 마감 기한에 관계없이 Y 이상이 아닙니다.

변경 주문을 제외하고. Y와 마감일을 수정합니다.

모든 작업을 완벽하게 전달하기위한 절대적이고 엄격하며 최종적이며 협상 불가능한 마감일입니다.

"협상 불가능"은 일반적으로 사실이 아닙니다. 협상이 가능합니다. 협상하는 것은 고통 스럽습니다.

정부 기관과의 협상에서 중요한 부분은 비용 및 일정 변경에 "변호사 수준의 증거"가 필요하다는 사실입니다. 멋진 파워 포인트 슬라이드를 사용한 몇 가지 신중한 기술 프레젠테이션은 "증거"가 아닙니다. 사례를 작성하려면 많은 문서가 필요합니다.

정부는이를 ​​가능한 한 저렴하고 효과적으로 만들기 위해 모든 힘을 다했다는 확실한 증거를 제공해야합니다. 그들은 모든 결정이 공공 언론에서 재생되고 뒤늦게 감시되고 있음을 알고 있습니다.

정부 업무의 소프트웨어 개발의 복잡성과 사실상 "월요일 아침 쿼터백"측면은 압도적 인 증거없이 계약을 변경 하는 것을 꺼려 합니다.

적절한 민첩한 접근 방식을 어렵게 만듭니다.

"프로세스와 도구에 대한 개인과 상호 작용"은 매우 어렵습니다. 당신은 개인과 함께 일하고 있지 않지만, 일을하는 정부의 대표자는 프로세스에 의해 제약을받습니다.

이와 같은 프로젝트에서 그들은 범위, 자원 및 시간에 손을 묶었습니다. 관리해야 할 것은 품질뿐입니다. 그래서...

그렇지 않으면 민첩한 접근 방식을 통해 대부분의 이점을 얻을 수는 없지만 품질 위험을 완화하고 고객에게 나중에 문제를 알리기 위해 최선을 다할 수 있습니다.

따라서 최대한 민첩해야합니다.

1. 요구 사항을 살펴보고 기술 위험에 대해 가장 우선 순위를 정하십시오. 우선 순위가 지정된 요구 사항을 백 로그로 설정하십시오.
2. 스프린트의 백 로그를 통해 스프린트의 기능을 디자인, 테스트 및 코딩하십시오. 클라이언트 상호 작용이 누락되었으므로 요구 사항 문서가이 활동에 대한 클라이언트를 나타내야합니다.
3. 각 스프린트 리뷰에 고객을 초대합니다. 거절 할 수도 있지만 예라고 말할 수도 있습니다. 그리고 나중에보다 빨리 피드백을받을 수 있습니다.

마감 기한을 지키기 시작하면 완료된 작업을 보여줄 수 있으며, 그 시점에서 클라이언트가 모든 것을 얻지 못할 것이라는 것을 알면 우선 자신이 원하는 것을 말할 수있을만큼 우선 순위가 높아집니다. 가장 위험한 작업도 수행해야합니다. 즉, 마감 시간의 작업이 추가 작업 시간에 가장 쉬운 일임을 의미합니다.

이런 종류의 고객은 일반적인 것이 아니라고 생각합니다. 이전에 비슷한 프로젝트를 요청한 그룹을 다루므로 원하는 것을 정확히 알고 있습니다. 사양이 변경 될 것이라고 언급 한 적이 없습니다.

요청한대로 정확하게 X 기능 제공

내가 제안한대로 X 기능을 모호하게 제공하고 즉시 통지 할 때 준비가되면 운이 좋습니다.

기능 요청은 벽에 던져 질 것입니다. 우리가 듣고 싶지 않다고 귀찮게하지 마십시오.

그들이 원하는 것을 알고 있다면 가서 빌드하십시오.

고객의 마음에는 기능 우선 순위의 개념이 없으며 모두 중요하거나 요청하지 않았을 것입니다.

당신은 이것을 잃을 수 없습니다. 적합하다고 생각되는대로 빌드하십시오.

프로젝트는 초과 또는 마감 기한에 관계없이 Y 이상이 아닙니다. 모든 작업을 완벽하게 전달하기위한 절대적이고 엄격하며 최종적이며 협상 불가능한 마감일입니다.

정부를위한 프로젝트를 만든 적이 없다면 힘든 일입니다. 역사가 있다면 배달 할 수 있는지 판단 할 수 있습니다. 그렇다고해서 돈을 잘 지불하지 않거나 (10 달러 망치로 50 달러를 지불 한 것으로 악명이 높다) 또는 예상치 못한 기대치가있는 것은 아닙니다. 이러한 사양을 사용하면 팀의 누군가가 고객 역할을하고 사양과 비교하여 작업을 승인해야합니다. 결함을 발견하고 요구 사항을 변경하도록 간청하더라도 아마 그렇지 않을 것입니다.

안타깝게도 소프트웨어 프로젝트를 어떻게 다루어야하는지에 대한 일반적인 고객의 견해입니다. 고객이 불합리하다고 말하는 것은 아닙니다. 결국-이것이 다른 건물 (예를 들어 집)을 어떻게 실행할 것인가? 그럼에도 불구하고, 나는 우리 모두가 이미 알고있는 것 이상을 제공하지 않습니다. 당신이 요구하는 것은 ...이 상황에서 민첩한 관행을 적용 할 수 있습니까?

나는 당신이 묘사하는 상황과 많은 측면에서 유사한 프로젝트를 막 끝냈다는 이점이 있습니다.

1. 고정 된 (돌에서, 지옥이나 높은 물) 마감 시한.
2. 기능 요구 사항 문서 ( "성경"). 의외로 부적당하다.
3. 전통적인 역할 : 비즈니스 분석가, 프로젝트 관리자.
4. 약혼 한 비즈니스 사용자 ( "제품 스폰서 없음"이라고 말할 수 있습니까?).

... 물론 미래 지향적 인 개발 팀은 위의 사항에도 불구하고 민첩한 방식으로 작업하려고합니다.

1. 2 주 반복;
2. 스탠드 업;
3. 회고전;
4. 페어 프로그래밍;
5. TDD;
6. 지속적인 통합.

이 중 원격으로 비즈니스에 의미가 있습니까? 마감일까지 두 달이 지났는데, 그 때까지 반복적으로주의 깊게 관찰 된 반복과 계획 회의는 머리없는 닭염에 시달렸습니다.

다른 사람들이 위에서 제공 한 답변은 다소 타협합니다. 제 생각에는 애자일 ( "애자일"또는 "애자일")은 우리가 타협 할 때 악의적 인 방식으로 "완료"됩니다. 내 의견으로는 :

타협이 없거나 민첩하지 않습니다.

민첩성의 정신은 체이스를 자르고 폐기물을 제거하며 잔인하게 자신에게 정직하는 것입니다. 이제 대규모 프로젝트에 대한 소프트웨어 평가가 최고라는 사실은 잘 문서화되고 부인할 수없는 사실입니다. 이것에 대한 잠재 고객을 교육하는 것은 소프트웨어 전문가로서 우리의 의무가 아닌가? 고객이 우리가 전문가라는 사실을 받아들이 려하지 않는다면, 떠나는 것이 우리의 전문적인 의무가 아닙니까?

내가 지금있는 곳에서 일을 시작했을 때, 나는 당신이 상당히 많이 요구했던 것과 같은 질문을하는 것을 스스로 발견했습니다. 정부 계약으로 폭포에 대해 언급해야 할 것이 있습니다. 아이러니하게도 민첩성은 이제 폭포수 방식으로 현실적으로 일하는 정부 고객 과의 화두가 되었으므로 이제는 기본적으로 융통성이없는 고객으로 민첩한 프로세스를 구현하기 위해 더욱 열심히 노력하고 있습니다.

우리는 "Scrummerfall" "Agilefall"또는 "A mess"로 기술 된 시스템을 가지고 있지만, 여러 측면에서이 프로젝트 (gargantuan) 프로젝트가 수년에 걸쳐 진행되면서 점점 더 민첩한 프로세스를 채택 할 수있었습니다. . 우리가 한 방법 중 하나는 기본적으로 고객과 달리 시스템 사용자와 의사 소통 채널을 찾는 것입니다. 고객은 업무상 소프트웨어를 건드리지 않고 이해하기를 원하지 않는 임명 된 관리가 이끄는 답답한 부서입니다. 우리의 사용자는 중요한 업무를 수행하려고하는 현장의 정규 정부 요원입니다. 우리에게있어 통신 피드백 루프를 설정하는 열쇠는 우리처럼 민첩하게 만들 수 있었기 때문에 UAT (User Acceptance Testing)의 필요성이었습니다.

우리 프로젝트의 초기 단계에서, 광대 한 정부 고객의 여러 사무실에서 온 실제 사용자 그룹이 여기 위치에 모이고 일련의 작업을 진행할 때 몇 주 동안의 얼굴을 가질 것이라고 결정되었습니다. 소프트웨어 테스트를위한 스크립트 테스트 비공식적 인 것만 큼, 요구 사항 팀은이 시간을 실제 최종 사용자로부터 피드백을 얻는 귀중한 방법으로 전환했습니다. 한편 정부의 UAT 테스트 팀은 관료주의를 통해 변경 명령을 포함하여 최종 요구 사항 프로세스에 더 많은 영향을 미쳤습니다. 최종 결과는 나 자신과 같은 BA가 스크럼 팀에 내장 된 독립형 제품 소유자의 역할을하며 매우 민첩한 방식으로 기능 할 수있는 실제 고객과 귀중한 대면 시간을 가질 수 있다는 것입니다.

물론, 많은 문제가있다, 우리는 아직없는 정말 민첩하지만 우리는 실제로 정부 계약 분야에서 그 방법론을 사용하여 중요한 민첩한 프로젝트의 예로서 개최 된 것으로 민첩 충분합니다.

요약하자면 : 조직 내 민첩한 전도사로서의 경험을 사용하여 고객에게 침투하십시오. 그들과 함께 학습 프로세스를 진행하고, 주요 직원들과 신뢰를 바탕으로 파트너십을 구축하고, 필연적으로 자리 잡은 공식적이고 체계화 된 요구 사항 프로세스를 진행합니다. 개발중인 것을 실제로 사용해야하는 사람들에게 감사를 표할 것입니다!

요구 사항이 잘 작성되었다고 가정하고 요구 사항이 의미하는 바를 의미한다고 생각합니다. 민첩한 프로세스의 앞뒤로 그들이 요청한 것 외에도 그들이 원하는 것을 얻도록 도울 것입니다.