린 소프트웨어 개발의 7가지 낭비와 이를 방지하는 방법

린 프로세스 사고는 낭비 편집을 근절하고 줄이는 것을 우선시합니다. 주요 회사에서 채택한 "린" 접근 방식에도 불구하고 일부 표준 "낭비" 관행은 "명백한 특성"으로 인해 지속됩니다. 인간과 조직의 관행에 깊이 새겨져 있는 본성은 엄격한 접근을 하기 전까지 완고합니다.

폐기물이란 무엇입니까?

자원/시간 또는 노력이 필요하지만 성과 또는 수익 발생에서 관련 결과를 가져오지 않는 모든 것을 "낭비"라고 합니다.

궁극적으로 "폐기물 감소" 절차는 팀 생산성과 결과를 높이기 위해 설계되고 안내됩니다.

그러나 이제 린 소프트웨어 개발은 ​​애자일의 조상이 되었기 때문에 소프트웨어 엔지니어링 및 개발에 대해 이러한 7가지 낭비 감소 원칙을 채택하여 효과적인 제품 및 서비스를 생성하고 비용을 절감하며 제품 출시 시간을 단축할 수 있습니다.

1. 부분적으로 완료된 작업

이전 작업이 다시 시작되지 않으면 그 노력은 낭비였습니다.

완료/완료될 때까지의 작업은 고객의 가치 제안에 추가되지 않습니다. 따라서 보류하면 시간을 낭비하고 코드를 유지 관리하는 데 어려움을 겪습니다.

현대적인 예는 클라이언트가 제품에 대한 수정이나 추가 기능을 요구하는 경우입니다. 비즈니스는 긴급하게 완료하기 위해 최선을 다하고 있습니다. 개발 팀은 진행 중인 작업을 중단하고 요구 사항에 따라 조치를 취해야 합니다. 같은 페이지에서 이전 작업이 다시 시작되지 않으면 노력 낭비입니다.

또는

코딩되지 않은 문서: 요구 사항이 자세히 설명되어 있지만 구현되지는 않습니다.

이 낭비를 줄이는 방법은 무엇입니까?

• 프로젝트의 "시작"이 아니라 "마무리"에 중점을 두어야 합니다.
• 진행 중인 작업 기간을 줄입니다.
• 팀이 노력을 구현할 준비가 될 때까지 모든 요구 사항에 대한 자세한 사양을 기다리는 것을 중단하십시오(그렇다면 손실 원인이 되지 않을 것입니다).

2. 추가 프로세스

실용적인 가치를 전달하지 않고 제품 시장 시기 또는 성취를 불필요하게 연장하는 추가된 프로세스 또는 읽지 않은 문서는 낭비입니다.

그러나 비즈니스 정책에 따라 이러한 문서가 요구되는 경우가 많으며 아직 읽어본 적이 없는 상당한 문서 작업이 있습니다. 그 노력은 대단합니다.

전형적인 예:

• 문서의 불필요한 세부 사항.
• 실행 없이 추가 관리 또는 계획.

그것을 줄이는 방법?

조직은 손실된 원인/노력과 가치를 제공하는 것을 구분할 수 있습니다. 의미 있는 결과를 생성하는 데 초점을 맞추고 "양" 작업을 제한하여 더 "품질" 작업을 수행하는 채널 노력을 기울여야 합니다.

3. 추가 기능

고객을 위해 추가했지만 수익 증대에 기여하지 않거나 요청하지 않은 기능 또는 가치가 낮은 기능은 노력 낭비입니다.

기업은 많이 활용되거나 실행되지 않을 기능을 추가할 때 이러한 개발 오류를 범합니다. 이 새로운 기능은 실제로 유휴 상태에 있으며 응용 프로그램의 복잡성을 증가시킵니다.

소프트웨어 80/20 규칙은 중요한 역할을 합니다. 사용자의 80%는 해당 기능의 20%만 활용합니다. 따라서 기존 사용자를 유지하기 위해 해당 20% 기능을 최고 수준으로 만드는 데 중점을 두어야 합니다.

추가 코드에는 다음과 같은 단점이 있습니다.

• 애플리케이션의 복잡성을 증가시킵니다.
• 잠재적인 애플리케이션 충돌 지점이 될 수 있습니다.
• 제품 수명 주기 동안 추적 및 유지 관리에 불필요한 사후 노력이 필요합니다.

이 낭비를 줄이는 방법은 무엇입니까?
반복적인 개발에 집중하십시오. 즉, 초기 제품 릴리스 중에 애플리케이션의 USP를 정의하는 강력한 기본 기능을 구축하십시오.

제품을 기능적으로 만드는 데 집중하고 제품의 지속적인 발전을 확인하십시오. 또한 시장 분석, 소비자 행동 및 피드백을 기반으로 적절한 기능을 계속 구축하십시오.

4. 작업 전환

사람들이 불편하고 기존 프로세스를 방해할 때 여러 작업에 할당하는 데 많은 시간이 소요될 수 있습니다. 특정 작업 또는 두 가지를 완료하는 가장 효율적인 방법은 한 번에 하나씩 완료하는 것입니다.

작업 사이를 전환하는 동안 기존 작업을 닫고 다른 작업에서 추진력을 얻는 데 약간의 시간 비용이 발생합니다. 이를 컨텍스트 전환이라고 하며, 서로 간에 지속적인 전환이 예상되는 경우 이러한 콘텐츠 전환이 누적되어 지연됩니다. "결과" 또는 "배달 시간".

그것을 줄이는 방법?

단순 - 한 번에 하나씩.

• 콘텐츠 전환을 줄입니다.
• 방해나 산만함을 최소화하십시오.
• 중요하지 않은 것은 뒤로 미루세요.
• 리소스를 한 번에 하나의 프로젝트로 할당합니다.

5. 대기/지연

승인 종속성은 주로 제품 로드맵 중에 시간을 정해야 합니다. 특정 시간 간격이 할당되지 않은 경우 지연된 응답 및 피드백을 준비합니다. 지연은 또한 소비자가 제품의 실제 가치를 깨닫지 못하게 합니다. 그러나 개발자나 디자이너는 완료된 작업에 대한 승인을 기다려야 합니다. 따라서 시간 경과를 완전히 피할 수는 없습니다.

이것을 줄이기 위해 무엇을 할 수 있습니까?

• 기존 피드백을 기다리는 동안 무언가를 선택/할당합니다.
• 입력하고 검토할 시간을 할당하십시오.
• 변경 사항을 이메일로 보내기보다 빠른 전화, 직접 대면 대화를 고려하십시오.
• 정기적인 피드백.

6. 모션

개발 또는 연구 팀이 획득한 정보로 흩어져 있고 적절하게 표시/레이블을 지정하지 않은 경우 혼란과 드롭인을 흐리게 하는 데 영원히 걸릴 수 있습니다. 결과물이 전달될 때마다 정보가 잘못 배치된 경우 결과를 크게 저해할 것입니다.

그것을 줄이는 방법?

• 레이블 할당 또는 획득한 리소스.
• 피드백 타이밍을 줄입니다.
• 대면 협업.

7. 결함

결함으로 인한 낭비량 = (결함이 미치는 영향) x (검출되지 않은 시간)

소프트웨어 개발은 ​​그 복잡성으로 인해 불가피한 결함을 만들지만, 실행 및 고정이 오래 걸리거나 고정 또는 재작업에 따른 비용이 발생하는 경우 문제가 발생한다. 또한 주요 코드 오류 및 버그는 잠재적으로 전체 제품 수명 주기에 영향을 미치고 방해할 수 있으며 보안 위협에 취약하게 만들어 수백만 달러의 수익 손실을 초래할 수 있습니다.

이것을 줄이기 위해 무엇을 할 수 있습니까?

• 즉각적인 테스트.
• 지속적인 통합.
• 제품 테스트 및 최대한 빨리 출시.