|
B-Nasty posted:Just go ahead and publish a translation table that states how many hours every point is worth so that Agile can devolve the way it always does. My team skipped this and went straight to estimating hours. 1 point is 1 hour. Also our "iterations"/"sprints" last months and every single bug in the backlog always ends up being a requirement of the current sprint. We don't meet for days, occasionally weeks. I feel like my experience with agile so far has been people using it as an excuse to axe random ideas about how to run the projects. "Oh that's not agile!" Unless the point being made is actually about agile and then it's "We don't need to be strictly agile!" I had little to no experience with agile going into my current job and somehow feel like I know even less about it now. This isn't a thing I seem to have any power to fix and I have no idea who really would. I feel like I have no idea what agile really is, but I am pretty sure that most of the people I work with don't either. I guess we're supposed to have daily stand-up meetings, involve subject-matter experts and stakeholders in the process/meetings, and do incremental releases quite frequently. I don't think any of those things are happening. wilderthanmild fucked around with this message at 03:47 on Apr 6, 2017 |
#
?
Apr 6, 2017 03:24
|
|
|
|
| # ? May 10, 2024 03:34 |
|
|
My tech lead linked me this in hipchat yesterday. https://www.youtube.com/watch?v=nvks70PD0Rs e: Also the CTO got walked out today. Haha that's what you get for promising 12 months of work in only 6 months, shithead! Oh nice. Our deadline was extended by 2 whole sprints. 
Gildiss fucked around with this message at 04:01 on Apr 6, 2017 |
|
#
?
Apr 6, 2017 03:58
|
|
|
wilderthanmild posted:I feel like I have no idea what agile really is, but I am pretty sure that most of the people I work with don't either. I guess we're supposed to have daily stand-up meetings, involve subject-matter experts and stakeholders in the process/meetings, and do incremental releases quite frequently. I don't think any of those things are happening. You do, however, have a great idea of what agilefall is now.
|
|
#
?
Apr 6, 2017 04:34
|
|
|
Scrum is such a piece of poo poo though. I can't loving stand it. The pointless ceremony, the constant masturbation, the "self-organising team" bullshit... It's awful and actively makes my job worse.
|
|
#
?
Apr 6, 2017 10:58
|
|
|
For me, the only essential part of being agile is being able to release working, valuable software often. There are a million ways to achieve that. FIxed-length iterations or story points are by no means required and I doubt they are even helpful. Messyass fucked around with this message at 11:23 on Apr 6, 2017 |
|
#
?
Apr 6, 2017 11:06
|
|
|
ratbert90 posted:Git-lfs is a thing. Since we were talking about github will they do git lfs backing store of more than 20 gigs? If not you still need your own solution.
|
|
#
?
Apr 6, 2017 12:11
|
|
|
lovely dickheads putting their fingers in the project and dev team will happen no matter what methodology you adopt. Waterfall, "agile", whatever. The point is to tell people who shouldn't be involved to gently caress off as much as possible. I cannot think of a single good project experience I've had. They're all awful.
|
|
#
?
Apr 6, 2017 12:24
|
|
|
wilderthanmild posted:My team skipped this and went straight to estimating hours. 1 point is 1 hour. Also our "iterations"/"sprints" last months and every single bug in the backlog always ends up being a requirement of the current sprint. We don't meet for days, occasionally weeks. There's really not much to agile, and most people shilling it don't know what it is so... http://agilemanifesto.org http://agilemanifesto.org/principles.html If your 'agile' is all about process it simply isn't. All the people selling management cure-all snake oil aren't interested in making your org run better; they're interested in supporting the extant beliefs of management and raking in cash.
|
|
#
?
Apr 6, 2017 12:26
|
|
|
Sometimes I think people forget what true old school waterfall was like. Like the whole process of writing all the requirements before a single line of code, and that those requirements were binding on both sides (dev and customer.)
|
|
#
?
Apr 6, 2017 12:44
|
|
|
smackfu posted:Sometimes I think people forget what true old school waterfall was like. Like the whole process of writing all the requirements before a single line of code, and that those requirements were binding on both sides (dev and customer.) Now we get all that plus the business gets to add more scope in the middle and they get to choose the delivery date. And managers get to micromanage even more. It's a real win-win.
|
|
#
?
Apr 6, 2017 13:03
|
|
|
smackfu posted:Sometimes I think people forget what true old school waterfall was like. Like the whole process of writing all the requirements before a single line of code, and that those requirements were binding on both sides (dev and customer.) Honestly, I would kind of prefer the requirements being set in stone at the beginning. My team is constantly running into revision after revision of how the product owner wants things to look and work, with functionality and UI changing out from under us over and over - sometimes multiple times in the lifecycle of a single ticket. We're getting so frustrated with the constant changes and backtracking and re-dos all up against a bullshit deadline (~12 weeks for an entire site relaunch + custom CMS, user login system, bespoke network structure involving nginx I don't even know) that I kinda wish I was doing waterfall right now, cause at least they wouldn't constantly change the requirements on us and invalidate all of our work.
|
|
#
?
Apr 6, 2017 13:32
|
|
|
lol, requirements still constantly changed in waterfall. It just meant a lot more work was already done on those changes by the time you found out about them.
|
|
#
?
Apr 6, 2017 13:54
|
|
|
smackfu posted:Sometimes I think people forget what true old school waterfall was like. Like the whole process of writing all the requirements before a single line of code, and that those requirements were binding on both sides (dev and customer.) Our PM once told us that bugs are okay because we're an agile shop, not a waterfall shop. If we were a waterfall shop, there'd be no bugs. This wasn't a joke.
|
|
#
?
Apr 6, 2017 14:11
|
|
|
Figures.  I guess it's better to just make changing requirements less of a hassle.
|
|
#
?
Apr 6, 2017 14:11
|
|
|
wilderthanmild posted:
The problem I see with companies jumping on the "agile" and "devops" bandwagons is that these things require people, process, and tools to succeed, and organizations ignore the people aspect. They buy tools and (sometimes) invest in process changes, but they don't get people to buy in to changing their approach to doing things, so the entire effort fails or turns into some useless abomination. It's like companies that invest millions in virtualization and cloud technology, but then make people go through a weeks-long process to provision a new VM. They have the tools, but the people and the process are exactly the same, netting zero benefit. Everyone cargo cults. "Successful companies use X tool and Y process, if we shoehorn X tool and Y process into our awful perception of how software should be written and delivered, we'll succeed too!"
|
|
#
?
Apr 6, 2017 14:46
|
|
|
Gildiss posted:Now we get all that plus the business gets to add more scope in the middle and they get to choose the delivery date. And managers get to micromanage even more. I can't remember the last time I saw a written requirement. I'd love me some spec to rules lawyer over.
|
|
#
?
Apr 6, 2017 17:31
|
|
|
I work as a qa engineer writing front end and rest & soap tests for our systems. All my tests are automated scripts using a fitnesse/java platform. Today I had someone ask me how I could write tests if the software wasn't done yet. I answered I would give my best interpretation of the very meager userstory and would guess what would be in the json response to test on. "But what if your tests fail?" Then either the software or the test is at fault, the frontend dev, backend dev and me would discuss what would need to be in there based on our perception and after some 15 minutes we would reach consensus and would all modify our code to match that consensus. Sometimes we would involve the PO or BA, if needed. I hardly write bugs anymore. This is by far the best testing job I have ever had, in the testing world for 13 years now.
|
|
#
?
Apr 6, 2017 18:32
|
|
|
Pollyanna posted:lovely dickheads putting their fingers in the project and dev team will happen no matter what methodology you adopt. Waterfall, "agile", whatever. The point is to tell people who shouldn't be involved to gently caress off as much as possible. I've worked on great Agile products, and I've worked on PMI-style waterfall projects that also went really well. With the latter, I worked for Time Warner following their split with AOL, and the project was to forklift the entire infrastructure of the Time Inc. division out of AOL's datacenters and into a different hosting situation, modernizing our entire infrastructure management and adding multi-site DR in the process. We had 24 months to implement this project with 50 people and literally 8,000 line items, and the lawyers loving around wasted 14 of our 24 months, leaving us a whopping 10 months to implement this entire thing for a massive collection of sites serving billions of pageviews a month off of decade-old content management systems. You'd think this was a recipe for Total loving Disaster, but we ended up finishing way under budget and a week ahead of schedule because the PMs were supremely competent and correctly leveraged the one single, solitary good thing about PMBOK/waterfall project management: everyone had the exact same vision of what was supposed to be happening and how they fit into it.
|
|
#
?
Apr 7, 2017 05:03
|
|
|
Keetron posted:I work as a qa engineer writing front end and rest & soap tests for our systems. All my tests are automated scripts using a fitnesse/java platform. Seriously people, if you're not using acceptance test driven development / specification by example / behavior driven development in tyool 2017... what the gently caress.
|
|
#
?
Apr 7, 2017 07:31
|
|
|
I've seen posts on SA about companies that don't even use version control.
|
|
#
?
Apr 7, 2017 13:06
|
|
|
A few months back I started a new job involving acting as a technical resource for 9 scrum teams. My first major deliverable was simply to try and write up a set of common standards all team should be following, with the understanding we'd then be able to, at the end of the year during evaluation time, measure the improvement over the year. I felt patronizing to actually include 'Use Source Control' as a bullet point on the list. I felt, in TYOOL 2017, it was a freebie. I felt reinforced by the fact that in the first week, everyone had helpfully pointed out where in the corporate TFS/Git servers their projects resided. And then I found out that huge swaths of the work, while TECHNICALLY residing in source control, hardly ever gets used. Instead many teams tend to use shared folders on the NAS to do their actual work, and in some cases will go 6 to 9 months before bothering to put their latest changes into source control - and when they do, inevitably it is the exact structure of /Code /code old /code old old /New Code /New Code old that also gets checked in, making the source control itself a cacophony that nobody understands, further getting people to just grab a copy and work from a shared folder.
|
|
#
?
Apr 8, 2017 13:17
|
|
|
So the offer I was expecting finally came through and it is... way more than I was hoping for. Feeling pretty great about that. I'm going to formally accept it and put in notice on Monday.  Fortunately/unfortunately, one of my coworkers, our only competent devops guy, also got an offer and put in notice, yesterday. Our manager is on vacation til Wednesday, so he talked to his manager. When he gets back I think he'll have one remaining direct report, and the team will have one guy who knows anything about the system left. If only management had listened to us sooner.
|
|
#
?
Apr 8, 2017 14:05
|
|
|
A bug is reported. You write a unit test that replicates it. You fix the bug and the test is green. Do you keep that unit test around forever now?
|
|
#
?
Apr 8, 2017 14:25
|
|
|
smackfu posted:A bug is reported. You write a unit test that replicates it. You fix the bug and the test is green. Do you keep that unit test around forever now? Yes. The test will let you know in the future if you or someone else creates a regression.
|
|
#
?
Apr 8, 2017 14:39
|
|
|
smackfu posted:A bug is reported. You write a unit test that replicates it. You fix the bug and the test is green. Do you keep that unit test around forever now? New Yorp New Yorp posted:Yes. The test will let you know in the future if you or someone else creates a regression. And when that regression occurs, look at the test. See if it still makes sense to have. The answer is almost always yes, but sometimes it should be changed or removed.
|
|
#
?
Apr 8, 2017 14:41
|
|
|
Not keeping the test means you trust your team to not make the same mistake twice, which is an exceptionally high bar, in my experience.
|
|
#
?
Apr 8, 2017 14:51
|
|
|
Yeah, the only reasons the test should be removed are that the test got rolled into another one that still verifies that the bug discovered does not exist, or the functionality is removed/modified such that the test is no longer useful.
|
|
#
?
Apr 8, 2017 15:13
|
|
|
Clanpot Shake posted:Not keeping the test means you trust
|
|
#
?
Apr 8, 2017 16:05
|
|
|
Volmarias posted:Yeah, the only reasons the test should be removed are that the test got rolled into another one that still verifies that the bug discovered does not exist, or the functionality is removed/modified such that the test is no longer useful. Agreed. In my experience unit tests are way more valuable as validation that things haven't regressed down the line. I often treat them as safety net to catch 'unintentional changes in behavior'. I don't know why you'd ever want to remove one unless it's been rendered totally irrelevant.
|
|
#
?
Apr 8, 2017 22:01
|
|
|
At least make sure the test is descriptive. This way you'll know in six months time *why* Foo needs to equal Bar on Mondays.
|
|
#
?
Apr 8, 2017 23:47
|
|
|
Sagacity posted:At least make sure the test is descriptive. This way you'll know in six months time *why* Foo needs to equal Bar on Mondays. This too. Consider also adding a comment linking to the bug in whatever tracker you use to make it explicit.
|
|
#
?
Apr 8, 2017 23:58
|
|
|
Clanpot Shake posted:Not keeping the test means you trust
|
|
#
?
Apr 10, 2017 01:19
|
|
|
I make changes that cause tests which were originally added to repro a bug to fail all the time. It's really nice having a test suite that's extensive enough that it can be used to test hypotheses about changes, and adding tests as you encounter bugs is a decent way to incrementally get there without specifically dedicating time to expanding your tests.
|
|
#
?
Apr 10, 2017 06:32
|
|
|
Plorkyeran posted:I make changes that cause tests which were originally added to repro a bug to fail all the time. It's really nice having a test suite that's extensive enough that it can be used to test hypotheses about changes, and adding tests as you encounter bugs is a decent way to incrementally get there without specifically dedicating time to expanding your tests. Amen to this. Sometimes a change in behavior is necessary, and a git grep isn't enough to make sure everything lines up properly. Getting rid of unit tests should be reserved for getting rid of functions.
|
|
#
?
Apr 10, 2017 06:37
|
|
|
smackfu posted:I've seen posts on SA about companies that don't even use version control. It's me. im that goon.
|
|
#
?
Apr 13, 2017 15:56
|
|
|
My current place didn't before I started. Because every project is greenfield, there is no team, there is no SCRUM, and I'm the only developer. I'm in heaven.
|
|
#
?
Apr 13, 2017 18:04
|
|
|
Giga Gaia posted:It's me. im that goon. Eject
|
|
#
?
Apr 13, 2017 19:04
|
|
|
I migrated everything at my current workplace from svn to git/gitlab with git-lfs. Feels good.
|
|
#
?
Apr 14, 2017 00:04
|
|
|
Been there. I don't know how people can stand to use svn.
|
|
#
?
Apr 14, 2017 00:19
|
|
|
|
| # ? May 10, 2024 03:34 |
|
|
revmoo posted:Been there. I don't know how people can stand to use svn. Because they have been using it since forever. When it came out SVN was better than CVS and it was a an almost drop-in replacement. Now git comes changing everything. From their point of view the distributed nature of git only means that now they can (and have to) commit locally before pushing to a server. Which is not really a thing they care about. So here comes a new tool that forces them to re-learn how to use version control and forces them to change their workflow for no (obvious) benefits. No wonder they resist that kind of change.
|
|
#
?
Apr 14, 2017 19:05
|
|