새로운 컴파일러 백엔드를 구현할 때 Scrum이 의미가 있습니까?

새로운 플랫폼으로 이식해야하는 기존 언어가 있습니다. 기존 컴파일러의 백엔드를 변경하여 시도 할 것입니다.

백엔드를 다시 작성하는 것은 상당한 양의 작업입니다. INVEST 기준을 위반하지 않고 이것을 합리적인 이야기로 나누는 방법을 볼 수 없습니다.

각 스토리가 어떻게 협상 가능한지 알 수 없습니다. 모두 작동하는 컴파일러에 필요합니다. 이야기는 우선 순위가 동일하며 어떤 순서로 전달하든 상관 없습니다. 나는 그들 모두를해야합니다.

내가 구현하고있는 소프트웨어의 일부는 다른 것보다 우선 순위가 낮으며 점진적으로 제공 할 수 있음을 알 수 있습니다. 그러나 머스트 해브 (Must Have )라는 중요한 핵심 이 있습니다.

나는 스크럼을 따르려고 노력하고 있지만 방금 움직임을 겪고 있습니까?

이런 종류의 프로젝트에 권장되는 관행이 있습니까?

애자일 프로세스가 만들어진 주된 이유는 변화하는 요구 사항에 대처하기위한 것입니다. 요구 사항이 완전히 정립 된 경우 (정확하게 고정 된 요구 사항은 드물지만 여기서 귀하의 말을하겠습니다!) 변화하는 요구 사항 (예 : 협상 가능한 사례)을 처리하기위한 모범 사례 중 일부는 다소 관련이 없습니다. 그러나 스크럼 워크 플로를 따르는 것은 여전히 ​​일정을 세우고 결과물을 제공하는 측면에서 많은 잠재적 가치를 지니고 있습니다. 결과물이 한동안 완전히 사용 가능한 제품이 아니더라도 고객 (및 팀)에게 진전을 보여줄 수 있다고 할 말이 있습니다.

"필수"스토리는 "플랫폼 X에서 컴파일 할 수 있어야한다"라는 하나의 서사시를 구성한다고 생각하십시오. 이 경우 사용자에게 가치를 전달하기 전에 전체 서사시를 완료해야하지만 대규모 프로젝트를 시작할 때 종종 그렇습니다. 스토리를 시작하여 가능한 가장 간단한 프로그램을 컴파일 한 다음 더 많은 언어 기능을 지원하기 위해 스토리를 더 만듭니다.

무엇보다도 모든 상황을 고도로 일반화 된 접근 방식에 맞추도록 강요하지 마십시오. 애자일은 당신을 위해 일해야합니다.

물론 스크럼이 유용합니다. 두 가지 일을하는 방법론입니다.

1. 프로젝트가 변화에 적응하고
2. 진행 상황을 추적하고 완료 시점에 대한 아이디어를 얻을 수 있습니다.

따라서 그것을 사용하는 데 가치가 있습니다.

나는 당신의 전제 조건 중 일부가 정확하지 않다고 생각합니다.

각 스토리가 어떻게 협상 가능한지 알 수 없습니다. 모두 작동하는 컴파일러에 필요합니다.

사실이 아닙니다. 언어의 하위 집합을 지원할 수 있으며 특정 조건에서 작동하는 컴파일러를 계속 사용할 수 있습니다. 완전한 컴파일러보다 가치가 낮지 만 여전히 가치가 있습니다.

또한 "협상 가능"이 의미하는 바를 오해합니다. 반드시 "선택적"을 의미하는 것은 아니며 INVEST에서 스토리가 선택적 일 필요는 없습니다. 이야기는 귀중한 목표이며 협상은 그 목표에 도달하는 방법에 관한 것입니다. 분명히 각 언어 기능의 백엔드를 구현하는 방법 이상이있을 것입니다. 협상이 필요한 곳이 있습니다.

이야기는 우선 순위가 동일하며 어떤 순서로 전달하든 상관 없습니다.

아래에서 말하는 것처럼 일부 스토리는 "필수"가 아니므로 일부는 덜 가치가 있습니다. 그러나 "필수 항목"범주에서도 일부 언어 기능은 다른 언어 기능보다 훨씬 더 기본적이고 측정 가능합니다.

이를 측정하는 한 가지 방법은 미리 정의 된 테스트 스위트가있는 경우 "기존 코드베이스에서 더 많은 코드 라인을 컴파일 할 수있는 방법"또는 "더 많은 테스트를 통과하는 방법"입니다.

다른 옵션도 있습니다. 당신이하는 C와 같은 언어를 컴파일 엄밀히 말하면 한 경우에만 필요 if하고 gotoA (거의) 기능 언어를 가지고 당신이 구현할 수있는 루프를 while, for그리고 repeat매크로로. 프리 컴파일러를 사용하는 것이 쉽다고 가정하면 저렴한 스톱 갭 솔루션을 사용할 수 있습니다 (이봐, 우리는 협상 중입니까? :-)

적응성과 관련하여 언어 지원은 상당히 정적 인 요구 사항이지만 언어도 변경되며 요구 사항에 대한 지식 도 변경됩니다. 모든 것을 구현해야합니까? 당신의 목표를 위해 특별히 필요하지 않은 것들이 있습니까? 애자일의 기본 테넌트 중 하나는 불완전한 지식을 보유하고 있다는 지식입니다. 활용할 수 있습니까?

결론적으로, 질문에보다 직접적으로 대답하려면 요구 사항을 변경할 수 없을 때 민첩한 프로세스가 필요합니까? 기필코 아니다! 사용할 수 있습니까? 아마 그렇습니다! 그들은 당신의 시간 가치가 있습니까? 아마도 그렇지는 않지만 요구 사항은 변경되지 않습니까? 과거의 경험에서 "변경 불가능한 요구 사항"=> "게으른 제품 소유자"-규칙은 아니지만 명심할 가치가 있습니다.

TL; DR

모든 프로젝트 관리 컨트롤은 오버 헤드를 추가합니다. 필요없는 오버 헤드를 추가하지 마십시오.

스크럼은 여기서 잘못된 망치입니다 (손톱이 아님).

스크럼은 개별 개발자에게 적합한 일련의 개발 관행이 아니라 프로젝트 관리 프레임 워크 입니다. 프로젝트 관리를하지 않는 한, Scrum은 잘못된 선택 일 것입니다.

또한 말할 때 :

이야기는 우선 순위가 동일하며 어떤 순서로 전달하든 상관 없습니다. 나는 그들 모두를해야합니다.

몇 가지를 암시합니다.

1. 모든 스토리가 100 % 완료되지 않으면 프로젝트의 가치가 없습니다.
2. 이야기는 서로 의존하지 않습니다.

이 두 진술이 모두 사실이라면, 가치 나 의존성 순서에 따라 작업의 우선 순위를 정하도록 설계된 프레임 워크 나 관행을 사용하는 데 아무런 의미가 없습니다.

제안 된 대안

모든 개발 프로젝트는 몇 가지 민첩한 관행으로부터 혜택을 볼 수 있습니다. 특히, 특정한 경우에는 다음을 권장합니다.

1. 모든 스토리에 단위 테스트 및 합격 테스트가 포함 된 "완료된 정의"가 있는지 확인하십시오.
2. 자주 통합하고 리팩터링하십시오. 프로젝트가 끝날 때 거대한 통합 작업을 수행하지 마십시오.

또한 모든 이야기가 완료되지 않으면 제품의 가치가 실제로 0이더라도 이야기를 완성 된 이정표로 취급 할 수있는 주제로 그룹화하는 데 시간을 할애합니다. "나는 foo 기능을 완료했습니다"라고 말할 수있는 것은 "23/117 개의 임의의 스토리를 완료했습니다"라고 말하는 것보다 더 유용합니다. YMMV.

귀하의 우려를 이해하지만 스크럼을 사용하는 데 여전히 가치가 있다고 생각합니다.

물론, 사용자 스토리는 소비자 용 애플리케이션보다 훨씬 더 고정되어 있습니다. 따라서 스크럼의 측면은 더 적은 가치를 제공 할 것입니다.

당신이 가치를 얻을 것이라고 생각하는 곳은 반복적이고 빈번한 릴리스 입니다. 모든 스프린트가 끝날 때 잠재적으로 출시 가능한 제품을 보유하면 코드 품질을 높이고 기술 부채를 낮게 유지할 수 있습니다. 결함을 조기에 발견하는 좋은 방법이기도합니다.

속도 를 아는 것도 도움이 될 것 같습니다 . 몇 번의 스프린트 후 팀이 각 스프린트를 완료하는 데 얼마나 많은 노력이 필요한지 확인할 수 있습니다. 이를 통해 배송 날짜를 결정하는 데 도움이되는 객관적인 지표가 제공됩니다.

무엇보다도 민첩성이 형용사 라는 것을 기억하십시오 . 모든 스프린트가 끝나면 회고 회의를 열고 필요에 따라 프로세스를 조정해야합니다. 컴파일러 개발에 적용되지 않는 스크럼 프로세스의 일부가 있으면 제거하십시오. 도움이 될 다른 프로세스 요소가 있으면 추가하십시오. 내 의견으로는 민첩성의 가장 중요한 부분은 프로세스를 인식하고 특정 상황에 맞게 지속적으로 개선하는 것입니다.

(컴파일러 프로젝트에서 스크럼을 수행 한 적이 없습니다. 소금 한알로 조언을 구하십시오.)

그렇습니다. 스크럼이 따라야 할 엄격한 규칙 세트가 아니라는 것을 기억한다면 가능합니다. 프로젝트에 맞게 조정할 수 있습니다. 스프린트, 스탠드 업, 매주 스크럼은 팀 구성원 간의 커뮤니케이션을 향상시키고 프로젝트가 의도 한 방향으로 계속 진행되도록하는 데 여전히 유용합니다.

모든 스토리의 우선 순위는 같지만 구현하기가 상대적으로 어렵다는 점을 고려해야합니다. 프로젝트가 끝날 때까지 가장 어려운 아이템을 유지하고 싶지 않습니다. 가능한 빨리 작업을 시작하고 싶을 것입니다.