당기는 원리는 무엇입니까? 소프트웨어 개발의 풀 원칙

당신이 방금 일을 마쳤고 당신의 배가 으르렁거린다고 상상해보세요. 그래서 당신은 재빨리 슈퍼마켓에 가서 당신이 좋아하는 “토마토 소스를 곁들인 파스타” 요리의 모든 재료를 구합니다. 열심히 일하는 슈퍼마켓 직원은 시간이 나면 즉시 선반을 보충합니다. 이 예는 끌어오기 원칙을 정확히 설명합니다. 자원(이 경우 파스타와 토마토 소스)을 끌어오면 직원이 빈 공간을 채웁니다. 1분 안에 구매하세요. 끌어오기 원칙을 사용하면 필요할 때마다 리소스를 사용/뽑을 수 있습니다.

그러나 파스타와 토마토 소스가 소프트웨어 개발과 무슨 관련이 있습니까?

풀 원칙은 무엇이며 애자일 소프트웨어 개발에서 어떻게 작동합니까?

당기기 원칙은 현재 많은 산업 분야에서 대표되는 린 경영 철학의 기본 원칙 중 하나입니다. 이것은 무엇보다도 생산, 행동 또는 서비스가 고객에 의해 시작됨을 나타냅니다. 소프트웨어 개발의 경우 개발자는 필요할 때만 소프트웨어 작업을 시작합니다. 예를 들어, 일상적인 작업 중에 새로운 범위의 기능이 완벽하게 마무리될 것이라는 것을 알게 된 잘 실행되는 웹 응용 프로그램이 있습니다. 이것이 소프트웨어 회사에 대한 티켓을 만드는 방법이며(자세한 내용은 나중에 설명) 개발자는 이 티켓으로 계속 작업할 수 있습니다.

미는 원리에 비해 당기는 원리의 장점은 무엇입니까?

요약하면 풀 원칙은 실제로 필요한 수요에 대한 조치와 서비스를 수행하고 추측이나 예측에 따라 조치를 취하지 않도록 합니다. 회사에서는 불필요한 비용을 피할 수 있고 프로젝트 프로세스가 개선됩니다. 또한 실제 수요에만 서비스를 제공하기 때문에 제 시간에 작업을 완료하는 것이 훨씬 쉽습니다.

푸시 원칙에서는 예상 수요가 충족되지만 실제 수요와 일치하지 않는 경우가 많습니다. 이로 인해 예기치 않게 비용이 많이 들 수 있는 비용이 발생합니다. 가상의 최악의 시나리오에 대한 약간의 사고 실험: 내부 작업 프로세스를 자동화할 수 있는 새로운 비즈니스 웹 응용 프로그램을 개발하도록 우리에게 맡기고 사전에 Excel과 이메일을 통해 모든 것을 정리했습니다. 프로젝트를 수락하고 이미 웹 응용 프로그램을 사용하고 있는 후 열성적인 직원 중 한 명이 파일 업로드가 있으면 좋을 것이라고 기억합니다(아직 필요하지 않음). 그래서 그는 개발자에게 가서 이 파일 업로드를 가능한 한 빨리 프로그래밍하도록 요청합니다. 이것은 그것을 프로그래밍하고 정상적인 작업을 수행하기 위해 초과 근무를 해야 합니다. 모닝 커피를 마시는 동안 그의 팀 동료가 현재 전력을 다하지 않고 있는 것이 눈에 띕니다.

그런 식으로 작동해서는 안 됩니다. 그렇죠? 이 사고 실험은 푸시 원칙이 사전 제작 및 과잉 생산을 통해 더 높은 가능한 요구(아마도 이 파일 업로드를 원했을 것임)로부터 스스로를 보호하려고 한다는 것을 보여주었기 때문입니다.

이것은 당신이 우리에게 연락하여 이 작업을 제공하고 시간이 있는 개발자가 이 작업을 수행할 수 있는 끌어오기 원칙의 반대입니다. 당기기 원칙에서는 낭비적인 작업을 피하고 개발자가 자신의 중요한 작업에 집중하여 시간 내에 작업을 완료할 수 있습니다.

당김 원칙의 관리는 어떻게 생겼습니까?

민첩한 프로젝트 관리의 일부이기도 한 Kanban 시스템을 사용합니다. 컬럼당 수행되는 작업을 제한함으로써 최적의 워크플로 및 품질 보증이 항상 보장됩니다. 우리는 다음 7개의 열로 작업합니다.

  • to-do(생성, 아직 편집되지 않음)
  • 진행 중
  • 검토
  • 검토 중(품질 보증 진행 중)
  • 검토 완료(품질 보증 성공)
  • 배치하다, 파견하다
  • 완료

“To-Do”열에서 열려 있고 필요한 작업이 설정됩니다. 이는 고객, 제품 소유자 또는 이 경우 개발자가 직접 설정할 수 있습니다. 사용 가능한 다음 직원이 이 티켓을 받아 “진행 중” 열로 옮깁니다. 이러한 방식으로 프로젝트에 관련된 모든 사람은 누가 현재 이 작업에 적극적으로 참여하고 있는지 알 수 있습니다. 그러나 직원은 정의된 최대 티켓 수를 초과하지 않는 경우에만 다른 티켓을 처리할 수 있습니다. 상담원이 티켓을 처리하면 티켓을 ‘검토하기’로 옮깁니다. 여기에서 대기 중인 다른 직원이 작업/티켓이 올바르게 완료되었는지(검토 중) 확인할 수 있습니다. 왜냐하면 네 눈은 항상 두 눈보다 더 잘 보기 때문입니다. 모든 것이 정확하면 소프트웨어 확장/변경 사항이 게시되는 “배포” 열로 티켓이 이동됩니다. 게시가 완료되면 “완료” 열에서 티켓이 닫히는 것을 볼 수 있습니다.

멀티태스킹은 가정에서 가능할 수 있지만 솔직히 말해서 한 가지 일을 100% 정확하고 빠르게 하지 않고 동시에 많은 일을 하려고 합니다. 개발자가 매번 “코드에 대해 생각”해야 하는 경우 혼자서는 피할 수 있는 시간이 경과됩니다. 이 단일 작업 모델에서 그는 항상 하나 또는 몇 가지 작업에 집중하고 최적으로 완료한 다음 새로운 작업을 맡을 수 있습니다.

당기기 원리의 장점

우리는 내부 및 외부 프로젝트 모두에서 오랫동안 끌어오기 원칙을 사용하여 작업해 왔습니다. 우리는 다음과 같은 이점을 발견했습니다.

  • 업무 효율성 향상
  • 사전 제작이 없으므로 노력이 최소화됩니다. 이렇게 하면 팀의 용량과 비용을 더 쉽게 예측할 수 있습니다.
  • 특정 기간 동안 얼마나 많은 작업을 수행할 수 있는지 예측할 수 있는 평가 가능한 데이터
  • 자원은 지속 가능하게 사용됩니다
  • 초과근무는 피한다
  • 워크플로의 유연성

당기는 원리가 당신에게도 적용될 수 있는지 궁금하십니까? 귀하의 메시지를 기다리며 귀하의 업무 프로세스를 최적화하기 위해 개별적으로 그리고 개인적으로 기꺼이 조언해 드릴 것입니다.

About admin

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다