수동 소득 아이디어 2023
사용자를 위한 이점 외에도 소프트웨어의 품질은 디지털 제품의 성공에 중요한 요소입니다. 실제로 소프트웨어 품질 문제는 필요한 만큼 중요하지 않은 경우가 많습니다.
기술적 우수성과 좋은 설계에 대한 요구가 이미 민첩한 작업 원칙의 일부임에도 불구하고 기술적 부채는 눈에 띄지 않고 무시되고 과소평가됩니다. 회사와 고객의 소프트웨어 품질 저하로 인한 피해는 막대할 수 있습니다.
기술 부채란 무엇입니까?
“기술 부채”라는 용어는 Ward Cunningham이 품질과 속도 사이의 기술적 절충안을 나타내기 위해 만들었습니다. 기술 부채는 소프트웨어 품질의 타협에서 발생하며 좋은 품질에는 속도가 필요하고 특정 상황에서(예: 특정 기한 또는 고객 기대치를 충족하기 위해) 소프트웨어 품질에 대한 의심이 있을 때 타협이 이루어진다는 주장에 기반합니다. .
따라서 기술적 부채는 의사소통 부족, 팀 노력, 자격 또는 성급한 제품 출시로 인해 발생하고 리팩토링 없이 지속적으로 증가하는 코드의 의도적 또는 우발적 오류, 결함 및 약점을 설명합니다. 물론 여기에는 잘못 프로그래밍된 소프트웨어를 변경하기 위해 수행해야 하는 추가 노력도 포함됩니다.
그러나 기술적 부채는 의식적인 결정에 의해서만 발생하는 것이 아니라 예를 들어 자격 부족이나 품질 또는 코딩 표준 부족으로 인한 사고로 인해 발생합니다. Martin Fowler의 기술 부채의 4가지 유형을 참조하십시오.
경제학에서와 같이 부채라는 용어는 이자를 포함하여 상환해야 함을 의미하거나 과도한 부채의 경우 궁극적으로 파산으로 이어지며 소프트웨어 개발에서는 소프트웨어가 죽거나 결과적으로 회사를 한계까지 밀어붙이는 손상이 발생할 수 있음을 의미합니다. 재정적 탄력성을 가져옵니다.
Scrum 및 애자일 소프트웨어 개발의 기술적 부채
민첩한 소프트웨어 개발에서 품질은 절대 타협할 수 없는 것으로 간주됩니다. 일회성 단축도 결국에는 더 많은 시간과 비용이 소요되고 대부분의 경우 원래 가능했던 품질이 더 이상 달성되지 않기 때문에 장기적으로는 좋은 결정이 아닙니다. 따라서 우리의 관점에서 기술 부채는 절대 금물입니다.
소프트웨어 개발에서 기술적 부채의 결과는 무엇입니까?
기술 부채는 “음수 값예를 들어, 시스템 오류, 열악한 사용자 인터페이스, 부정적인 고객 만족도, 높은 지원 비용, 낮은 판매 및 마진 등으로 인해
기술 부채 또는 불량 코드는 짧은 시간 후에 영향을 미칩니다. 에 대해 부정적인 개발 속도 에서.
새로운 기능을 작업할 수 있는 시간이 줄어들고 있습니다. 기술 부채의 영향은 선형이 아니라 기하급수적입니다. 이것은 개발팀이 기술적 부채의 영향을 수정하는 데 점점 더 많은 시간을 할애할 것임을 의미합니다. 그만큼 “시장 진출 시간” 팀의 소요 따라서 명확한 떨어져 있는.
기술적 부채는 사상자 수 약 투명도. 기술적 부채가 누적됨에 따라 복잡성과 예측 불가능성이 증가하여 개발 팀이 유효한 추정치를 생성하기가 점점 더 어려워집니다.
기술적 부채는 의욕 저하 특히 경영진이 시간 압박을 가하는 경우 개발 팀에서 직원 마이그레이션으로 이동합니다. 생산적인 작업을 허용하지 않는 조건에서 해당 품질 표준을 가진 개발자는 장기적으로 작업하지 않습니다.
기술적 부채는 증가하다 그만큼 총소유비용.
기술 부채의 원인은 무엇이며 기술 부채는 어떻게 발생합니까?
- 품질 기준 및 품질 측정 부족
- 높은 코드 복잡성
- 중복 코드 또는 모듈
- 누락된 통합 테스트
- 열악한 테스트 자동화 및 테스트 범위
- 누락되거나 일관되지 않은 코딩 표준
- 누락되거나 불충분한 기술 지식
- 조정되지 않은 개발 팀
- 개발팀 경험 부족
- 클라이언트와 소프트웨어 개발 파트너 간의 의사 소통 부족
- 누락된 제로 버그 정책
- 누락되거나 부적절한 문서
- 열악한 아키텍처 및/또는 디자인
- 지연된 리팩토링
- 애자일 소프트웨어 개발 방법 및 프레임워크에 대한 지식이 없거나 불충분함
일반적인 기술적 부채 목록은 이러한 점이 모범 사례 소프트웨어 개발 팀이 기대하는 것과 상충된다는 것을 분명히 보여줍니다.
기술 부채가 소프트웨어를 죽이는 이유
개발 팀이 품질에 대해 타협해야 하고 합의된 품질 기준을 충족하지 않는 것을 제공하는 경우 처음에는 타협이 부분적으로만 보일 수 있습니다. “Quick & Dirty Hacks”가 도입되었거나 아키텍처가 손상되었을 수 있습니다. 개발팀은 괜찮아 보일 수도 있는 “외부 hui, 내부 ugh”를 전달했습니다.
이 불편한 상황에 처한 팀이 이 불행에서 벗어날 수 있는 유일한 방법은 기술 부채를 갚고 가능한 한 빨리 줄이는 것입니다. 하지만 나중에 품질을 가져오려면 더 많은 노력이 필요하기 때문에 원래 필요했던 것보다 더 많은 시간이 소요될 것입니다. 따라서 지속적인 부채의 결과는 더 많은 또는 더 높은 부채입니다!
이미 잘못된 코드를 기반으로 다음 릴리스를 계속하는 팀의 개발 속도는 더 빨라지는 것이 아니라 더 느려질 것입니다. 나쁜 코드가 많을수록 속도가 느려집니다. 이제 같은 이야기가 반복되고 더딘 진행으로 인해 또다시 퀄리티가 떨어진다면 부채는 늘어날 것이다. 이번에는 모두가 이미 열악한 품질을 더욱 악화시키는 것이 더 쉽습니다.
이것은 소프트웨어가 죽기 시작하는 곳입니다. 어느 시점에서 품질은 다소 관리할 수 있는 쓰레기 더미(“큰 진흙 덩어리”)로 끝납니다.
기술적 부채보다 새로운 기능에 우선순위를 두는 것은 엄청난 위험을 수반합니다. 이러한 선택을 할 때마다 품질 문제를 무시하는 의식적인 선택을 하는 것입니다.
기술 부채는 언제 허용되는 것으로 보입니까?
품질에 대한 의식적인 타협이 허용되는 상황은 거의 없습니다.
빠른 프로토타입 제작 및 피드백 받기
시장에 가장 먼저 진출하여 경쟁 우위 확보
예상치 못한 사건에 대한 대응 – “실제” 긴급 상황
그러나 모든 경우에 위에서 이미 설명한 결과의 악순환에 빠지지 않도록 이 단계 직후에 리팩토링 또는 기술 부채 감소를 위한 시간을 계획해야 합니다.
품질을 타협하려는 이러한 의식적인 결정으로 관련 위험 또는 이자를 포함한 부채를 가정된 기회 또는 자산과 신중하게 비교해야 합니다.
기술적 부채는 소프트웨어의 추가 개발 및 유지 관리에 직접적인 영향을 미친다는 점에 유의해야 합니다. 수학적으로 잘못 프로그래밍된 소프트웨어로 인해 변경 및/또는 확장에 대한 노력이 60%에서 100%까지 증가한다고 가정할 수 있습니다.
기술적 부채를 어떻게 피합니까?
- 소프트웨어 개발 파트너를 선택할 때 관련 표준 및 모범 사례에 따라 작동하는지 확인하고 이 시점에서 어떠한 타협도 하지 마십시오.
- 개발팀이 이미 잘 훈련되어 있고 새 프로젝트를 기존 CI/CD 플랫폼에 기술적으로 “온보딩”하는 것이 1일 이내에 가능한지 확인하십시오.
- 외부 전문가가 정기적으로 코드 검토 또는 감사를 수행하도록 합니다.
- 제로 버그 정책을 구현합니다.
- 소프트웨어 개발 파트너를 선택할 때 그들이 소프트웨어 개발에 집중하는지 확인하십시오. 경험에 따르면 이 파트너가 최고 품질 표준에 따라 작업할 가능성은 포트폴리오에 다른 제안 외에 소프트웨어 개발이 있는 서비스 제공업체에 비해 훨씬 더 높습니다.
- 출시 시간이 품질보다 더 중요하다는 말을 들으면 회의적입니다. 실제로 이것은 모순이 아닙니다. 품질이 시장 성공의 전제 조건이기 때문입니다. 키워드: “처음부터 제대로 하라”.
- SonarQube 등을 통해 적절한 도구 또는 메트릭을 사용하여 소프트웨어 품질 및 보안을 지속적으로 측정합니다.
- 서비스 제공업체와 협력하려면 다음과 같은 적절한 품질 보증을 요구하십시오. “알려진 오류 없음”.
- 의심스러운 경우: 품질을 타협하는 것보다 덜 중요한 기능을 사용하지 않는 것이 좋습니다.
결론
기술 부채는 가치 창출, 경험주의 및 팀 사기에 영향을 미치는 숨겨진 비용입니다. 장기적으로 그들은 회사와 경영진, 개발자, 제품 소유자, 스크럼 마스터 또는 고객과 같은 관련된 모든 사람들에게 매우 문제가 되는 상황으로 이어질 것입니다. 재정적 손실. 따라서 의식적이든 무의식적이든 기술적 부채를 허용하는 것은 적어도 중장기적으로는 결코 좋은 생각이 아닙니다.
