제조업에 비해 소프트웨어 개발에는 고유한 특징이 있습니다. "린 사고"는 방법과 실제 수준에 해당하며 목표에 맞는 적응이 필요합니다.
소프트웨어 제품 개발과 제조 제품 개발의 차이점은 다음과 같이 분류할 수 있습니다. 1) 가치의 불확실성 2) 프로세스의 불확실성. 가치 불확실성은 다음과 같이 반영됩니다. 1) 고객 가치 자체가 불확실하고 처음부터 정확하게 정의할 수 없으며 언제든지 진화하고 있습니다. 2) 업계는 급격한 변화와 불확실성을 겪고 있습니다. 위의 다양한 불확실성에 반영된 본질은 한 가지로 요약될 수 있습니다. 즉, "변화"는 소프트웨어 개발의 핵심 주제이며, 이는 린 소프트웨어 개발이 "반복 능력"을 강조해야 하며 조직 모델이 더 평면화되어야 한다고 결정합니다. . 소프트웨어 개발의 프로세스 불확실성은 모든 소프트웨어 프로젝트의 개발 프로세스가 어느 정도 창의적인 프로세스라는 점에서 반영되며, 실제로 상당한 양의 구체적인 작업 세부 사항을 미리 결정할 수 없습니다. 소프트웨어 개발 엔지니어의 핵심 가치 중 하나입니다.
소프트웨어 개발 프로젝트에 린 사고를 적용하면 비즈니스 성공을 소프트웨어 프로젝트 테스트의 유일한 기준으로 삼는 것입니다!
린 사고는 풀 생산(Pull Production), 즉 사용자 가치 풀(User Value Pull)을 강조합니다. 이는 다운스트림 요구사항을 업스트림 생산 링크로 시기적절하고 정확하며 효율적으로 전달하는 것뿐만 아니라 가치 흐름을 허용하는 것이기도 합니다. 어떤 흐름이 사용자가 원하는 가치인지 확인해야 합니다. 이를 수행하는 가장 좋은 방법은 가장 다운스트림 고객 가치(예: 사용자 주문)가 전체 가치 흐름을 주도하도록 하는 것입니다. ——은행 정보 기술의 생산과 관련하여 제품 및 서비스에 대한 사용자 요구에 직접적으로 영향을 받는 정보 기술 및 기타 작업을 개발하는 것이 필요합니다. 여기서 "사용자 요구"와 "비즈니스 부서 요구"는 다음과 같습니다. 구별하기 위해 사용자는 은행의 최종 사용자(공공 및 민간)를 나타냅니다.
은행 정보 기술 업무가 항상 은행 전체 운영 체제에서 백엔드 지원 역할에 빠지기 쉬운 이유는 무엇입니까? 근본적인 이유 중 하나는 정보기술학과가 사용자 가치에 대한 직접적인 인식이 부족하다는 것입니다. 소위 기술 부서의 대응 요구는 최종 사용자 가치의 실현 및 흐름에 대한 어떠한 개입이나 책임도 없이 전적으로 비즈니스 부서의 아이디어에 대한 응답입니다.
이는 정보기술부 단독으로는 변경할 수 없습니다.
물론 사업부서에서도 매우 안타까워하고 있지만 시장 대응과 고객의 요구를 파악하기 위해 열심히 노력하고 있으며, 요구 사항을 구체화하여 기술에 전달하기 위해 최선을 다하고 있습니다. 부서, 기술 부서를 적극적으로 홍보하여 또 다른 좋은 주문형 전달 시스템을 신속하게 진행합니다. 또한, 시장 수요를 가장 효과적으로 충족시키기 위해서는 최전선 연결고리로서 사업부서의 필요성과 중요성은 의심할 여지가 없습니다.
무엇이 문제인가? ?
전통적인 은행 구조에서는 기술 부서가 비즈니스 부서 뒤에 격리되어 사용자 가치 전달에 직접 참여하는 것은 물론 사용자의 직접적인 요구에 직접 접촉할 필요도 없다고 판단하기 때문입니다. 시나리오.
He Mian이 "린 앤 애자일의 첫 번째 원칙과 확장된 구현"이라는 기사에서 지적한 것처럼 조직 구조 모델이 가치 흐름 모델을 결정합니다. 따라서 조직 구조 모델의 근원부터 사용자 가치의 요구에 따라 전체적인 배치가 이루어져야 합니다. 사업부와 정보기술부 사이의 순서와 관계는 바뀌어야 한다. 기술부가 사업부를 책임져서는 안 되며, 사업부가 시스템의 최종 수용자가 되어서는 안 되며, 전적으로 시스템을 책임져서는 안 된다. 시스템의 최종 시장 효과 기술 부서와 비즈니스 부서는 모두 애자일 팀의 구성원이어야 하며 서로에 대한 컨설턴트 역할을 해야 합니다. 기술 부서는 비즈니스 설계를 위한 기술 컨설턴트이며 비즈니스 부서는 비즈니스입니다. 기술 부서의 컨설턴트로서 양 당사자가 협력하여 사용자 가치에 직접적으로 기여해야 합니다.
비즈니스 성공(작은 성공에서 큰 성공까지, 단순한 성공에서 복잡하고 체계적인 성공까지)이 프로젝트를 테스트하고 수락하는 유일한 기준입니다. 코디네이터 역할이 있는 경우 제품 관리자(또는 Agile 팀의 프로젝트 관리자)입니다.
발췌 1. 린 사고의 세 가지 수준인 가치, 방법론, 실행 세트를 이해합니다.
값: 2001년에 출판된 16페이지 분량의 "Toyota Way" "Toyota Way – 2001". 이는 사람에 대한 존중과 지속적인 개선이 린 가치의 핵심임을 확증합니다.
이 두 가지 테마에는 현 상태에 대한 도전, 카이젠(kaizen), 지속적인 개선을 위한 겐치 겐부츠(genchi genbutsu), 사람 존중(존경과 팀워크)이라는 다섯 가지 가치가 포함됩니다. "고객에게 폐를 끼치지 마십시오" - 생산의 다음 연결 고리도 고객입니다.
방법론: "린 사고"는 린의 5가지 원칙을 요약하며, 이는 또한 5가지 구현 단계이기도 합니다.
프랙티스 세트: 가치관부터 프랙티스 세트까지, 그 운용성은 점점 더 강해지고 있으며, 동시에 산업 특성은 점점 더 강해지고 있으며, 그 다양성은 점점 더 낮아지고 있습니다. Toyota의 린 제조 TPS에 관한 한, Kanban(적시 지원을 위한 중요한 도구), "1분 금형 교체" 등 다양한 성공적인 실제 방법이 포함됩니다.
발췌 2. 제품 개발과 제품 제조의 차이점:
발췌 3. 린 제품 개발의 목표, 방법론 및 관행:
목표: 매끄럽고, 고품질, 유용한 가치
방법: 유용한 가치를 탐색 및 발견하고, 가치 흐름을 원활하게 합니다. - 가치 흐름의 효율성에 집중하고 향상시킵니다.
Ohno는 사용자 가치에 중점을 두고 있으며, 가치가 흘러가는 과정을 낭비라고 합니다. 이는 사용자의 입장에서 볼 때 의미 없는 행동과 기다림을 모두 의미합니다. 이는 "모든 조직의 성과는 외부에서만 반영될 수 있다"는 Drucker의 말과 일치합니다. 이 아이디어는 제품 개발에도 적용됩니다.
가치 흐름 효율성에 중점을 두고 개선하는 것이 린 제품 개발의 원칙이며 린 제품 개발과 기존 개발 방법의 또 다른 본질적인 차이점이기도 합니다.
실습 : 경영실습과 기술실습으로 구분됩니다.
경영 실천의 첫 번째 부분은 가치 발견, 검증, 탐구의 문제를 해결하는 린 스타트업 및 혁신 실천입니다. 두 번째 부분은 린(Lean) 요구사항 분석 및 관리 실무로, 요구사항을 효과적으로 분할, 계획, 분석 및 전달하는 방법에 대한 문제를 해결합니다. 세 번째 부분은 Lean Kanban 방법의 실천입니다.
DevOps를 중심으로 기술 실무를 개발할 수 있습니다.
첨부발췌 4. 자기卍
1. 卍자는 인간 옆에 있는 글자로 자기卍를 의미한다. 자동화는 최종 테스트 링크에 의존하기보다는 품질을 보장하기 위해 모든 링크에 의존하는 "Build Quality In"의 기초입니다.
2. 시간 엄수와 셀프 서비스는 모순되는 통일성입니다.
발췌 5. Agile의 원래 의도
Agile의 원래 의도를 잊지 않고 비즈니스 목표를 기억하는 것이 중요합니다. 즉, 가치를 더 일찍 제공하고 변화에 더 유연하게 대응하는 것입니다.
발췌 6. 전통 소프트웨어의 역설
가장 중요한 결정은 지식이 가장 부족할 때 내려지며 나머지에 대한 벤치마크로 사용됩니다. 이것이 바로 지식 축적 사이의 역설입니다. 전통적인 개발 하에서 의사결정 시간.
프로세스 자체가 복잡해지는 경향이 있고, 소프트웨어 개발에 매우 중요한 사람들의 주도권이 억제됩니다.