1
플랫폼 개발에 민첩한 작업을 할 수 있습니까? 플랫폼의 고유 한 기능 영역을 담당하는 일련의 개발 포드를 그림으로 그립니다. 이제 2 ~ 4 명의 앱 개발 팀이 플랫폼을 사용하여 대중에게 소프트웨어 앱을 제작합니다. 이 시나리오에서 어떻게 민첩한 작업을합니까?플랫폼 개발을위한 민첩한 작업을 수행 할 수 있습니까?
A
답변
1
저는 이것이 민첩성을 정의하는 방법에 달려 있다고 생각합니다. Agile은 일련의 방법론과 관행을 포괄하는 용어입니다.
는 Wikipedia에서는이 같은 정의 :
민첩한 방법은 일반적으로 자주 검사 과 적응, 팀워크, 자기 조직을 장려하는 리더십 철학을 장려하는 훈련 프로젝트 관리 프로세스 을 촉진 책임 성 [...].
우리는 아키텍처 팀이 매우 구체적이지 않은 민첩한 방식으로 작동하고 기능 팀이 스크럼을 사용하는 방식으로 애자일 방식으로 접근합니다. 지정하지 않으면 프로세스가 어떻게 적용되는지에 대한 엄격한 규칙은 없지만 여러 가지 민첩한 원칙을 사용한다는 의미입니다. 가장 중요한 개발은 폭포수 방식이 아니라 반복적으로 수행됩니다.
핵심 소프트웨어 개발 부서 전체에서 우리는 지속적인 통합과 많은 자동화 된 테스트를 사용합니다. 매일의 스탠드 업은 정의에 따라 기능 팀에서 사용하는 방식이지만 때로는 플랫폼 팀에서 상황에 따라 사용하는 방식입니다. 플랫폼 팀은 그들이 한 일에 대한 주간 프리젠 테이션을 진행합니다. 또한 사용자 스토리는 기능 팀에만 사용되는 것이 아니라 때로는 플랫폼 팀에게도 사용됩니다. 책임이 겹치고 제품 요구 사항이보다 일반적인 플랫폼 요구 사항으로 판명 될 때도 있습니다.
그래, 상황 (즉, 관리 및/또는 제품 요구 사항)이 허용하는 한, 플랫폼 팀에게는 민첩함이 가능하다고 생각합니다. 당신이 사용하는 것과 사용하는 방법은 당신에게 달려 있습니다.
1
애자일은 애플리케이션 개발에서 작동 할 수있는 것과 동일한 이유로 플랫폼 개발에서 작동 할 수 있으며 동일한 근본적인 이유로 두 경우 모두 실패 할 수 있습니다.
민첩한 프로세스는 정의에 따라 환경에 적응합니다. 일반적으로 프로세스를 사용하는 사람들이 그것을 적용하는 사람들이며, 적용되는 작업의 목적에 맞도록 유지됩니다. 이 적응성은 작업 환경에서 프로세스 적응성을 용인 할 수 있다면 민첩하게 프로세스를 본질적으로 견고하게 만듭니다.
플랫폼 개발에서 릴리스 일정은 응용 프로그램 개발보다 릴리스 간격이 더 멀고 안정적입니다. 언뜻보기에, 이것은 기능의 증가를 제공하는 것이 덜 유용하다는 것을 의미하며, 고객에게 유용한 기능 확장을 제공 할 때와 동일한 피드백 루프를 제공하지 않습니다. 더 자세히 살펴보면, 아무도 생산중인 기능을 기다리지 않고 있거나 모든 가치가있는 완전한 산출물 인 경우에만 해당됩니다.
한편 환경은 성공에보다 도움이됩니다. 다른 한편으로는 민첩한 프로세스를위한 필수 메커니즘 중 하나가 빠져 있습니다. 프로세스가 누락 된 메커니즘을 보완하도록 적응 될 수있는 한 - 예 : 테스터 또는 응용 프로그램 개발자가 중간 산출물을 사용하도록함으로써 - 적응 된 프로세스는 여전히 목적에 부합해야합니다.
소프트웨어 설계 및 구성 측면에서 소프트웨어 (사양 포함)는 동일한 방식으로 작성됩니다 (한 번에 한 줄씩). 같은 종류의 사람 : 소프트웨어 개발자; 동기 부여와 주의력면에서 다소 차이가없는 동일한 특성을 지닌다. 새로운 기능의 범위는 더 커질 수 있으며 목표는 장기간 일정으로 정의되지만 여전히 단계적으로 도달해야하며 마지막 단계에서 일종의 진행 상황을 반복하여 반복에 맞게 정의 할 수 있습니다 . 개발 관리자는 산출물뿐 아니라 이정표의 관점에서 생각하기 때문에 현재의 사례에서 발전한 것일 수 있습니다.
다른 팀에서 플랫폼 및 응용 프로그램 개발을 위해 사용한 스크럼 프로세스를 보았습니다. 팀은 각기 다른 요구와 프로세스에 대한 다른 이해에 따라 다양한 방식으로 프로세스를 구현하지만 주요 성공 요인은 팀 (및 그 내부의 개인)의 역량과 팀 관리의 역량입니다.