금요일에 배치하지 않는 이유는 무엇입니까? [닫은]
Joel은 StackOverflow 팟 캐스트 # 24에서 금요일에 소프트웨어를 배송하지 않는 것이 FogCreek 회사 정책이라고 언급했습니다. 그러나 그는 그 이유에 대해 자세히 설명하지 않았습니다.
나는 동의한다. 제 고용주는 목요일 밤에 배치합니다. 따라서 금요일에 품질 보증 (QA)을 놓친 버그를 정리해야합니다.
그러나 관리자는 QA가 릴리스 전에 소프트웨어를 테스트 할 시간이 충분하지 않은 경우 금요일 밤에 배포 할 것을 제안했습니다. 사람들의 주말 계획은 어떻습니까? 그리고 금요일 밤에 배포하면 토요일에 누락 된 버그를 정리하기 위해 작업해야합니다.
그렇다면 금요일에 소프트웨어를 출시하지 않으시겠습니까?
* 우리는 (확실하지 않음)이 가정을해야 할 수도 있습니다. 회사의 핵심 웹 애플리케이션을 배포하는 한 시간대에 하나의 핵심 소프트웨어 개발 팀이 있습니다.
그것은 아닙니다 단지 버그의 문제. 사용자에게 새로운 기능을 설명하고 성능 문제가 없는지 모니터링하는 등 기타 관련 지원 부담이있을 수 있습니다.
새 릴리스는 일반적으로 지원 활동의 짧은 급증을 의미하므로 사용 가능한 사람이 적을 때 (또는 시간이 더 많이 소요될 때) 일정을 잡는 것은 좋지 않습니다.
다음과 같은 이유로 금요일에 배포하지 마십시오.
- 주말이라 사람들이 덜 예리 해
- 주말이어서 사람들이 버그를 고칠 수 없습니다.
- 주말이므로 질문에 답할 수 없습니다.
- 이번 주가 끝났는데 왜 배포하겠습니까?
당신은 당신 자신의 질문에 거의 대답했습니다. 그것은 짧고 달콤한 이유입니다. 만약 당신이 금요일에 출하하고 버그로 인해 생산에 들어가면 일반적으로 다음 월요일까지 그것을 고치거나 고객과 이야기 할 사람이 없습니다. 이는 최악의 시나리오에서 잠재적으로 며칠간의 수익 손실입니다.
우리는 목요일 이나 금요일 에 코드를 공개 하지 않습니다. 아무도 미션 크리티컬 버그를 찾는 데 금요일을 보내고 싶어하지 않습니다. 우리가 1 일 안에 수정 사항을 생성하더라도 릴리스되기 전에 적어도 하루가 더 남을 가능성이 있습니다. 주말에 일하거나 다음 주까지 고쳐지지 않는다는 뜻입니다.
대상 그룹에 따라 다릅니다. 주로 금요일에 배포합니다. 당사의 브라우저 기반 제품은 전 세계적으로 고객이 사용하지만 주로 업무 시간에 사용됩니다. 즉, 고객에게 영향을주지 않도록하려면 일요일 아침 외에 다른 시간이 없습니다 (인도 및 중동 지역은 토요일에 사무실에서 벗어나지 않음).하지만 일반적으로 "타협"합니다. 금요일 오후에 배치합니다.
이전에 데이트 사이트에서 일한 적이 있다면 화요일 쯤에 새로운 것을 배포하고 싶었던 데이트 사이트에서 일했다면, 활동은 주말에, 이상하게도 월요일 점심에는 정점에 도달했기 때문입니다.
어쨌든 두 가지 고려 사항이 있습니다. 1. 언제 고객에게 가장 지장을주지 않을 것인가 (웹 애플리케이션 인 경우) 2. 중요한 버그를 신속하게 수정하기 위해 개발 팀에 가장 적합한시기.
개발자가 주말에 엉망이 될까봐 걱정된다면 QA 파이프 라인이 너무 짧을 수 있습니다.
우리는 일반적으로 화요일에 배치하고 나머지 한 주 동안 문제를 해결합니다. 또한 주말에 작업이 없으면 금요일 저녁에 배포해도되지만 작업중인 경우에는 좋은 생각이 아닙니다.
사람들은 금요일 (이미 그 뜨거운 데이트 | 차가운 맥주 | 둘 다 생각하고 있음)과 휴가를 떠나기 며칠 전에 조금 더 엉성한 경향이 있습니다 ;-)
그것은 정말로 당신의 응용 프로그램과 주말에 얼마나 바쁘거나 중요한지에 달려 있습니다.
우리는 보통 금요일에 소프트웨어를 배포하지 않지만 토요일이나 일요일에 배포하는 경우가 많습니다. 릴리스의 영향을 최소화하기 위해 일요일 아침이 특히 좋습니다.
릴리스를 만드는 데 필요한 다운 타임의 영향을 최소화하려고하는지 아니면 잠재적 인 버그를 완화하려고하는지에 따라 다릅니다.
고객이 실제로 시스템을 사용할 때까지는 (대부분의 경우) 버그가 표시되지 않으므로 금요일에 배포하는 것은 주말에 사용량이 적은 경우 월요일 아침에 배포하는 것과 같습니다.
반면에 온라인 쇼핑과 같은 것은 주말에 더 많이 사용되는 경향이 있으므로 금요일에 배포하지 않는 것이 좋습니다.
또한 근무 시간 외 지원 정책에 따라 다릅니다. 소프트웨어를 롤백 할 수있는 누군가가 대기중인 경우 위험이 적습니다. 그래도 저는 근무 주중에 그렇게하고 싶습니다.
우리는 보통 화요일-목요일에 배포하며 월요일 (가장 바쁜 날)과 주말 (버그가 눈에 띄지 않고 문제를 일으킬 수있는 경우)을 피하는 것을 선호합니다.
당신은 해야한다 금요일에 배포 그래서 당신은 주말을 가지고 팀의 나머지 부분은 월요일에 당신의 부주의를 통지하기 전에 정리하고 수정 버그 할 수 있습니다.
토요일에 사무실에서 제대로 작동하는지 확인하지 않는 한 금요일 배포를 계획하지 않을 것입니다. 미끄러짐으로 인해 금요일에 배포를 끝내면 물건을 서두르는 위험이 큽니다. 기다리는 것이 훨씬 좋습니다. , 모든 사람이 주말 동안 진정하고 월요일 아침 검토 후 배송됩니다.
배포가 주말에 실행되는 경우 금요일 밤에 시작하면 사무실이 조금 더 일찍 정리되어 전체 시스템 부하가 월요일 아침보다 낮아지기 때문에 좋은 출발을 할 수 있습니다.
저는 금요일에 배포하는 정책이있는 회사에서 일했습니다. 그들은 이스라엘에 있었고 토요일은 보통 근무주의 마지막 날입니다. 어쨌든...
마지막 회사에서 정책은 늦어도 화요일과 목요일 점심 시간까지 Ops에 배포 패키지를 제공하는 것이 었습니다. 즉, 사전 라이브 QA의 마지막 단계에서 문제가 발생하면 반나절 동안 문제를 해결하고 사소한 조정을 요청할 수 있습니다. (다른 모든 QA는 라이브가 아니기 때문에 언제든지 발생할 수 있습니다.)
운영팀이 할 시간이 있다면 (물론 사전에 예약해야 함) 라이브를 제외한 모든 환경에 릴리스하는 것은 언제든지 괜찮지 만 라이브를 위해 릴리스하지 마십시오.
Monday- Bad, you've just come back from (hopefully a non-working) weekend and won't have everything you did last week in the front of your mind. Wednesday- Usually the least productive day of the week and sits as the "middle of the work" day. If your slot was Tuesday and you missed it due to bugs, Wednesday is probably a bad choice as you're not providing enough time to fix and test those bugs. Friday- Come on. Seriously? It's Friday. If this really needs explaining then you're not experienced enough to be doing the kind of managerial position you're in. But seriously, it's because deploying on Fridays means volunteering your clients to come in on the weekend to test your work in a live environment. For me, that beats any idiocy you might be lining yourself up for.
We are lucky enough to make good use of time difference, we have offices spread across the world. Thus when making updates to clients we arrange it so that it is done overnight for the customer so to minimize the impact on them.
this works well when you control the implementation and deployment of your software but releasing on a web site is another animal altogether. As others pointed out already make sure you allow time for :
- Supporting quirks and bugs that may occur
- Supporting users in the transitions
- Last minute hot fixes
참고URL : https://stackoverflow.com/questions/2115612/why-not-to-deploy-on-a-friday
'IT박스' 카테고리의 다른 글
| CSS 텍스트 선택 비활성화 (0) | 2020.09.05 |
|---|---|
| NameError (초기화되지 않은 상수 Paperclip :: Storage :: S3 :: AWS) : (0) | 2020.09.05 |
| 라텍스는 목록의 항목 사이에 공백을 제거합니다. (0) | 2020.09.05 |
| SQL 명령을 통해 MySQL 호스트 표시 (0) | 2020.09.05 |
| yyyyMMddHHmmss 형식을 사용하여 현재 시간을 포맷하는 방법은 무엇입니까? (0) | 2020.09.05 |