🎯 Definicja
🔑 Kluczowe punkty
📚 Szczegółowe wyjaśnienie
💡 Przykład zastosowania
📌 Ź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.