2 ms·

You're wrong on both accounts: (1) Being able to estimate with laser-like accuracy is not part of what's agile. Estimation is not part of the agile manifesto a

You're wrong on both accounts: (1) Being able to estimate with laser-like accuracy is not part of what's agile. Estimation is not part of the agile manifesto at all - Kanban for example can be done without a single estimate. It just limits the number of tasks that you have in parallel. Scrum on the other hand does deal with estimates, but it mainly postulates that you can't estimate large chunks of work at all and small chunks not necessarily correct. So there are all kinds of observed correction metrics built in that help you to get a better estimate - no one vouches for a correct one though. (2) If you can't use TDD because you have to build a whole set of mock object you might have a tightly coupled system. Writing a test is not dead line count, it helps to formulate boundary conditions and expected behavior. It's certainly not useful for all kinds of project but it's certainly not limited to security sensitive or tricky algorithms. If the behavior is simple, then the test is simple as well. If the behavior is complicated, then the test will be as well - but at least you'll think about how it is supposed to be.

PaulHoule 15y ago
My own "agile" process for certain kinds of development involves breaking down all tasks to less than an hour and estimating time to 10 minute granularity and planning on weekly releases. For boring web apps built on the right framework I find this keeps everybody very happy. Devs aren't chasing their tails, you can make and keep promises to the client, etc. Of course you've got to be building the kind of app where there aren't surprises, but those exist. As for the other project, the whole thing is a machine where you put a 600 million fact knowledge base in one end and it manufactures 'potempkin villages' (little knowledge bubbles about particular domains w.r.t a point of view) on the other end. Once it's done, I could use it to generate micro test cases for the rest of the system, but in the short term that doesn't bring in revenue or delight customers.

PaulHoule 15y ago

My own "agile" process for certain kinds of development involves breaking down all tasks to less than an hour and estimating time to 10 minute granularity and planning on weekly releases. For boring web apps built on the right framework I find this keeps everybody very happy. Devs aren't chasing their tails, you can make and keep promises to the client, etc. Of course you've got to be building the kind of app where there aren't surprises, but those exist. As for the other project, the whole thing is a machine where you put a 600 million fact knowledge base in one end and it manufactures 'potempkin villages' (little knowledge bubbles about particular domains w.r.t a point of view) on the other end. Once it's done, I could use it to generate micro test cases for the rest of the system, but in the short term that doesn't bring in revenue or delight customers.