저의 고용주 (개발자가 아님)는 CASE 도구가 개발 프로세스 및 문서를 개선하는 데 도움이 될 것이라고 생각합니다. 우리는 현지 고객을 위해 모바일 뱅킹 솔루션을 구축하는 5 명의 개발자로 구성된 소규모 팀입니다. CASE 툴은 구매해야하므로 시간과 비용이 낭비 될 것으로 생각되며, 모델링에 익숙해 지려면 시간과 시간이 필요합니다. 코드 생성은 또 다른 문제입니다. CASE 생성 코드는 좋은 개발자가 작성한 코드만큼 좋지 않을 것이라고 생각합니다.
민첩한 원칙, 디자인 패턴을 고수하고 TDD를 사용하고 코드를 깨끗하게 유지한다고 생각합니다. 우리는 잘해야합니다. 그리고 분석 및 디자인에 있어서는 화이트 보드의 간단한 UML 다이어그램이 트릭을 수행해야한다고 생각합니다. 문서는 훌륭하고 중요하지만 가능한 한 적게 작성해야하며 문서에만 집중하고 코드를 잊어서는 안됩니다. 이것이 내가 생각하는 것입니다.
제가 맞습니까? 또는 고용주의 말을 듣고 적절한 CASE 도구를 연구해야합니까?
답변
상황은 결정에 대한 분석적 접근을 보증합니다. 결론은 “Case 도구가 비즈니스에 가치를 제공합니까?”입니다. 종종 경영진은 개발자가 조직의 현재 프로세스 및 문화에 얼마나 잘 맞는지에 관계없이 방법론이나 도구를 채택하기를 원할 것입니다.
ChrisF가 지적한 것처럼 고용주가 CASE 도구를 살펴 보라고 요청한 경우이를 준수해야합니다 (프로그래밍이 아닌 작업장 문제임). CASE 도구 채택에 영향을 줄 수있는 몇 가지 요소는 다음과 같습니다.
- 어떤 프로세스에 사용 가능한 CASE 도구가 있습니까?
- 새로운 도구를 채택하기 위해 몇 인당 시간이 필요한지 추정
- 새로운 도구를 채택하면 프로세스가 어떻게 변할까요?
- 또는 새로운 도구를 채택함으로써 어떤 긍정적 (또는 부정적인) 영향이 측정 될 수 있습니까?
이것을 개발 환경과 프로세스를 업그레이드 할 수있는 기회로 생각하십시오. 현재 프로세스가 조직의 문화와 완벽하게 일치 할 수도 있지만 적절한 연구를 수행하기 위해 고용주와 팀에게 맡겨야합니다.
답변
예, CASE 도구에 대한 연구를 시작해야합니다.
- 도움이되지 않을 것이라는 주장을 뒷받침 할 증거 가 필요 하기 때문입니다. 당신은 결코 그들이 당신을 도울 것임을 알 수 있습니다.
- 고용주가 당신에게 말했기 때문입니다.
나는 David Kaczynski가 그의 훌륭한 답변 에서 제시 한 요점 을 정확하게 반복하지 않을 것 입니다.
답변
코드 생성을 통해 실제로 애자일에서 CASE / MDA 지향 개발로의 큰 패러다임 전환처럼 보입니다. 프로젝트 관리 관점 (CASE 접근 방식이 반복, 사용자 스토리, 빠른 피드백 또는 지속적인 개선 개념과 충돌하지는 않음) 일 필요는 없지만 “소프트웨어 기술”관점에서 분명히 그렇게하므로 코드에 대한 통제력이 떨어집니다. 읽을 수없고, 단단하며, 테스트하기가 더 어려우며, 지속적으로 모델과 동기화해야하는 코드 등이 생성되고 생성됩니다.
당신이 묘사 한 것에서, 고용주에게 필요한 것은 쉽게 이해할 수 있습니다
- 개발자가 팀을 떠나는 경우 지식 손실을 피하기 위해 더 나은 문서화.
- 더 빠른 개발 프로세스.
소프트웨어 전문가는 CASE 접근 방식이 이러한 기대치를 충족시키는 능력에 대한 의심을 분명히 말할 수 있습니다. 또한 필요한 경우 CASE 도구를 살펴 보는 것도 귀하의 의무입니다. 그중 하나를 시도한다고해서 1 / 결과가 만족 스러울 것이라는 것을 의미하지는 않습니다 (특히 개발해야 할 필요성과 충돌하는 잠재적으로 큰 코드 생성 오버 헤드에 대해 생각하고 있습니다). 기존 민첩한 컨텍스트를 유지하면서 CASE 도구 (다이어그램, 문서 생성)의 일부 기능이 사용되는 절충안을 찾으십시오.
애자일 환경의 CASE 툴과 그 장점 / 단점에 대한 흥미로운 기사가 있습니다 : http://www.agilemodeling.com/essays/simpleTools.htm
답변
저의 고용주 (개발자가 아님)는 CASE 도구가 개발 프로세스와 문서를 개선하는 데 도움이 될 것이라고 생각합니다. “
만약 당신의 고용주를위한 컨설턴트의 역할을하려고한다면, 나는 이런 종류의 것들로부터 그것들을 설득해야 할 의무가 있습니다. 우선, 업무에 관여하지 않는 사람들이 개발자를위한 도구를 선택하게하는 것은 중대한 관리 오류입니다. 이것은 거의 잘되지 않습니다. 선택하는 사람들이 강한 기술적 배경을 가지고 있지 않으면 적어도 두 배나 나쁩니다. 그리고 그들이 추진하고있는 도구에 대한 경험이 없다면, 이것은 완전한 혼란이 될 것입니다.
비 기술적 경영진이 이런 종류의 것을 제안하는 가장 큰 이유는 누군가가 무언가를 팔려고하기 때문입니다. 이런 종류의 물건을 판매하는 한 주요 회사는 희귀 한 공기 속에서 납 제플린처럼 떨어지는 수입을 가지고 있습니다. 다른 곳으로 이동하지 않은 영업 사원 (일명 리셀러, 컨설턴트)은 새로운 마크, 즉 고객을 찾기 위해 노력하고 있습니다. 이 회사들이 어려움을 겪고있는 주요 이유 중 하나는 더 이상 이러한 종류의 도구에 대한 수요가 많지 않기 때문입니다. ‘이러한 종류의 도구’라는 말은 ‘코드 작성을 제거 할 것’을 약속하는 도구를 의미합니다. 언어에 따라 코드에 아무런 문제가 없습니다. 작성된 코드는 이러한 도구가 제공하는 것보다 훨씬 강력한 추상화를 가지고 있습니다.
이것이 개발을 관리하는 나쁜 방법 인 주된 이유 중 하나는 팀 직원을 끌어들이는 데 사용할 수있는 인력을 크게 줄일 수 있기 때문입니다. 하나는,이 흔하지 않은 도구를 배워야하며, 둘째, 대부분의 숙련 된 개발자는 이러한 일을하고 싶지 않습니다. 종종 이러한 도구를 중심으로하는 것은 이러한 도구가 대부분의 작업을 수행하기 때문에 훌륭한 개발자가 필요하지 않다는 것입니다. 이것은 완전히 거짓입니다. 반대입니다. 그들은 사소한 모든 일을하고 종종 사소한 부분을 어렵게 만듭니다. 또한 코드를 작성할 필요가 전혀 없습니다.
특히 CASE 도구를 사용하여 이러한 패키지를 소유 한 세 곳에서 근무했습니다. 모든 하나에서 다음과 같이 진행되었습니다.
- 이 모델은 도구로 설계되었습니다. 평소보다 훨씬 오래 걸리고 노력이 늦어 질 때까지 사용 가능한 결과물이 생산되지 않았습니다.
- 비즈니스 로직으로 모델을 보강해야했습니다. 모델이 잘못되었고 프로젝트가 너무 늦었 기 때문에 프로젝트 초기 단계에서 수동으로 조정해야했습니다.
- 모델과 코드를 다시 동기화하면 CASE 도구를 선반에 다시 넣지 않아도되므로 비용이 많이 들었습니다.
간단히 말해서, 그것은 모든 경우에 100 % 총 실패와 돈 낭비였습니다. 다른 조직에서 CASE 도구를 사용한 다른 사람들과 이야기했을 때 이야기는 거의 같습니다. 이러한 도구를 모두 사용하지는 않았으며 일부 사람들이 도구를 잘 활용했을 가능성이 있지만,이를 사용한 대부분의 팀은 오래 전에 사용을 중단했을 것입니다.
답변
CASE 도구를 조사 / 구현함으로써 얻을 수있는 이점 중 하나는 향후 고용을 위해보다 유용한 기술을 습득 할 수 있다는 것입니다. 데이비드 카친 스키 (David Kaczynski)가 지적한 것처럼, 이것은 고용주 / 직원 관계 질문만큼 프로그래밍 문제가 아닙니다. CASE 도구의 또 다른 이점은 일단 배우면 회사는 더 복잡한 프로젝트를 더 광범위하게 수행 할 수 있다는 것입니다. 고용주가 원하는 계약이 CASE 도구 사용을 선호하거나 선호하는 계약일 수 있습니다.
답변
당신은 문제와 솔루션을 혼합하고 있으며 상사는 거의 성공으로 도움을 주려고합니다. 상사에게 도전하려면 조직에서 자신의 역할이 무엇인지 분명해야합니다. 그가 CEO이고 CTO 인 경우 결정은 귀하의 결정이며 CEO는 문서 부족으로 인해 어떤 비즈니스 측면이 영향을 받는지 지적해야합니다. 그런 다음 CASE 도구 또는 다른 솔루션을 사용하여 비즈니스 문제를 해결해야합니다.
CASE 도구 사용에 대한 구체적인 제안과 관련하여 추가 작업으로 팀에 과부하를주지 않고 목표를 달성 할 수 있도록 올바르게 선택해야한다고 생각합니다. 문서화를 개선하려는 경우 그래픽 다이어그램에서 코드를 생성 할 필요는 없지만 코드에서 다이어그램을 생성 할 수있는 도구가 충분할 수 있습니다. 이러한 도구의 예는 Codelogic 입니다. 나는 몇 년 전에 깨끗하고 명확한 디자인을 이해하고 사용하기 쉽게 만들기 위해 사용했습니다. 돈을 표현하는 것이 또 다른 관심사라면 아마도 오픈 소스를 볼 수 있습니다 (여기서는 도울 수 없지만 모든 연구 결과에 관심이있을 것입니다).
CASE 도구의 대안도 도움이 될 수 있습니다. 순환 적 또는 기타 복잡성 측정과 같은 것을 측정하면 설계가 잘 구성되고 개발자가 코드에 집중할 수 있습니다. Javacode와 같은 코드에 대한 주석이 좋으면 문서를 개선하는 데 도움이 될 수 있습니다.
솔직히 CASE 도구가 상사가 그것을 이해하는 데 도움이되지 않는다고 생각하면 생각합니다. 그가 좋은 상사라면 그는 당신의 의견을 소중하게 생각할 것입니다. 나는 비판적 분석없이 자신이 말하는 것을 수행하는 직원을 결코 좋아하지 않았습니다. 그러나 물론 다윗이 제안한대로 모든 토론은 강력하고 객관적인 주장에 대해 논의해야합니다.
답변
나는 고용주가 자신이 물건을 거꾸로 받았다는 것을 깨닫게하려고합니다. 소프트웨어 팀에 투자 할 여지가 있다면 병목 현상이나 품질 문제가 무엇인지 식별해야합니다. 경우 당신이 문서와 개발 프로세스 분야에서 개선을위한 대부분의 여지가 있음을 밝혀, 당신은이 지역을 개선 관련하여 가장 큰 투자 수익 (ROI)을 가지고 어떤 변화 식별해야합니다. CASE 도구를 사용하기 시작했을 수도 있고 그렇지 않을 수도 있습니다.