this post was submitted on 05 Jun 2024
413 points (94.4% liked)

Programming

16971 readers
243 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS
(page 3) 39 comments
sorted by: hot top controversial new old
[–] autotldr@lemmings.world 2 points 3 months ago (1 children)

This is the best summary I could come up with:


Even though the research commissioned by consultancy Engprax could be seen as a thinly veiled plug for Impact Engineering methodology, it feeds into the suspicion that the Agile Manifesto might not be all it's cracked up to be.

One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed.

"Our research has shown that what matters when it comes to delivering high-quality software on time and within budget is a robust requirements engineering process and having the psychological safety to discuss and solve problems when they emerge, whilst taking steps to prevent developer burnout."

A neverending stream of patches indicates that quality might not be what it once was, and code turning up in an unfinished or ill-considered state have all been attributed to Agile practices.

One Agile developer criticized the daily stand-up element, describing it to The Register as "a feast of regurgitation."

In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates.


The original article contains 501 words, the summary contains 175 words. Saved 65%. I'm a bot and I'm open source!

[–] TheGiantKorean@lemmy.world 1 points 3 months ago

Someone would look at our process and say "that's not agile!" and they might be correct, technically speaking. I don't personally care what it's called as long as it works.

We agree to requirements up front with our customer; we might change stuff as we go along if our customer realizes that what they asked for won't work (this happens occasionally), which is fine, but otherwise we don't let them change stuff around on a whim, and we don't allow scope creep. If they want a new feature, that's version 2 (or 3, or 4).

We don't meet very frequently. We do check in to make sure we're on target, and deliver features incrementally when it makes sense to do so. We do sprints. We talk about when things are working and when they aren't, but only when we think it's a good time to do so.

At the end of the day, you need to tailor the process to your needs and what makes sense to you and your team.

[–] Omgboom@lemmy.zip 1 points 3 months ago

Lol I'm going to send this to my project manager

[–] sentient_loom@sh.itjust.works 0 points 3 months ago (1 children)

Should I remove my Agile experience from my resume?

[–] MajorHavoc@programming.dev 1 points 3 months ago

Time to replace it with AI experience! /sarcasm... Mostly

load more comments
view more: ‹ prev next ›