우리는 작업에 대한 원칙을 공유하고 싶습니다. Django 웹 개발 회사 그것은 우리의 연습의 수년 동안 형성되었습니다. 그들의 목표는 결과 달성의 효율성을 높이는 것을 목표로 하는 사고 방식을 만드는 것입니다.
이 기사는 초보자와 젊은 팀에게 유용합니다. 원칙은 모든 개발 프로세스 및 도구에 쉽게 적용됩니다. 그것들은 본질적으로 작업이 무엇인지, 어떻게 작업해야 하는지에 대한 이해를 기반으로 합니다.
여기서 작업은 특정 "작업"과 "기능" 또는 "서사시"를 모두 나타냅니다. 부풀려지지 않도록 텍스트의 원칙에 대한 해석의 예는 없습니다. 개별 논문의 본질을 조금 더 넓게 드러낼 수 있는 몇 가지 추천 자료를 남겨두고, 나머지 질문은 댓글로 답해 드리겠습니다.
목표 오리엔테이션
왜 모든 작업에는 목표가 있습니까? 그것을 달성하는 과정이 효과적이기 위해서는 원하는 결과가 왜 필요한지 작업에서 명확해야합니다. 문제 공식화에 유용한 질문:
- 어떤 결과가 나와야 합니까?
- 왜 이런 결과가 필요했을까요? 무엇을 위한 것입니까? 누구에게, 어떤 가치를 가져다 줄까요?
- 문제가 해결되었음을 이해하는 방법(결과를 얻음)?
개발 중인 시스템 사용자의 요구와 특성 및 비즈니스 목표를 고려하여 이러한 질문을 하십시오. 사용자나 고객의 입장에 서십시오. 어렵지만 배울 수 있습니다. 경험 많은 동지의 가정을 시도하고 확인하십시오.
작업을 설정한다는 것은 무엇을 의미합니까?
생각하고 설명:
- 목적, 필요 또는 문제.
- 원하는 결과입니다. 목표에 맞추십시오. 결과가 달성에 기여하는지 확인하십시오.
- 타이밍 또는 기술과 같은 제약 조건.
작업은 수행자, 저자, 테스터 및 해결에 관심이 있는 기타 사람들에게 동등하게 명확해야 합니다. 일반적으로 수용되는 개념에 의존하고 이중 해석을 배제하며 충분하지만 중복되지 않습니다. 한편으로는 출연자에게 불필요한 제약을 주어서는 안 된다. 반면에 결과에 대한 중요한 요구 사항을 놓치지 않을 필요가 있습니다.
작업을 수락한다는 것은 무엇을 의미합니까?
- 필요한 결과와 목적을 이해합니다. 서로 최적의 통신에 동의합니다.
- 시간 또는 솔루션의 최대 복잡성 측면에서 작업의 제한 사항에 동의합니다.
- 명시된 한도 내에서 결과를 달성하는 데 책임을 집니다.
작업을 설정하는 사람은 작업을 설정할 책임이 있습니다. 그러나 작업을 수락하기 전에 해당 문구에 영향을 미치고 작성자와 함께 토론하고 수정할 수 있습니다.
문제에 불확실성이 존재하면 항상 위험이 따릅니다. 작업을 수락하기 전에 작업 전략을 이해하십시오.
만들다은 무슨 뜻인가요?
작업은 실행 결과가 의도한 대로 사용할 준비가 되었을 때 "완료"되고 추가 작업이 필요하지 않습니다. 작업을 "거의 완료"할 수 없습니다. 완료되었거나 다른 상태입니다. 테스트를 위해 제출된 작업은 아직 완료되지 않은 작업이기도 합니다.
작업을 완료했다고 주장하는 경우 추가 테스트, 배포 및 검증이 필요하지 않으며 작업 결과를 사용할 수 있음을 의미해야 합니다. 반대의 경우도 마찬가지입니다. 추가 작업이 필요하지 않고 결과가 예상되는 이점을 가져오는 경우 작업이 완료되었으며 완료 상태로 전환되어야 합니다.
작업이 특정 순간에 완료되어야 한다고 말하면 그 시간에는 테스트 및 수락을 포함하여 수명 주기의 필요한 모든 단계를 통과해야 합니다. 작업을 제 시간에 완료하려면 마감일 전에 "제출"을 시작해야 합니다.
이 원칙은 계획에도 적용되어야 합니다. 테스트, 디버깅 등을 고려하여 문제를 해결하는 데 드는 시간과 노력의 이름을 지정하십시오.
여과 효율
부가가치 결과는 빠르면 빠를수록 좋습니다. 피드백이 더 빨리 나타나고 품질 관리, 기대치, 프로젝트 전체가 더 효과적입니다.
완료를 향해 작업을 이동합니다. 한 가지 지위에 얽매이거나 한 아티스트에게 축적되어서는 안 됩니다. 이는 결과 달성의 효율성을 감소시키는 문제의 증상입니다.
성능 원칙을 유지하려면 "건강한" 분해가 필요합니다.
필요에 따른 분해
작업 분해는 전체 결과를 얻는 효율성을 높이고 프로젝트 관리 프로세스를 단순화해야 합니다.
분해의 좋은 수준은 각 작업의 결과가 프로젝트의 전체 결과 및 품질의 달성을 제어하는 데 사용될 수 있을 때입니다. 동시에 중간 결과의 출현은 목표 달성 과정을 늦추지 않습니다. 작업이 작을수록 작업 간에 전환하는 데 더 많은 주의가 산만해집니다.
커뮤니케이션을 위한 시간 추적
업무에 소요된 시간을 기록해야 하는 경우 의사소통에 소요된 시간을 고려하십시오. 문제와 이에 대한 논의에 익숙해지는 것은 솔루션 프로세스의 일부입니다. "대화"를 위해 별도의 작업을 시작해서는 안됩니다.
예를 들어, SaaS 프로그래머(https://www.softformance.com/services/saas-development/), 디자이너와 개발자 사이의 예는 이 디자인을 개발하는 작업의 일부입니다. 커뮤니케이션은 협업 도구입니다. 그러나 문제 해결의 복잡성을 고려하는 것도 필요합니다. 때로는 코드를 작성하는 것보다 알아내고 동의하는 데 더 많은 시간이 걸립니다. 괜찮습니다.
