Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agile Is Dead, Long Live Continuous Delivery

gradle.org

Post reply on HN
Print view View original

141–150 of 157 posts

Re: Agile Is Dead, Long Live Continuous Delivery

#141

Post by novembermike »

wsc981 wrote: post #117
lostcolony wrote: post #65

Earlier quoted context omitted.

So the way I have always handled it - Product owners create stories. These are titled things like "As a (type of user), I want to be able to X". The point of the title is to determine who this actually benefits. Then, they attempt to define it with acceptance criteria. These are a list of "what does it mean to solve this need". Ideally, it implies a set of tasks, and gives a decent starting point for QA to start test…

What always annoyed me about Story Points is that it's a measure of complexity, not time. At least that's what Story Points are supposed to stand for. When you state that a team should know how many Story Points it can handle, it would make much more sense to see Story Points as some measure of time. If you've completed last few Sprints 38 to 42 Story Points, with 2 full-time devs, than one could state that a single…

The problem is that time isn't something you can chop up neatly.

For ease of use, let's say that a story point represents 8 hours of actual work. That gives us 168/8 points a week, or 21 points. Of course, we lose 7 of those to sleep, 4 to the weekend and another 5 to the evenings during the week, leaving us with 5 points per week. You probably lose a point to lunch, coffee, bathroom breaks and mingling with coworkers and another point to meetings and interruptions.

That leaves you with 3 points out of 21 potential points in a week, and you aren't getting 3/5 done per day. Using story points instead of hours tries to get people to treat the sprint as a unit instead of time as a unit, since time can be split up to a very fine degree. Just because you work 40 hours a week doesn't mean you can complete 20 2 hour tasks.

Re: Agile Is Dead, Long Live Continuous Delivery

#142

Post by vlehto »

I used to study construction engineering and now I work in construction. "Waterfall" is still in use and going strong. Applying that directly to coding seems bit stupid.

I then swithed major to mechanical engineering, and there "toyota production system" is the thing. Agile and lean are just taking the underlying idea bit further. The original idea is to eliminate intermediate storages. This happens by making every production cell to order shit from previous production cells via kanban card. Previous idea was to just optimize volumes of every cell while giving zero fucks who, when and why the product was needed. But even inside the realm of mechanical engineering this sometimes is plain stupid. For example the workflow of large castings doesn't follow rythm of manufacturing cells. It follows the rythm of curing molds, heating metal and waiting the metal to cool down. What is "Agile" in software seems to follow TPS somewhat. You do one unit of work, you cash that in and start on second one. Id guess it's just coincidence that short compiling times and intermediate storage elimination happened during same timeframe and that resulted one term for both "agile".

I have very limited experience on coding, but neither of the previous seem to fix any underlying hard problems in coding. When I code, I struggle with interfaces, specs, debugging and data flow. The only thing that comes close to coding is design of mechanical parts. But that has lot less degrees of freedom. And there seems to be pretty much zero management fads applied to mechanical design anymore. The only thing everybody is saying is that "try to keep open mind in the beginning of process. And spend some serious time defining your problem, because that's what affects total costs most". The rest is just going by gut feeling.

We have ISO and ASME, but still interfaces are some of the most tricky subjects around in mechanical design. I'd expect the next meaningfull paradigm for coding to focus on interface design, as it's the one that requires communication between human beings. And it sets limits to what individual coders can achieve.

"Never stand between craftsman and his professional pride" Quote by Kalevi Aaltonen, but I guess he got it from somewhere.

Re: Agile Is Dead, Long Live Continuous Delivery

#143

Post by Silhouette »

blowski wrote: post #107
barrkel wrote: post #56

Earlier quoted context omitted.

The trouble with waterfall is that it tries to predict beyond the scope of a sprint, which just isn't valid. This assertion is nonsense. There's nothing magical about a couple of weeks such that it forms a boundary outwith lie impossible predictions. The validity of predictions depend entirely on the understanding of the problem domain and the complexity of the solution space. The single biggest benefit from agile in…

If you've got a bunch of good, productive developers, you've got to work really hard to get anything but good software out of them. They will probably self-organise into an effective team, whatever the methodology. On the other hand, if you have a bunch of inexperienced, mediocre developers (myself included) then "bite-size stories being fed on a conveyer belt" is probably a good way to get productivity out of them.…

If you've got a bunch of good, productive developers, you've got to work really hard to get anything but good software out of them. They will probably self-organise into an effective team, whatever the methodology.

I'm sure there is an element of truth to this, but I doubt it's as decisive as you're suggesting in real life.

If you've got a good team of expert developers, people who are both individually skillful at producing useful code but also good team players and able to co-operate, I'd say you have a decent chance of them self-organising. I'd omit the "whatever the methodology", because these are exactly the kinds of teams who don't want or need some consultant's pet methodology limiting their options.

Of course, there is more to building useful real world software projects than just producing a good design and implementation. Even the most technically brilliant team also needs a clear goal to be effective in practice. Capturing the requirements and turning them into actionable specifications is a significant challenge in its own right, one which requires a very different skill set that even exceptional developers won't necessarily have.

I suggest that one of the big differences between a highly skilled and experienced team and a team with more modest capabilities is that the former will immediately recognise the need for clear specs and try to do something about the lack of them. The kinds of development processes and methodologies we're talking about today are designed in part to shield the latter from the same responsibility, but consequently they also rely on having very good people to do that work instead (and by corollary tend to fail hard if the communication with customers and resulting planning work aren't up to standard for whatever reason).

Re: Agile Is Dead, Long Live Continuous Delivery

#144

Post by jcrites »

timv wrote: post #94
jheriko wrote: post #48

Earlier quoted context omitted.

http://agilemanifesto.org/ http://agilemanifesto.org/principles.html From the very first. > Individuals and interactions over processes and tools Have you seen this in practice and experienced how people work day-to-day? Leave them to their own devices and it varies a lot by personality. Some people need micro-management for instance... there is also thing that process is very important, and this point is self contra…

I think one's assessment of the manifesto is largely dependent on how generously you read it. > Individuals and interactions over processes and tools needs to be read in conjunction with: > while there is value in the items on the right, we value the items on the left more Which means I can interpret it a way that is true , but not that interesting. That is, I believe that a great developer with crappy tools will pro…

"Individuals and interactions" is not saying "hire good people", although I can see why you could read it that way. I've always understood it to be saying, "Get people together in a room and talk and figure out what to do", instead of "rigidly follow an arbitrary process".

For example, let's say that we did some project planning a month back, which says that we should start on a certain new project tomorrow. Everyone on the team is grumbling and no longer feels like that's a wise expenditure of resources. What should we do? Stick to our goal and follow the process, or get people together, work it out, and set new goals? Agile is saying, especially when you consider other bullets like "Responding to change over following a plan", that people subscribing to the Agile Manifesto value getting individuals together, collaborating, and responding to change more than following their plan.

Re: Agile Is Dead, Long Live Continuous Delivery

#146

Post by amptorn »

coldtea wrote: post #44

"Continuous Delivery", huh? Yeah, let's replace one consulting fad (the 4 or 5th I've seen in my career, I entered when "Waterfall" was still in vogue, then XP, then Agile, some variations of each too) with another. How about this methodology: http://programming-motherfucker.com/

That methodology is awful. And kind of embarrassing.

Re: Agile Is Dead, Long Live Continuous Delivery

#147

Post by mywittyname »

WWKong wrote: post #90

There will be many comments pointing, "agile works great when implements the right way". While that might be true I'm willing to bet good money that agile has turned out to be really bad for 90%+ of the teams. I tried hard to save my org from agile and failed. Everything crashed and burned soon after.

This is my experience too. Companies bring in agile consultants to tell them how to release software better. But things never improve, and in two years, they do it over again (but with a different buzzword).

If your company has trouble developing software, the problem has nothing to do with development processes. The problem is always management.

Re: Agile Is Dead, Long Live Continuous Delivery

#148

Post by vorg »

geodel wrote: post #123

I don't know what to think about it. The gradle.org website screams consulting with its slickness and free user guides/books etc. It does not look like honest, no-nonsense build software. The source code is about 6000 Java files + 3200 groovy files besides many others. To me it appears excessive and over designed software. I will be very reluctant to use a build software which needs 300+ pages user guide. TBH it is e…

After James Strachan was knifed 2 years after he created Apache Groovy, that ecosystem has been all about consulting and conferences. Software such as Grails and Gradle is shoved down people's throats with promises of managing complexity and giving users choices, but in reality these tools add complexity and the documentation obscures. Then the sales calls start touting conferences and paid services to manage it all.

Re: Agile Is Dead, Long Live Continuous Delivery

#149

Post by vorg »

morgante wrote: post #93

I stopped reading at "Agile had a great run in it’s youth by taking on some obviously bad practices such as 'Waterfall' software development." Nothing about waterfall is obviously bad. It's how most engineering projects are done. Heck, it's how most projects generally in the world are done. There's a reason it took a long time to move away from waterfall. It solves obvious problems and meshes with how the rest of cor…

> We are now more squarely in the age of Microservices, Mobile first, Polyglot, post-Java JVM languages

Gradle provides only one language, i.e. Apache Groovy on the JVM, for specifying build configuration info. Before talking about "Polyglot, post-Java JVM languages", perhaps Gradleware needs to eat its own dogfood and provide an API so users can write their build configs in Jython or JRuby if they want. Be polyglot before preaching it.

Re: Agile Is Dead, Long Live Continuous Delivery

#150

Post by nessus42 »

joeblau wrote: post #110
nessus42 wrote: post #11

Earlier quoted context omitted.

Yes, we use Kanban where I work. We've been doing "continuous delivery" and "DevOps" for years. It's not bad, but I still don't really like scrums.

What's "DevOps"?

It's when you do software development for services that are constantly changing and need to be up all the time, and you are not only responsible for the development, but also for the services being up all the time.
Post reply on HN