금요일에 배치하지 않는 이유는 무엇입니까? [닫은]

Joel은 StackOverflow 팟 캐스트 # 24에서 금요일에 소프트웨어를 배송하지 않는 것이 FogCreek 회사 정책이라고 언급했습니다. 그러나 그는 그 이유에 대해 자세히 설명하지 않았습니다.

나는 동의한다. 제 고용주는 목요일 밤에 배치합니다. 따라서 금요일에 품질 보증 (QA)을 놓친 버그를 정리해야합니다.

그러나 관리자는 QA가 릴리스 전에 소프트웨어를 테스트 할 시간이 충분하지 않은 경우 금요일 밤에 배포 할 것을 제안했습니다. 사람들의 주말 계획은 어떻습니까? 그리고 금요일 밤에 배포하는 경우 토요일에 누락 된 버그를 정리하기 위해 작업해야합니다.

그렇다면 금요일에 소프트웨어를 출시하지 않으시겠습니까?

* 우리는 (확실하지 않음)이 가정을해야 할 수도 있습니다. 회사의 핵심 웹 애플리케이션을 배포하는 한 시간대에 하나의 핵심 소프트웨어 개발 팀이 있습니다.

그것은 아닙니다 단지 버그의 문제. 사용자에게 새로운 기능을 설명하고 성능 문제가 없는지 모니터링하는 등 기타 관련 지원 부담이있을 수 있습니다.

새 릴리스는 일반적으로 지원 활동의 일시적인 급증을 의미하므로 사용 가능한 사람이 적을 때 (또는 시간이 더 많이 소요될 때) 일정을 잡는 것은 좋지 않습니다.

다음과 같은 이유로 금요일에 배포하지 마십시오.

1. 주말이라 사람들이 덜 예리 해
2. 주말이어서 사람들이 버그를 고칠 수 없습니다.
3. 주말이므로 질문에 답할 수 없습니다.
4. 이번 주가 끝났는데 왜 배포하겠습니까?

당신은 당신 자신의 질문에 거의 대답했습니다. 그것은 짧고 달콤한 이유입니다. 만약 당신이 금요일에 출하하고 버그로 인해 생산에 들어가면 일반적으로 다음 월요일까지이를 고치거나 고객과 이야기 할 사람이 없습니다. 이는 최악의 시나리오에서 잠재적으로 며칠간의 수익 손실입니다.

우리는 목요일 이나 금요일 에 코드를 공개 하지 않습니다. 아무도 미션 크리티컬 버그를 찾는 데 금요일을 보내고 싶어하지 않습니다. 우리가 1 일 안에 수정 사항을 생성하더라도 릴리스되기 전에 적어도 하루가 더 남을 가능성이 있습니다. 주말에 일하거나 다음 주까지 고쳐지지 않는다는 뜻입니다.

대상 그룹에 따라 다릅니다. 주로 금요일에 배포합니다. 당사의 브라우저 기반 제품은 전 세계적으로 고객이 사용하지만 주로 업무 시간에 사용됩니다. 즉, 고객에게 영향을주지 않도록하려면 일요일 아침 외에 다른 시간이 없습니다 (인도 및 중동 지역은 토요일에 사무실에서 벗어나지 않음).하지만 일반적으로 "타협"합니다. 금요일 오후에 배치합니다.

이전에 데이트 사이트에서 일한 적이 있다면 화요일 쯤에 새로운 것을 배포하고 싶었던 데이트 사이트에서 일했다면, 활동은 주말에, 이상하게도 월요일 점심에는 정점에 도달했기 때문입니다.

어쨌든 두 가지 고려 사항이 있습니다. 1. 언제 고객에게 가장 방해가되지 않을 것인가 (웹 애플리케이션 인 경우) 2. 중요한 버그를 신속하게 수정하기 위해 개발 팀에 가장 적합한시기.

개발자가 주말에 엉망이 될까봐 걱정된다면 QA 파이프 라인이 너무 짧을 수 있습니다.

우리는 일반적으로 화요일에 배치하고 나머지 한 주 동안 문제를 해결합니다. 주말에 작업이 없으면 금요일 저녁에 배포해도되지만 작업중인 경우에는 좋은 생각이 아닙니다.

사람들은 금요일 (이미 그 뜨거운 데이트 | 차가운 맥주 | 둘 다에 대해 생각하고 있음)과 휴가를 떠나기 며칠 전에 조금 더 조잡 해지는 경향이 있습니다 ;-)

그것은 정말로 당신의 응용 프로그램과 주말에 얼마나 바쁘거나 중요한지에 달려 있습니다.

우리는 보통 금요일에 소프트웨어를 배포하지 않지만 토요일이나 일요일에 배포하는 경우가 많습니다. 릴리스의 영향을 최소화하기 위해 일요일 아침이 특히 좋습니다.

릴리스를 만드는 데 필요한 다운 타임의 영향을 최소화하려고하는지 아니면 잠재적 인 버그를 완화하려고하는지에 따라 다릅니다.

고객이 실제로 시스템을 사용할 때까지는 (대부분의 경우) 버그가 표시되지 않으므로 금요일에 배포하는 것은 주말에 사용량이 적은 경우 월요일 아침에 배포하는 것과 같습니다.

반면에 온라인 쇼핑과 같은 것은 주말에 더 많이 사용되는 경향이 있으므로 금요일에 배포하지 않는 것이 좋습니다.

또한 근무 시간 외 지원 정책에 따라 다릅니다. 소프트웨어를 롤백 할 수있는 누군가가 대기중인 경우 위험이 적습니다. 그래도 저는 근무 주중에 그렇게하고 싶습니다.

우리는 보통 화요일-목요일에 배포하며 월요일 (가장 바쁜 날)과 주말 (버그가 눈에 띄지 않고 문제를 일으킬 수있는 경우)을 피하는 것을 선호합니다.

당신은 해야한다 금요일에 배포 그래서 당신은 주말을 가지고 팀의 나머지 부분은 월요일에 당신의 부주의를 통지하기 전에 정리하고 수정 버그 할 수 있습니다.

토요일에 사무실에서 제대로 작동하는지 확인하지 않는 이상 금요일 배치를 계획하지 않았습니다. , 모든 사람이 주말 동안 진정하고 월요일 아침 검토 후 배송됩니다.

배포가 주말에 실행되는 경우 금요일 밤에 시작하면 사무실이 조금 더 일찍 정리되어 전체 시스템 부하가 월요일 아침보다 낮아지기 때문에 좋은 출발을 할 수 있습니다.

저는 금요일에 배포하는 정책이있는 회사에서 일했습니다. 그들은 이스라엘에 있었고 토요일은 보통 근무주의 마지막 날입니다. 어쨌든...

마지막 회사에서 정책은 늦어도 화요일과 목요일 점심 시간까지 Ops에 배포 패키지를 제공하는 것이 었습니다. 즉, 사전 라이브 QA의 마지막 단계에서 문제가 발생하면 반나절 동안 문제를 해결하고 사소한 조정을 요청할 수 있습니다. (다른 모든 QA는 라이브가 아니기 때문에 언제든지 발생할 수 있습니다.)

운영팀이 할 시간이 있다면 (물론 사전에 예약해야 함) 라이브를 제외한 모든 환경에 릴리스하는 것은 언제든지 괜찮지 만 라이브를 위해 릴리스하지 마십시오.

월요일-나쁜, 당신은 방금 (휴업하지 않는) 주말에서 돌아 왔고 지난주에 당신이 한 모든 것을 마음 앞에 두지 않을 것입니다. 수요일-일반적으로 일주일 중 생산성이 가장 떨어지는 날이며 "작업 중간"일로 사용됩니다. 슬롯이 화요일이고 버그로 인해 놓친 경우 해당 버그를 수정하고 테스트 할 충분한 시간을 제공하지 않으므로 수요일은 잘못된 선택 일 것입니다. 금요일-어서. 정말? 그것은 금요일. 이것이 정말로 설명이 필요하다면, 당신은 당신이 속한 관리직을 수행하기에 충분한 경험이없는 것입니다.하지만 진지하게, 그것은 금요일에 배치하는 것은 당신의 클라이언트가 주말에 와서 당신의 작업을 라이브로 테스트하기 위해 자원하는 것을 의미하기 때문입니다. 환경. 나를 위해, 그것은 당신이 자신을 줄 수있는 어떤 어리 석음보다 뛰어납니다.

우리는 시차를 잘 활용할 수있을만큼 운이 좋으며 전 세계에 사무실이 있습니다. 따라서 고객에게 업데이트를 할 때 고객에게 미치는 영향을 최소화하기 위해 고객이 하룻밤 사이에 완료되도록 조정합니다.

이것은 소프트웨어의 구현 및 배포를 제어 할 때 잘 작동하지만 웹 사이트에 배포하는 것은 완전히 다른 동물입니다. 다른 사람들이 이미 지적했듯이 다음과 같은 시간을 허용하십시오.

1. 발생할 수있는 문제 및 버그 지원
2. 전환에서 사용자 지원
3. 마지막 순간 핫픽스