아키텍처에서 개발로의 핸드 오버에 관한 모범 사례가 있습니까?

우리는 아키텍처에서 개발에 이르기까지 작업을 전달하는 프로세스를 개선하기 위해 노력하고 있습니다.

규모의 한쪽 끝에는 각 개발자가 자신의 방식대로 작업을 수행하면서 혼란에 빠질 위험이있는 아키텍처 지침이 없습니다.

모든 것이 지정된 규모의 다른 쪽에서는 사양이 개발보다 오래 걸리므로 매우 지루한 개발 작업이 발생할 위험이 있습니다.

이 극단 사이에 최적의 중간 지점을 찾은 사람이 있습니까? 어떤 아티팩트를 개발에 제공합니까? 예를 들면 : 모듈, 클래스 구조 또는 시퀀스 다이어그램?

별도의 "아키텍처"팀이라는 개념은 훌륭한 소프트웨어 개발 관행에 대한 모욕입니다. 회사 환경의 아키텍처 팀 은 개발자 풀에서 찾을 수있는 최악의 상아탑 의사 지적 황소 * 아티스트 의 정점 인 경향이 있습니다 .

다른 조직은 건축 그룹을 공로, 지식 또는 기술에 관계없이 가장 고위 구성원에게 막대한 급여를받는 정치적 보상 및 정당화로 간주합니다. 대부분 두 가지 유형으로 구성됩니다.

모든 개발자는 건축가가 될 수 있으며 회사의 고급 디자인에 참여해야합니다. 단일 그룹이 소프트웨어 설계의 모든 측면을 완전히 독재 적으로 통제하고 설계에 기여하지 않았고 설계 선택에 대한 추론을 이해하지 못하고 중대한 결함을 이해할 수있는 개발자에게 전달해야한다는 생각 실제 구현 및 기존 코드에보다 편안하고 근접한 디자인에서 핵심적으로 완전히 결함이 있으며 세 가지 시나리오 중 하나가 지속적으로 발생합니다.

• 개발자는 현재 구현의 현실로 인해 디자인을 이해하거나 완전히 거부하지 않고 문서화되지 않은 자체 디자인을 결정하고 대신 구현합니다. 상황은 소프트웨어의 구현을 반영하지 않는 공식 디자인 문서입니다.

• 개발자는 현재 요구 사항이나 사용자 스토리의 고유 한 측면을 고려할 수도 있고 그렇지 않을 수도있는 디자인을 맹목적으로 따르므로 버그가 있고 품질이 구현되지 않습니다.

• 디자인 문서를 이해하고 구현할 수있는 지능형 개발자는 디자인 토론에 참여하지 않아도 지루해합니다. 정치적 문제 나 선임 문제로 인해 건축 그룹에 참여하지 못했을 가능성이 높으므로 좌절하고 지루하며 녹색 목초지로 떠납니다. 이것은 프로젝트에 부정적인 영향을 미쳐 두뇌 유출로 이어지고 소프트웨어 품질의 악순환이 계속됩니다.

이 문제를 완화하는 가장 좋은 방법은 아키텍처 그룹을 변경하여 기술 책임자 위치에 두는 것입니다. 원하는 경우 아키텍처 그룹의 역할은 "기술 리드의 스크럼"이어야합니다. 그들은 최고 수준의 기술 방향 문제를 거의 만나지 않고 논의해야합니다. 토론을 Java에서 Scala로 마이그레이션하고 MySQL 용 Oracle을 포기하고 StarUML에서 Altova UML로 전환하여 특정 유형의 설계 프로세스를 요구하는 공통 유틸리티 라이브러리를 작성할 수 있습니다.

실제 및 실제 소프트웨어 설계는 아키텍처 그룹의 매우 높은 수준의 방향에 따라 모든 소프트웨어 개발자가 참여하는 커뮤니티 프로세스입니다.

아키텍처에서 개발 테스트 및 운영으로 정보가 전달되는 방식에는 항상 문제가있었습니다. 이러한 문제를 해결하는 방법은 다음과 같은 몇 가지 요소에 따라 다릅니다.

• 소프트웨어의 크기
• 복잡성
• 조직의 문화
• 믿음.

이러한 요소의 특정 조합의 경우, 창 발적 설계를 갖춘 순수 애자일 접근 기능 팀이 적합합니다. 정보는 함께 작동하여 흐릅니다. 분야는 필요한 것을 문서화합니다.

이러한 요소의 다른 조합을 위해 소규모 건축가, 테스터, 운영 전문가 및 수석 개발자 팀은 아키텍처 반복을 시작하여 아키텍처를 천천히 구축하고 아키텍처 결정에 대한 문서화 및 즉각적인 피드백을 얻을 수 있습니다. 기능을 구현하는 더 많은 개발자를 팀에 추가하고 원래 핵심 팀을 더 작게 만들 수 있습니다.

대부분 정부 및 금융 프로젝트의 경우 더 많은 문서를 미리 작성해야하며 선택에 대한 실제 피드백없이 시간이 오래 걸릴 수 있습니다. 내 생각에 이러한 많은 프로젝트가 실패한 가장 큰 이유는 여전히 이것이 귀하의 상황이라면 설명서를 요구 사항에 맞게 만들고 옵션 1 또는 2를 사용하여 실제로 소프트웨어를 구축하고 설명서를 수정 / 적응하는 것보다 낫습니다.

도움이 되었기를 바랍니다.

나는 이것이 인기가 없지만 당신이 한 의견을 알고 있습니다.

모든 것이 지정되면 스케일의 다른 쪽 끝에서 사양이 개발보다 오래 걸립니다. 그리고 매우 지루한 개발 작업이 발생할 위험이 있습니다.

실제로 당신이 노력해야하는 것입니다. 디자인 및 사양이 개발 작업이 지루할 정도로 견고하면 개발 비용이 줄어 듭니다. 코드를 수정하는 것보다 사양을 수정하는 것이 훨씬 저렴하며 소프트웨어 프로젝트의 가장 큰 비용은 빌드가 아니며 장기적인 지원입니다. 견고한 사양을 기반으로하는 지원 코드는 훨씬 저렴합니다.

나는 maple_shaft의 답변에 전적으로 동의하지는 않지만, 의견에 전체 비트를 말할 충분한 공간이 없었습니다! ;-)

모든 개발자가 아키텍트 일 수 있고 건축가 여야한다는 데 동의하지만 모든 개발자가 전체 제품 또는 시스템의 아키텍처를 책임 져야한다는 것은 아닙니다. 또한 모든 건축 팀에 동일한 브러시를 사용하여 페인트 할 수 있다고 생각하지 않으며 올바른 건축 팀이 전체 제품 개발 프로세스에 큰 가치를 제공 할 수 있다고 생각합니다. 오해는 건축가가 시스템 설계의 모든 측면을 지시해야한다는 것입니다. 대신 더 높은 수준의 디자인에 중점을두고 구현 세부 사항을 개발 팀에 남겨 두어야합니다. 그러나 개발자가 처음부터 계획 및 설계 프로세스에 관여해서는 안된다는 것은 아닙니다.

제품이 더 크고 모듈 식이며 궁극적으로 더 복잡할수록 다양한 개발 팀이 처리하는 제품의 다양한 부분을 찾을 수 있습니다. 이러한 팀은 담당 시스템의 일부를 완전히 이해 한 경우 시스템 전체를 이해할 필요가 없습니다. 종종 이러한 추가 팀은 건축 가나 다른 팀이 전문 지식을 갖지 못할 수있는 특정 기술 영역에서 모듈을 개발하기위한 특정 목적을 위해 하청 업체로 구성됩니다. 내 고유의 재능은 API 개발에 있으며 아직 보지 못했습니다. 유용성 측면에서 완전히 혼란스럽지 않고 완전히 유기적으로 개발 된 잘 인수 된 API, 또는 API의 여러 측면 사이에 일정 수준의 균일 성을 보장하는 사람으로 누군가를 두드러지게 요구하지 않았습니다. 나는 많은 예와 이유를 계속해서 언급 할 수 있지만, 이런 종류의 상황이 많은 사람들이 생각하는 상아탑 BS라고 생각하지 않습니다. 불행히도, 특히 기업의 편집증으로 인해 maple_shaft가 가장 염려할만한 종류의 제품 개발이 잘못되고 관리가 잘 안되는 제품을 개발하는 방어, 의료 및 금융 분야에는 많은 장소가 있습니다. 이것들은 건축가에게 약간의 가치가 나쁜 나쁜 이름 (일반적으로 말해서)을주는 것으로 생각합니다. 불행히도, 특히 기업의 편집증으로 인해 maple_shaft가 가장 염려할만한 종류의 제품 개발이 잘못되고 관리가 잘 안되는 제품을 개발하는 방어, 의료 및 금융 분야에는 많은 장소가 있습니다. 이것들은 건축가에게 약간의 가치가 나쁜 나쁜 이름 (일반적으로 말해서)을주는 것으로 생각합니다. 불행히도, 특히 기업의 편집증으로 인해 maple_shaft가 가장 염려할만한 종류의 제품 개발이 잘못되고 관리가 잘 안되는 제품을 개발하는 방어, 의료 및 금융 분야에는 많은 장소가 있습니다. 이것들은 건축가에게 약간의 가치가 나쁜 나쁜 이름 (일반적으로 말해서)을주는 것으로 생각합니다.

OP가 찾던 중간 지점은 어디입니까? 답은 커뮤니케이션 채널을 여는 것과 관련이 있습니다. 설계자는 개발 팀이 경계의 위치를 ​​이해할 수 있도록 설계를 설명하는 사양을 충분히 자세하게 전달해야합니다. 모든 것이 블랙 박스로 간주되는 가장 넓은 의미의 스토리 및 기능 시나리오. 그런 다음 설계자는 팀이 가정을 확인하고 너무 광범위하거나 명확하지 않은 사양에 대한 질문에 답변 할 수 있도록 건축가의 시간에 액세스 할 수 있도록해야합니다. 그 후, 개별 팀이 다른 팀이 무엇을하고 있는지 파악하고 시스템의 각 부분이 다른 부분과 잘 어울릴 수 있도록 다른 팀과 연락 할 사람을 알아야합니다. 이 팀들은 서로 직접 만납니다. 일단 시스템이 가장 넓은 레벨로 설계되면, 설계자는 팀이 위생 상태 점검이 필요할 때 사람들이 직접 방문하는 사람들이되어야하고 제품 "비전"이 유지되도록해야합니다. 또한 필요한 모든 통합 프로세스를 수행하고 관리자, 고객 및 기타 지분 보유자로부터 개발 팀을 위해 필요한 "에어 커버"를 제공하는 동시에 이러한 다양한 사람들이 모두 함께 작업 할 수 있도록해야합니다. 그것들이 어떻게 작동해야 하는가.

IMHO 아키텍트는 무엇보다도 촉진자 및 커뮤니케이터이며 디자이너는 둘째입니다. 어떤 수준의 사양에 대해? 최고의 건축가는 팀이 원하는 세부 수준에 대해 팀에 물어보고 그들 사이에서 균형을 찾는 건축가라고 생각합니다. 각 팀마다 필요한 문서 수나 방향에 따라 요구 사항이 다를 수 있습니다. 선임 팀은 대략적으로 그려진 그림을 발견하고 빠른 대화로 충분할 수 있지만 비교적 후배 개발자로 가득한 팀은 좀 더 많은 것을 요구할 수 있습니다. 무엇보다도 건축가는 각 팀에서 최상의 결과를 얻기 위해 개발자가 자신의 디자인 재능을 발휘하도록 장려해야합니다.

무언가를 개선하기 위해 노력하고 있으므로 이미 프로세스의 문제를 감지했습니다. 특정 상황의 근본 원인은 다음과 같습니다 . 개발자는 외부인이 자신에게 부과 한 아키텍처로 자신을 식별 할 수 없습니다. 아키텍처를 개발에 넘겨 주면이 근본 원인을 해결하지 못할 가능성이 높습니다.

아키텍처를 개발 팀의 일부로 만듭니다. 건축가와 개발자 사이의 경계를 찢습니다. 이렇게하면 정보가 흐릅니다. 개발 팀이 아키텍처를 형성하는 데 참여하면 아키텍처를 외계인으로 간주하지 않습니다. 아키텍처에 대한 지식을 팀에 주입하십시오. 당신이 언급 한 혼돈을 피하기 위해 기업 아키텍처의 원동력을 가르쳐주십시오. 언급 한 지루함을 피하기 위해 아키텍처 결정을 내려야 할 경우 개발자를 참여시킵니다. 그러면 더 이상 인계가 필요하지 않으며 개발 팀에서 건축가로서의 역할을 수행했습니다.

미래의 팀이 코드를 유지하려면 가능한 한 많은 정보를 제공해야합니다. 예를 들어 시퀀스 다이어그램이없는 경우 개발자는 단계별로 코드를 추적해야하므로 시간이 낭비됩니다.

또한 새로운 팀이 틀린 가정을 할 여지가 있습니다.

일반적으로 프로젝트가 무엇인지, 기술 사양, 단위 테스트 사례 및 시퀀스 / 클래스 다이어그램에 대한 문서가 있어야합니다.

모델뿐만 아니라 코드를 만드는 클래스 다이어그램 뷰가 솔루션이라고 말합니다. 클래스 다이어그램은 프로젝트 아키텍처의 정적 뷰를 나타냅니다. 패키지> 클래스, 인터페이스, 열거 형> 속성, mehtods 등 ...> 등을 가지고 있습니다. UML2 메타 모델은 Java 또는 dotnet 프로젝트와 정확히 동일한 구조를 갖습니다.

우리 프로젝트에서 사용하는 것은 단일 모델에 저장된 클래스 다이어그램입니다. 분류자가 이미 존재하는 경우 모델의 뷰를 생성하거나 새로운 경우 그래픽으로 새 뷰를 생성합니다. 개발자는 CVS 내의 프로젝트 폴더 루트에 저장되어 다이어그램과 모델을 볼 수 있습니다. 내가 좋아하는 것은 개발자가 모델링 할 수 있다는 것입니다. 코드 수준에서 무언가가 변경되면 전체 팀의 CVS에서 모델이 자동으로 업데이트되기 때문입니다.

클래스 다이어그램은 실제로 간단하고 리버스 엔지니어링이 작업을 수행하고 코드의 그래픽 뷰를 작성하기 때문에 실제로 잘 작동하고 UML을 알 필요가 없습니다. 간단한 탐색, 고급 및 상세보기로 많은 주석을 다이어그램으로 추가 할 수 있으며 항상 프로젝트에서 직접 CVS에 표시됩니다. 내 UML 클래스 다이어그램은 이제 마술입니다 :-)