Che cosa sono gli "gating bugs" in mischia?

Nella maggior parte dei casi, "gating" è essenzialmente sinonimo di "blocco" - cioè, una cosa è impedire a qualcos'altro di procedere. Oltre a ciò, c'è una implicazione di una recinzione su entrambi i lati del cancello - in altre parole, questo non è solo un blocco, ma è qualcosa che è difficile da seguire o aggirare, quindi non è possibile (per esempio) basta prendere in giro questo pezzo fino a quando il bug è stato risolto.

Un esempio ovvio potrebbe essere qualcosa di estremamente fondamentale per tutto nel sistema. Ad esempio, supponiamo che tu avessi un sistema scritto in Java, ma stavi usando una macchina virtuale personalizzata - allora qualcuno ha cercato di ottimizzare (ad esempio) l'allocatore di memoria, ma ha introdotto un bug in modo che il tentativo di allocare un oggetto, è soggetto a crash l'intero sistema. Non si può davvero prendere in giro l'allocazione della memoria e non si può testare nulla in modo affidabile. Sei contro il muro e non puoi procedere oltre fino a quando il bug non viene corretto.

[No, non intendo prendere su Java in particolare - un'altra macchina virtuale che è disponibile in forma open-source potrebbe portare esattamente allo stesso tipo di problema con altrettanta facilità, e ovviamente ci sono tutti i tipi di altri problemi pure - questo sembra essere un esempio particolarmente estremo.]

Il termine "gating bug" o "gating" non fa parte della terminologia di Scrum. Un cancello è qualcosa che sta bloccando il progresso in avanti. Un termine simile è "blocco bug".

Un uso comune di gate nella gestione del progetto è il modello a gate di fase , che definisce fasi chiare e distinte del progetto e ha porte che il progetto deve attraversare per poter continuare. È diverso da un esempio di bug, dal momento che un gate è spesso un'attività pianificata e non qualcosa che viene scoperto o si pone durante il corso di un progetto.