🎯 Definicja
Szybkie Dostarczanie (Deliver Fast) to zasada Lean, która nakazuje dostarczanie wartości w sposób wczesny i częsty. Celem nie jest pośpiech, ale jak najszybsze uzyskanie informacji zwrotnej (feedbacku) od użytkownika i rynku.
🔑 Kluczowe punkty
- Wcześnie (Early): Umożliwia feedback. Nawet niefunkcjonalna makieta pozwala zweryfikować założenia i uporządkować procesy (system dostarczania, kontrola wersji).
- Często (Often): Zmiana cyklu z kwartalnego na tygodniowy drastycznie zmniejsza presję. Jeśli funkcja nie jest gotowa, może poczekać tydzień, a nie trzy miesiące.
- “Jeśli boli, rób to częściej”: Jeśli wdrożenie jest stresujące i trudne, należy je zautomatyzować i powtarzać tak często, aby stało się rutyną.
📚 Szczegółowe wyjaśnienie
Szybkie dostarczanie wynika bezpośrednio z zasad tworzenia wiedzy i odraczania zobowiązań. Przejście na częste wydania wymusza zmianę sposobu pracy – nie można robić rzeczy “tak samo, tylko szybciej”. Trzeba robić rzeczy inaczej: automatyzować to, co wcześniej robiono ręcznie, i rezygnować z elementów, które nie są niezbędne.
Częste dostarczanie eliminuje marnotrawstwo czasu poświęcanego na przygotowanie ogromnych, rzadkich wydań, które niosą ze sobą ogromne ryzyko błędu i stresu.
💡 Przykład zastosowania
- Weekly Release vs Quarterly Release: W cyklu tygodniowym błędy są mniejsze, łatwiejsze do naprawy, a procesy wdrożeniowe muszą być w pełni zautomatyzowane, co podnosi jakość.
- MVP (Minimum Viable Product): Wypuszczenie podstawowej wersji funkcji, aby sprawdzić, czy klienci w ogóle jej potrzebują, zanim zainwestuje się miesiące pracy w pełne rozwiązanie.
- Automatyczne CI/CD: System, który po każdym pushu do repozytorium buduje i testuje kod, dostarczając natychmiastowej wiedzy o jego stanie.
📌 Źródła
👽 Brudnopis
The creating knowledge and defer commitment principles lead directly to another principle, deliver fast. In this context, fast means two related, but different things. One fast is obvious. We want to move quickly. In an agile context, this means delivering at the end of a sprint as opposed to working on a project for 6 months and only at the end revealing what has been wrought by it. By delivering fast, and what we really mean by fast is early, we are enabling feedback. Even if the only early delivery is a non‑functional mockup of a login page, I can tell you from experience the delivering just that will force you to get your delivery system in order, get your version control process straightened out, and will allow for conversations that might have come much later after much more work had been done and with much greater commitment. The other kind of fast I’m talking about here is often. Imagine you have a quarterly release schedule for a software product. Take a moment to consider what that process might look like. And now, imagine what changes when you move to a weekly release schedule. A manager might panic. We have so much stress and work organized around those quarterly releases. Doing that weekly might give him a heart attack. The reality is if you had to release weekly, once again, you wouldn’t do things differently. You’d do different things entirely. First and foremost, if you’ve got another weekly release coming next week, the pressure is off. And a feature that’s not quite cooked can and should just sit out another week. But more fundamentally, it’s just not going to be possible to do all that work that goes into a full calendar quarter’s preparation for a release. So things that didn’t make sense to automate before will have to be automated. And things which were perhaps desirable, but not strictly necessary, will have to be done away with altogether. And here’s another big principle. If it hurts, do it often. Again, if it hurts, do it often, especially the painful parts. I’m a big believer in fear‑driven development in the sense that you look for the one part of your code processes or whatever that gives you a bad feeling in the pit of your stomach, and you do that first. Repeat over and over again until there is no such part of your code or processes.