헤비급 개발 방법론에서 개인 연습을 얻는 방법?

나는 프로젝트가 엄격한 품질 표준을 충족하고, 심도있게 문서화되고, 상세하게 관리되고, UML 다이어그램과, 과거의 업무 경험 대부분이 있었던 "카우보이 코딩"과 반대되는 모든 것들을 수행해야하는 새 직장에 있습니다. . 대규모 항공 우주 또는 의료 기기 소프트웨어가 개발되는 방식을 생각하십시오.

나는 카우보이 코딩의 혼란을 떠나 기쁘고 무거운 엔지니어링 방법이 얼마나 좋은지 궁금합니다. 그러나 어떻게 무거운 방법에 대한 경험을 빠르게 얻을 수 있습니까?

단순히 몇 달 / 년 동안 일을하는 것 외에는.

단순한 언어 또는 새로운 API를 사용하면 완구 테스트 프로그램을 해킹하고 의도적으로 실수가 발생하는 것을 볼 수 있습니다. 자전거 타기 또는 악기 연주에 능숙 해지는 것처럼 연습이 필수적입니다. 플루트를 집어 들고 매일 30 분을 보내는 것은 쉽습니다. 오케스트라에 합류하거나 풀 타임 플루트 컨설턴트 일 필요가 없습니다. 그러나 규모가 크고 복잡한 팀을 포함하는 소프트웨어 엔지니어링 활동을 실천하는 방법은 무엇입니까? 의사 소통 및 계획, 의사 소통을 피하고 일정 및 예산 한도를 초과하는 것이 무엇입니까?

혼자 할 수없는 것 같습니다. 소수의 사람들이 짧은 시간 (1 일) 동안 대규모 프로젝트 전체를 소규모로 시뮬레이션 할 수있는 방법이 있습니까?

소수의 사람들이 짧은 시간 (1 일) 동안 대규모 프로젝트 전체를 소규모로 시뮬레이션 할 수있는 방법이 있습니까?

예, 어느 정도 가능합니다. 약 10 년 전 저는 뮌헨에서 열린 OOP 컨퍼런스에서 16 명에게 소규모 비즈니스 소프트웨어에 대한 대략적인 분석 및 디자인 작업을 수행하는 워크숍에 참여했습니다. 상반기는 주로 16 명으로 작업을 해결하기위한 팀 구조를 찾는 것이었고, 하반기는이 팀으로 작업을 해결하는 데 중점을 두었습니다.

첫 번째 부분에서 우리는 16 명의 사람들을 4 개의 그룹으로 나누도록 안내 받았다. 각 4 인 팀은 팀 구조에 대한 제안을 작성해야했으며 (시간이 지남에 따라), 팀 구조가 가장 우수하고 워크숍의 두 번째 부분에 사용해야하는 결정을 내리기 위해 슛 아웃 프로세스가 적용되었습니다. .

불행하게도, 첫 번째 부분 인 동안, 우리는 16 명의 사람들 각각에게 의도 된 팀 구조 내에서 직업을 부여하려는 실수를했습니다. 이 실수는 후반에 혼란을 초래합니다. 16 명이 그러한 과제를 해결하기에는 너무 많기 때문입니다. 효과적인 해결책은 16 명을 소규모 팀으로 다시 나누거나 주 업무를 수행하기 위해 3 명 또는 4 명을 선택하는 것이었을 지 모르지만, 지금 우리는 이것을 보지 못했다.

나는 그날 더 큰 프로젝트 조직에서 직면 할 수있는 전형적인 문제에 대해 많은 것을 배웠다는 인상을 여전히 받고 있습니다. 나는 당신이 어딘가에서 그런 종류의 워크숍을 방문 할 수 있는지, 또는 오늘날 누가 그런 것을 제공하는지 모른다.

점검 목록으로 시작하십시오 . (당신이 바로 첫 번째 단계였습니다 알고 있었다?)
현재 프로젝트에 대한 확인 체크리스트 목록 표준 문서를 모두 확인합니다. 즉. UML 다이어그램, 기능 사양, 고수준 및 저수준 설계 등 ... 시스템 엔지니어가 RTVM (요구 사항 추적 성 검증 매트릭스) 사용을 제안합니다

작업 할 샘플 프로그램을 선택하십시오. 당신이 하나를 얻을 수 없다면, 구글 "코드 카타"또는 구글의 코드 잼 아카이브 도전을 확인하십시오. 아니면 그냥 계산기를 만드십시오. :-)

샘플 프로그램의 기능 스펙을 빌드하십시오. 그런 다음 고급 디자인, UML 다이어그램 등으로 이동하십시오. 사양에 맞게 빌드하십시오. 그것을 테스트하십시오. 현재 작업 관행에 정의 된대로 스펙에서 중대한 결함을 발견 할 때마다 SDLC의 해당 단계로 돌아가서 다시 진행하기 전에 수정해야합니다.

첫 번째 라운드의 경우 작게 유지하십시오. 프로세스를 통한 사이클링은 특정 단계에서 과잉보다 더 중요합니다. 후속 라운드의 경우 중단 한 기능을 추가하십시오. 추적, 로깅, 성능 분석, 테스트 스캐 폴드 등. 추가 할 항목은 고용주가 실제 작업에 기대하는 것에 따라 다릅니다.

디자인 / 빌드 / 테스트 / 반복주기를 여러 번 반복 한 후에는 지금 걱정스러운 "무거운"구성 요소에 대한 기술과 경험을 쌓을 수 있습니다. 반복은 또한 다양한 단계와 생성 된 문서 사이의 상호 연결을 보여줍니다. 여기서 중요한 교훈은 문서 업데이트 및 테스트 요구 사항으로 인해 5 분 코드 변경으로 여러 시간 동안 여러 시간 동안 파급 효과가 발생할 수있는 방법을 보여줍니다.

"무거운"관행에 대한 경험은 실제 작업을 통해서만 가능합니다. 효과적으로 격리 할 수있는 방법이 없습니다. 그러나 공부할 수는 있습니다. 공부하고 숙고 할 수있는 많은 사례 연구와 자료가 있습니다.

그러나 당신이 보거나 연구하는 모든 관습이 반드시 긍정적 인 것은 아닙니다. 소프트웨어 개발은 ​​유동적 인 것이며, 오늘날 하드 코어와 엄격한 것처럼 보이는 것은 내일 어리 석고 중복되는 것처럼 보일 수 있습니다. 이는 새로운 도구와 실험 경험을 통해 신생 기업에서보다 보수적 인 조직에 이르기까지 발생합니다.

기본적으로 변경 및 위험 관리는 각 조직마다 고유 한 형태를 가지고 있습니다. 최선의 방법은 열린 마음을 유지하는 것이지만 팀마다 너무 많은 가정을 수행하지 마십시오.