한 팀에서 디자인하고 다른 팀에서 코딩

모든 소프트웨어 디자인이 현지 팀에 의해 만들어지고 코딩을 위해 해외 팀으로 보내지는 프로젝트에 참여하게됩니다.

이 특성을 가진 프로젝트에 처음으로 직면 한 것은 저에게 이상하게 느껴집니다. 관리자는 우리가 매우 자세한 디자인 문서를 작성해야하므로 오프 쇼어 팀에게는 오류의 여지가 없습니다. 내 관점에서 그들은 종이로 코딩하고 IDE에서 할 수 있습니다.

그래서 내 질문은이 접근법이 좋거나 입증 된 것입니까? 소프트웨어 프로세스가 프로젝트에서 성공해야 할 주요 고려 사항은 무엇입니까?

내 의견 :

해외 사람들에게 문서와 도표 만 제공한다면, 많은 의사 소통과 실망이있을 것 입니다.

내 추천

• 그들에게 너무 많은 문서가 아니라 포기하지 마십시오 인터페이스와 추상 클래스를 위해 설계 목표로 그들을 답답한 .

• 알려진 명명 표준을 사용해야합니다.

• 그들이 단위 테스트를 사용하도록 요구하십시오.

• 프로세스를 감독하기 위해 설계자 / 건축가 중 한 곳을 구내로 보내면 사내 코딩보다 비용이 저렴하지만 더 나은 결과를 얻을 수 있습니다.

폭포라고도 불리는 Big Design Up Front라고합니다. 매우 성공적인 방법론으로 널리 간주되지 않습니다. 그러나 나는 그것이 작동하는 것을 보았고 그것이 작동하면 매우 잘 작동합니다. 올바르게하는 것은 매우 비싸다.

고용주가 요청한 내용이기도합니다.

해외 팀은 육상 팀과 달리 작동하지 않습니다. 정확히 원하는 것을 매우 구체적으로 지정해야합니다. 그렇지 않으면 원하는 것을 얻을 수 없습니다.

마지막 프로젝트는 소프트웨어 디자이너였습니다. 모든 개발은 해외였다. 우리는 성공했다. 따라서이 과정이 효과가 있습니다.

나는 많은 문서를 만들었지 만 결코 포괄적이지 않고 단계별 지침이나 클래스 이름, 함수 이름 등을 자세히 설명하지는 않았습니다. 예를 들어 시퀀스 다이어그램, 사용 사례, 워크 플로, 시스템 및 통합을 생성했습니다. 그림과 필요한 세부 설계 문서

실제로 해외 개발을 얼마나 신뢰하는지에 달려 있습니다. 저는 해외 팀이 유능한 개발자가 될 것을 믿습니다. 즉, 전반적인 방향을 제시했지만 해외 팀이 유쾌하게 만족하는 것을 구현할 수있는 여지를 주었다. 과거에는 더 미세하게 관리되었습니다. 특정 상황에서는 필요에 따라 디자인 패턴을 사용하여 안내합니다. 또한 정기적으로 작성한 코드에 대한 코드 검토 및 분석을 수행했으며 리팩토링 또는 정리 작업을 권고합니다. 또한 일부 팀은 오락 용 차량으로 사고를 당했기 때문에 구현 중 일부 스토리를 코딩하여 리소스가 부족해졌습니다.

또한이 프로세스는 프로젝트에 대한 기술 리드의 강점과 비즈니스, 디자이너, 리드 및 개발자 간의 커뮤니케이션에서만 성공할 수 있다고 생각합니다. 우리는 각 기능과 스토리에 대해 많은 시간을 보냈으며 해외 리드 / 리소스가 요구 사항에 정통한지 확인했습니다. 기능 / 스토리를 검토하는 동안 질문을하지 않으면 몇 가지 문제가 예상됩니다. 또한 업무 승인이있을 때까지 작업이 완료된 것으로 간주되지 않았습니다. 따라서 민첩한 개발을 관리하는 도구에서 모든 것이 추적되므로 모든 사람이 책임을지게되었습니다.

다른 답변 중 하나가 이미 언급했듯이 개발 프로세스에는 명명 표준 (내장 된 규칙이 더 명확함), 테스트 케이스 적용 범위 (TDD, Mocking 등 사용)가 포함되어 있으므로 코딩 프로세스와 절차가 적절하면 증가합니다. 성공적인 프로젝트를위한 기회.

해외 개발의 주요 비용은 커뮤니케이션입니다. 문서화는 의사 소통의 한 방법이지만 문서가 모든 세부 사항과 잠재적 인 변경 사항을 다룰 수는 없습니다.

프로젝트 규모가 확실하지 않습니다. 그렇지 않으면 해외 개발 팀을 사용하는 것이 중요하지 않다고 가정합니다. 따라서 내 경험은

1. 스켈레톤 코드, 퍼블릭 인터페이스, 서비스 인터페이스 등을 정의하고 함께 검토
2. 다른 쪽과의 합격 시험을 정의하십시오
3. 큰 문서를 작은 이야기로 나누고 작은 이야기를 기반으로 작업하십시오. 큰 문서는 전체 시스템의 큰 그림 일뿐입니다.
4. 스토리의 체크 포인트를 일주일 또는 2 주 설정

1과 2는 실제로 다른 쪽이 요구 사항을 잘 이해하고 양쪽이 동일한 패턴을 사용하도록 개발에 관한 것입니다. 3과 4는 민첩한 개발 방법론의 일부이지만 역외 개발의 경우 완전한 민첩한 프로세스를 사용하기가 어렵습니다.

어느 정도는 우리 모두가 그렇게 작동한다고 생각합니다. 누군가가 무언가를 디자인하고 우리는 시스템의 일부이거나 시스템에서 작동하는 것을 코딩합니다. 모바일 장치의 비 게임 앱과 같은 프레임 워크를 기반으로 앱을 구축하는 것이 그 예입니다. 프레임 워크를 만든 사람들의 디자인 팀이 많은 UI 결정을 내 렸습니다. 앱 학습부터 앱 판매에 이르기까지 모든 것을 제어했습니다. 이 모델이 성공한 이유를 확인하려면 일부 공급 업체에서 제공하는 문서 및 도구의 양을 살펴보십시오.

또 다른 예로는 REST 스타일을 구현하려는 웹 애플리케이션이 많이 있습니다. HTTP 사용 방법에 대한 사양이 있지만 실제로 구현 방법을 알려주지는 않습니다. 어쨌든 준수해야 할 사양과 지침 원칙이 있습니다. stackexchange 또는 직장에서의 REST 구현에 대한 토론이 많으면 사람들에게 특정 방식으로 무언가를 구현하라고 말하는 건축가와 같습니다. 그것은 여전히 ​​많은 사람들이 그 스타일을 따르는 것으로 성공적인 모델이라고 생각합니다.

이 두 가지 예에서 디자인이 전파되는 방식을 볼 수 있습니다. 일부는 용지 사양으로, 다른 하나는 서적, 도구 및 예제로 제공됩니다. 사람들이 어떤 표준 / 디자인을 따르고 있는지에 따라 다른 정도의 이해를 얻으려고 노력하는 방법을 볼 수 있습니다. 그냥 stackoverflow로 이동하여 지켜보십시오.)

당신이 나에게 당신의 사양을 주면 부탁드립니다. 당신이 나에게 단위 테스트를 주면, 나는 코딩하고 테스트 할 것이다.