[–]▶ No.1007147>>1007602 >>1008763 >>1008787 [Watch Thread][Show All Posts]
This is insane, I'm so sick of trying to build reliable software and being told it's 'out of scope' until it eventually bites us in the ass. Clients are idiots why the fuck do we have to be at their mercy? You can't block us for months and then suddenly expect us to pull some magic out of our ass for your barely documented, proprietary, legacy system when the contract's almost up and you finally decide to reply to an email. Add to that the fact that oops you also forgot to mention a piece of critical information you can't launch without.
This stuff should be known upfront. If you don't know what you want you have no business getting a system built.
▶ No.1007222
It's definitely Agile that's the problem, not your AAA team.
▶ No.1007598>>1007611
I love how you're supposed to orient everything in your tracker around user stories, so you have to have some workaround for actually addressing architecture, data layout/schema, perf, etc.
▶ No.1007602>>1007613 >>1008685 >>1015385
>>1007147 (OP)
What is agile anyway? I keep seeing new terms everywhere.
▶ No.1007611>>1008737
>>1007598
The whole point is iterative development. Not everything in the product backlog has to be written in terms of a user story.
▶ No.1007613>>1007621
>>1007602
>agile
>new
That bullshit has been around for ages. It's a worthless meme which only non-coder execs can appreciate.
▶ No.1007621>>1007630 >>1008180
>>1007613
>which only non-coder execs can appreciate
"Coder" here. I appreciate it, for those projects that are very large and are being implemented from a client vision, and have a lot of stakeholders and require developers with many various expertise.
A lot of "coders" get turned off from it because of shitty implementations of Agile, wherein each sprint is more like a mini-waterfall.
▶ No.1007630>>1007650 >>1008529
>>1007621
>A lot of "coders" get turned off from it because of shitty implementations of Agile
>b- but it wasn't TRUE Agile!
▶ No.1007650>>1008126
>>1007630
I'm going to give you the benefit of the doubt and assume you are from /trannypol/, parodying what a retard would say.
▶ No.1007670
When I was at my internship, my boss insisted we were an agile shop, and that we did 2 week sprints. We had the whole atlassian suite and everything. I was the only person on my team though, so I just delivered what I could when I could.
I could see agile working for a team of professionals, who know each other and what they're doing, but I suspect its overkill when you just need to slap a web interface on "save text to files", "grep files", "display files".
▶ No.1008126>>1008288
>>1007650
lmao the absolute state of tech, agile is pure liberal cultist shit
▶ No.1008163
>I'm so sick of trying to build reliable software and being told it's 'out of scope' until it eventually bites us in the ass.
this. agile is literally just "hurr durr let's split up our problems into small easily addressable pieces", and then when they come across an "EPIC", shit is fucked. Agile doesn't even have any meaning. people are just like "i'm agile!", and then they start doing a bunch of pretend processes and software dev is no different than before except what was mentioned above.
▶ No.1008180
>>1007621
Fuck Agile. Our team fails to deliver every Sprint goal because it is unnatural for software development. If I have to do 1 more faggy estimation with cards, someone is gonna eat a bullet, probably my project manager.
▶ No.1008188>>1008196 >>1008552
>isn't doing agile properly
>complains about it
pajeet-tier argument
▶ No.1008196
>>1008188
>>thinking anyone is doing agile properly when whole point is to create shortcuts
▶ No.1008266
holy shit scrum and agile are fucking autism
▶ No.1008272
When agile is done right, it's a pleasure. Happy client, happy team.
▶ No.1008273
Agile was created for man, not man for Agile. If you're slavishly following rules and processes, you're misusing Agile.
▶ No.1008285>>1008553
agile is good with a client that actually knows what to do
▶ No.1008288
>>1008126
Aye, and I'll show you a true scottish agile
▶ No.1008382>>1008481 >>1008543
It's not a No True Scotsman fallacy because you can point to actual agile projects, which are successful, and the criteria for determining as such is not ad hoc.
▶ No.1008481
>>1008382
>because you can point to actual agile projects, which are successful
all that proves is that Agile doesn't always completely fuck everything up
▶ No.1008529
Threads like this remind me that I am not insane. Agile is driving me into an early grave and everyone around me laughs because "You just don't get it! Agile is great! Way better than the old system!"
>>1007630
This shit is so true its ridiculous. Any valid argument I make is cock blocked by this garbage or by "It's better than before"
▶ No.1008543
>>1008382
>because you can point to actual agile projects, which are successful
no you fucking can't. nothing made in the generation of agile is good. name one piece of software so i can laugh at your gay ass. literally all they accomplished is replacing the menu with a hamburger icon
▶ No.1008552>>1008559
>>1008188
No one can do agile properly, it's a bunch of unspecific garbage and no one can agree on what it means.
▶ No.1008553>>1008555
>>1008285
Yeah but the whole idea behind agile was that the customer doesn't know what they want. If the client knows what they want agile is pointless because you can do most of the planning upfront and be very clear on what needs doing.
▶ No.1008555>>1008679 >>1008681
>>1008553
Precisely this. Everybody bitching about agile seems to miss that, or has never built a big beautiful infrastructure only to have the client make a "slight" adjustment to their requirements, thus rendering all of the work useless.
▶ No.1008557>>1008559 >>1016461
Agile is obviously shit, but what do we replace it with? The reason companies like agile is because it makes them attractive to the customer since the customer doesn't have to be as responsible.
▶ No.1008559>>1008582
>>1008552
It's very common that system requirements change as development occurs over time. All agile means is that developers can respond to the changes as they are requested.
>>1008557
The question is how do you deal with changing system requirements over the development of the project? Do you let the project cost blow out to double or triple the original estimates that assume the requirements remain static? The fact is that the earlier in the project that you change the requirements, the cheaper in the long run that the project will cost; and also the later in the project that you change the requirements, the more expensive in the long run that the project will cost.
▶ No.1008560>>1008581 >>1008679
Agile is not shit, you're shit. You guys sound like MGTOW incels, projecting your personal failures onto the world around you.
▶ No.1008581>>1008588
>>1008560
>Everyone I disagree with is a MGTOW incel
>>>/leftypol/
▶ No.1008582>>1008588 >>1008589 >>1008763
>>1008559
What actually prevents project demands from being made immutable?
▶ No.1008588
>>1008581
>cross-comparing the objects of a metaphor rather than the relations
Double-digit IQ confirmed.
>>1008582
The project is serving the business needs of a client, which are dynamic and based on their vision, company politics/employee turnover, and customer feedback.
▶ No.1008589>>1008621
>>1008582
Theoretically, you could agree that any requirements gathered in the analysis stage of the project will remain immutable. In practice, what this means is the client would probably receive a software solution that doesn't quite accurately fulfill their needs. The reason for this is because clients don't necessarily understand every single minute detail (as well as the consequences of each detail) of their information processes and therefore, they won't advocate for those details. It would be the system analyst's responsibility to draw this kind of detail out from the stakeholders.
▶ No.1008621>>1008625 >>1008763
>>1008589
Then you'd start a new project to refactor the initial product, clearly outlining your criticisms.
▶ No.1008625>>1008828
>>1008621
That is more time and money spent to get the same result (at best) as an iterative process. This is why good client project managers will not use waterfall.
▶ No.1008679
▶ No.1008681>>1008687
>>1008555
>the client make a "slight" adjustment to their requirements, thus rendering all of the work useless.
How does Agile prevent this? Agile doesn't eliminate the need for software architecture, it just takes it out of the trackers. The client can easily render all the "Agile" work useless just the same as any other organization method. And generally speaking, if your architecture can't support new features (that aren't wildly out of scope), what the hell were you doing? Or are you really just saying to make everything microservices (hint, that's just the Unix philosophy rebranded) It's like you've mixed five different issues together and labeled the mythical solution as "Agile."
▶ No.1008685>>1008686 >>1008829 >>1016821
>>1007602
All it means is that they use trello or some equivalent kanban-cuck software to "organize". It's retarded bloat created in an attempt to make females and female derivatives feel like they are doing something worthwhile with company time.
▶ No.1008686
>>1008685
or sticky notes if they're literal niggers
▶ No.1008687>>1008752
>>1008681
>Agile doesn't eliminate the need for software architecture, it just takes it out of the trackers.
No it doesn't.
>The client can easily render all the "Agile" work useless just the same as any other organization method.
Not without contradicting the acceptance criteria of previous sprints. Deliveries should fail-fast; that's not possible in a waterfall.
>Or are you really just saying to make everything microservices.
No, but it's the same principle but applied to process instead of architecture.
▶ No.1008691
Before Agile there was Excel, and it was good.
Tell us dear Agile pros and black belt faggots, how is the state of software today? Your name is on the mess. You own it all.
▶ No.1008737
>>1007611
We just write stories that read: "As a developer, I want..."
▶ No.1008752>>1008761 >>1008763
>>1008687
>Not without contradicting the acceptance criteria of previous sprints. Deliveries should fail-fast; that's not possible in a waterfall.
Nobody ITT has said anything about waterfall other than Agile cultists. All you're saying here is that you are delivering small features quickly. Agile didn't patent that. You don't need shitty children's card games, "user stories," or weird names for normal things (meetings are SCRUM now!!) to do that.
▶ No.1008761>>1008780 >>1015011
>>1008752
There is no agile patent on anything. Agile is the name of one type of iterative software development to support the agile change in requirements as development occurs. People are bitching that agile is a problem when it's not. It's one solution to the real problem of stakeholders who cannot communicate the complete entirety of requirements at the very beginning of software development.
▶ No.1008762
I don't, in theory, have anything against agile. The customer doesn't know what they want, and the best way to give it to them is in small steps.
The problem that I have is that my organization is so beholden to time-boxes that a coworker has had time to read The Name of the Wind in the space between sprints over the last month, because we have under committed to the sprints that bad (stories have been over pointed due to risks that have not manifested) and have not accounted for it.
▶ No.1008763>>1008780
>>1008752
>Nobody ITT has said anything about waterfall other than Agile cultists
>>1007147 (OP)
>This stuff should be known upfront. If you don't know what you want you have no business getting a system built.
>>1008582
>What actually prevents project demands from being made immutable?
>>1008621
>Then you'd start a new project to refactor the initial product, clearly outlining your criticisms.
▶ No.1008780>>1008787
>>1008761
>Agile is the name of one type of iterative software development to support the agile change in requirements as development occurs. People are bitching that agile is a problem when it's not.
Agile is a problem in and of itself because it is stupid and infantile. When people talk about software development like they're a bunch of gradeschoolers, it makes them think stupid. People begin putting methodology above the practical reality-- it's a dogma. Ironically, it's more "agile" to simply have no set methodology at all. Programmers should do what makes sense and works in the given situation.
>>1008763
People are responding to your hackneyed scenarios. Again, iterative development can't save you from total overhaul demands, and it can't save you from having spaghetti architecture that doesn't grow or refactor properly. In fact, Agile encourages spaghetti by heavily emphasizing nebulous features rather than data layouts.
▶ No.1008787
>>1008780
>People are responding to your hackneyed scenarios.
>>1007147 (OP)
>This stuff should be known upfront. If you don't know what you want you have no business getting a system built.
▶ No.1008828>>1008830
>>1008625
They might not use waterfall, but something like RAD seems much more reasonable than Agile. At least this way it's likely you'll actually ship something on time.
▶ No.1008829
>>1008685
>female derivatives
▶ No.1008830
>>1008828
Use the right tool for the job. RAD has its place, as does Agile.
▶ No.1008833
Probably helps if software developers and QA are sent on Agile courses. It helped me. No system is perfect but as long as everyone agrees (Product Owner, Scrum Master and Dev/QA) on what the deliverables are each sprint generally it should work. Whatever doesn't work needs to be raised in retrospectives.
If Scrum isn't working for the team, consider Kanban.
I find Agile fails if the team is bad or you have a bad scrum master (my current situation).
▶ No.1015011>>1015109 >>1015162
>>1008761
>It's one solution to the real problem of stakeholders who cannot communicate the complete entirety of requirements at the very beginning of software development.
>be stakeholder
>don't know what I want
>can't come to consensus with other stake holders
>hire a programming company anyway
>offload the task of finding requirement consensus to the programming company
>at regular intervals, get presented partially developed products that make obvious that we didn't give them clear instructions
>be dissatisfied with programming company
>hire another company next time
>be programming company
>get vague request from customer
>customer doesn't really know what they want
>offer to do rapid iteration releases and spend time on creating fake mockups so the customer can realise sooner that their requirements were shitty and incoherent
>your employees want to kill themselves, but have family
▶ No.1015013>>1015109
How to make software great again: Create a new oppucation, the project demand mediator (PDM). Stakeholders then discuss, with the PDM, their user stories and visions. The PDM then steers the whole vision towards a coherent specification, which is then passed to the programming company (and not earlier). The programming company then makes a development plan, optimises it, and starts developing. The programming company can still give regular (every 25% of the way maybe?) status reports and presentations to the customer, they can then, via the PDM, make minor adjustments to the plan.
This way, almost all responsibility lies with the customer, and the programming company is actually kind enough to give status updates from time to time to give the customer the chance to detect their own failures early.
The PDM is a coder, but needs social skills. He knows how to understand the thought processes of different kinds of people. He knows how to moderate a discussion.
If there still are some parts of the specifications that are unclear, they will be left out, or a lowest common denominator of all possible approaches is chosen to be implemented.
▶ No.1015109>>1015156
>>1015011
Ah yes, if only the client were more considerate of the code monkey who's going to be punching the keys, rather than his own business needs, amirite?
>>1015013
>Create a new oppucation, the project demand mediator (PDM).
It already exists; embed related. However, you're not going to see a lot of business analysts these days, because most code shops are domain-oriented and can therefore understand the client's needs without one, spending the money on something more useful instead. Again, it would be autist paradise to have a middle man to bridge every specialty, but budgets are a thing.
▶ No.1015156>>1015377
>>1015109
It's not about being considerate, it's about being efficient. Every failed iteration wastes time and money. Laying out the requirements to a reasonably complete state early on in the process makes sure the budget isn't wasted in unproductive developer time when it could be invested in something else.
>Again, it would be autist paradise to have a middle man to bridge every specialty
Bullshit. Autists hate bureocracy. It's the normalfag managers who want to have more useless procedures in place.
▶ No.1015162
>>1015011
That kind of scenario isn't so common but it does happen. For that scenario where the company's information processing requirements run on black magic, I would offer a couple of directions as solutions.
The first one is a matter of iterative prototyping of software to run for a few months. For example I'd continually write a series of protoype software for the period of six months. That is probably enough time to work out a reasonable set of specifications. I'd be writing the complete system after that time of exploration.
The second one is to break up the project into phases. In the first phase, I'll write a series of small tools that perform small and well defined tasks. These tools are not intended to be integrated into a single cohesive system. This process gives me significant insight about the requirements. If the system I've delivered adequately meets the business requirements, my job ends there. Otherwise, the next phase of the job is to refactor or recreate the system into an integrated whole.
▶ No.1015377
>>1015156
>Bullshit. Autists hate bureocracy.
Sure, but they also love to have a single-minded focus on actual programming.
▶ No.1015385>>1015406 >>1015439 >>1016461
>>1007602
waterfall means taking forever to release a new version
example: windows 98, then windows 2000
agile means releasing a new small update all the time
example: some app that gets updates multiple times per month, as opposed to slow and huge updates
▶ No.1015406>>1015409
>>1015385
>Waterfall: Internal Beta testing
>Agile: User Beta testing
Agile is fucking cancer for everyone apparently
▶ No.1015409>>1015415
>>1015406
the next generation methodology will skip testing, then coding altogether.
▶ No.1015415
>>1015409
some agile people talk about pushing to production multiple times per day
it's not no testing, you just do automated testing, such as with selenium
▶ No.1015422>>1015425 >>1016888 >>1016904
<test-driven development
<continuous integration
<continuous delivery
<docker
<DevOps
fml
▶ No.1015425
>>1015422
These are just names of ideas. If you have your own personal way to develop and deliver your software efficiently, then good for you. However if you ever need to work within a team of developers, there will need to be a way to coordinate formal ways of getting shit done. That's why these techniques and tools get created.
▶ No.1015439>>1015444
>>1015385
Bad example, since Windows 2000 was one of the best operating systems ever made.
▶ No.1015444>>1016549 >>1016901
>>1015439
using it as an example for slow releases
1998 -> 2000 is 2 years, which is forever by agile standards
with agile, you're supposed to make lots of small updates/releases rather than a few big and infrequent ones
windows used to have service packs, which were big updates that came out every now and then
agile encourages people to build iteratively and to meet deadlines
agile is all about deadlines, waterfall (the slow old stuff) is about features and program-related stuff
guess which is better for budget-oriented project managers? agile, by far
"oops, we can't ship on time" is a very common thing with waterfall
with agile, it's "well we met the deadline but we couldn't finish all the optional features and there are still a couple quirks"
▶ No.1016461
>>1015385
>agile means releasing a new small update all the time
No that's what "incremental" means.
>>1008557
>Agile is obviously shit, but what do we replace it with?
Competent programmers who read books and don't need tutorial videos to create Hello World.
▶ No.1016549>>1016568 >>1016905 >>1017153
>>1015444
>Focusing on the program is bad
>Ship something half-assed instead
▶ No.1016568>>1016818 >>1016895 >>1017153
>>1016549 Is "she" a guy? She doesn't have boobs. Maybe she is a trap!
▶ No.1016818
>>1016568
Nah you can see her boobs they're just pretty small
▶ No.1016821
>>1008685
>female derivatives
got me good. nice one anon
▶ No.1016888
>>1015422
Thats a 100% hit rate for my last working environment which I left for various reasons
▶ No.1016895>>1017158
>>1016568
>see picture of female
>immediately fixated on what's under her clothes
never change, /tech/
▶ No.1016901
>>1015444
>1998 -> 2000 is 2 years, which is forever by agile standards
But they didn't jump from Win98 straight to Win2000. Actually, the progress at that time was from Win98 to WinXP, and it was much more gradual:
>1998: Win98
>1999: Win98SE
>early 2000: Win2000
>late 2000: WinMe
>2001 WinXP
Bretty agile for MS standards.
▶ No.1016904>>1016906
>>1015422
>DevOps
Is that that meme position name which is supposed to be developer, QA, sysadmin, network admin and service desk rolled all into one, where the physical employee is treated like a hypervisor upon which various roles are stacked like virtual machines?
▶ No.1016905
>>1016549
waterfall: don't ship at all
agile: ship an imperfect project
which is better, buddy?
▶ No.1016906>>1017156
▶ No.1017153
>>1016549
>>1016568
>Is "she" a guy? She doesn't have boobs. Maybe she is a trap!
Kek. You simpleton didn't even notice that the mouse is to the LEFT of the keyboard. She's obviously a LARPer.
Also, what man has so little muscle? Her arms are like fucking twigs.
▶ No.1017156>>1017239
>>1016906
>We will strive to be a better partner by valuing what you value:
FUCKING CUCKS
>Security Science over FUD
What.
>Open Contribution & Collaboration over Security-Only Requirements
CoC
>Consumable Security Services
Like, edible?
>24x7 Proactive Security Monitoring
>proactive monitoring
??
Is this actually serious?
▶ No.1017158
>>1016895
>have a penis
>be female
things that never happened
kys
▶ No.1017239
>>1017156
>CoC
That's not what that refers to, brainlet. You're in over yourhead.