|
Slimy Hog posted:Are you not working together on something? Not officially on this project, no. They're pulling them off of it since they haven't made any significant improvements. I like these offshore guys but their talents are honestly better used elsewhere. I don't mind helping them in understanding some things, but I feel like this is a give a man a fish vs teach a man to fish situation. Macichne Leainig fucked around with this message at 15:40 on Apr 2, 2020 |
#
?
Apr 2, 2020 15:34
|
|
|
|
| # ? May 10, 2024 12:23 |
|
|
Protocol7 posted:Not officially on this project, no. They're pulling them off of it since they haven't made any significant improvements. My experience with offshore is that they'd much rather charge the client for going out to sushi than try to pull in a catch and prepare it.
|
|
#
?
Apr 2, 2020 17:35
|
|
|
These have been some of the most capable off shore guys I’ve ever worked with. I don’t really want to speak ill of them. That said, my boss backed me up for not sending my code over, and if they really want I’m more than happy to help them improve their code, but I just don’t like the idea of sending working code over on a golden platter.
|
|
#
?
Apr 2, 2020 19:32
|
|
|
Pollyanna posted:Anybody here work at a company that went all in on SAFe? We've started implementing it (e.g. doing the bigass whole-day company-wide sprint scoping, planning, story pointing, etc. meetings), and my impression of it is very negative. To the point that I'm not confident in the direction of the company now Safe is for companies that hear about this "agile" thing and want to act like they follow the trendy new thing, but ultimately don't actually want to change anything. Definitely eject unless you can get a manager to make themselves a human shield and pretend that you're doing it while letting you actually be productive.
|
|
#
?
Apr 2, 2020 20:18
|
|
So many loving meetings now, it's a wonder we get anything done.
more than I was before?
|
Today on the second day of the first of many quarterly multi-day-long meetings someone on the leadership team had a hot mike moment and said the meetings could “get hosed right in the butt” to a call of like 150 ppl so I don’t think people are taking to it well. I will lol forever when it crashes and burns.
|
|
#
?
Apr 3, 2020 02:43
|
|
|
Pollyanna posted:Today on the second day of the first of many quarterly multi-day-long meetings someone on the leadership team had a hot mike moment and said the meetings could “get hosed right in the butt” to a call of like 150 ppl so I don’t think people are taking to it well. I will lol forever when it crashes and burns. that'd be the perfect time for everyone to laugh and then say yeah lets break for today
|
|
#
?
Apr 3, 2020 03:04
|
|
|
The SAFe facilitator we apparently hired got really indignant and was like “HEY YOU KNOW YOUR MIC’S ON RIGHT” and that’s how I know those people are uncool.
|
|
#
?
Apr 3, 2020 03:12
|
|
|
The guy at my old job who held the title of Release Train Engineer only lasted for like four PIs/2 years before he quit for another job so take that for what you will.
|
|
#
?
Apr 3, 2020 04:51
|
|
|
If I was on a call with 150 people I would walk into the ocean.
|
|
#
?
Apr 3, 2020 04:59
|
|
|
To be fair, we do program increment plannings at my job. We managed to bring them down from 2 full days per 8-week increment to about half a day. We also convinced management that most of what we do is inherently unpredictable, so what we're doing now is planning to 50% of capacity. The stuff we plan is the important company roadmap stuff that people really want to see done. The rest of the capacity we plan during normal sprint plannings and that's usually technical improvements, small nice-to-have features and bugfixes. These big plannings are basically the only thing from SAFe we do and if anyone suggests to do any more that wouldn't go over well. The reason PIs were added to the company is because 1. it gives the management a fake sense of predictability and 2. it stopped customer-facing people from trying to insert all sorts of stuff in the middle of our sprints because they already promised the customer. Their feature requests are usually only considered during the PI planning and this actually means the devs get disturbed less during their regular work. What I'm trying to say is, if you take SAFe, then remove everything that makes it "SAFe", keep the name and general concept of one of its ideas, and apply it to a completely different work process, there are ways to make it fit in without breaking everything. But even this took us over a year of trial and error to get into a workable system.
|
|
#
?
Apr 3, 2020 07:26
|
|
|
Agile is built for team-level, and companies need to plan above that. SAFe is bad way to do it, but I agree with the previous poster that Program Increments is fine. Like, not great, but fine.
|
|
#
?
Apr 3, 2020 14:34
|
|
|
I really think there are good concepts that can come out of SAFe, but the whole thing is so buzzword laden and seems so satirical. I still buy the theory that they came up with it so the SAFe guys can sell their consulting services to companies who inevitably gently caress up their implementation.
|
|
#
?
Apr 3, 2020 15:29
|
|
|
We're all working from home nowaday. Today, each one of us got a bottle of beer or wine in the mail (for me a 0,75 tripel beer) A letter was attached containing Zoom meeting details. We had a virtual vrijmibo. (Dutch informal drinking gathering at the end of the week)
|
|
#
?
Apr 3, 2020 19:33
|
|
|
Turambar posted:We're all working from home nowaday.
|
|
#
?
Apr 4, 2020 03:09
|
|
|
Turambar posted:We're all working from home nowaday. We've been doing virtual happy hours which honestly are more fun than I thought they'd be, but sending something out like that is a great idea.
|
|
#
?
Apr 4, 2020 15:30
|
|
|
https://twitter.com/moonpolysoft/status/1246621978460442627
|
|
#
?
Apr 5, 2020 16:43
|
|
|
I think I'm gonna set a new record on my team. It's day 10 of a 10-day sprint and I've finished, like, 1 story-point in JIRA. My time spent this past week has been: Write a commit. Try to find something to do since odds are my coworkers won't look at my Pull-request until the next day. Have my pull request rejected for a reason that contradicts info I was told a week earlier. repeat. While waiting for people to review my pull requests, I've been trying to find out why my cygwin install has slowed down over the past year. This is not a task given to me from the backlog, so now I'm gonna look like a piece of poo poo in our sprint meeting Monday. oops. edit: Also, my manager asked me to work on stuff over the weekend, but that assumed that I'd finish my tasks this sprint haha. Faith For Two fucked around with this message at 00:09 on Apr 11, 2020 |
|
#
?
Apr 11, 2020 00:01
|
|
|
Faith For Two posted:I think I'm gonna set a new record on my team. It's day 10 of a 10-day sprint and I've finished, like, 1 story-point in JIRA. Wait for the day to arrive when you find the flaw or omission that results in -several weeks of work being completed in the sprint. The PO loves hearing that.
|
|
#
?
Apr 11, 2020 00:39
|
|
|
the whole point of agile is that it's fine bro
|
|
#
?
Apr 11, 2020 00:46
|
|
|
Sounds like you have an opportunity to establish consistent code review guidelines for your team, which will help productivity a lot.
|
|
#
?
Apr 11, 2020 05:17
|
|
|
New Yorp New Yorp posted:Wait for the day to arrive when you find the flaw or omission that results in -several weeks of work being completed in the sprint. The PO loves hearing that.
|
|
#
?
Apr 11, 2020 18:28
|
|
|
Need some help dealing with software quality management. I currently work at a small start up company. Except for our one contract iOS developer, none of us come from formal software development/programming backgrounds. We're developing an audio app on iOS, that works with an external BLE device. Without going into too much detail, the device is an audio & vibration sensor and we're doing some fancy DSP stuff and displaying a handful of metrics. We're already released Version 1.0 of our commercial software, and are preparing a change order (CO) to release Version 2.0, and we're struggling with a lot of process questions. One issue is that we have a ton of engineering features in the code. One example is the ability to store recorded data to a cloud database. This is not user-facing - its hidden behind a password protected "Advanced User" mode. There's one camp in the company that says because this feature is not part of our Software Requirements Specification (its an internal development feature), and its not user-facing, it doesn't have to be tracked within the QMS (basically: it doesn't have to appear in the CO/Official release notes). There's another camp (me), that says it IS a real code difference between the releases, and even if its not user-facing, there's always a chance it could introduce a bug or something. The second issue is what I call stub code. There's a handful of metrics we expose to the user (as required by our SRS). But in reality there's a dozen more coded in - they just don't actually do anything at the moment. And they are tied to actual JIRA tasks requesting their implementation. How does this sort of thing get handled? It is a real code diff, but does it actually need to be "counted"? I realize there's probably no single correct answer here.
|
|
#
?
Apr 16, 2020 04:35
|
|
|
Any behavior that is detectable by any user should be verified. "User" is a broader term than just your customers; it could include, for instance, server operators. Metrics are detectable by users, because operators are users, and as a result they're features. Disabled features should still be verified, but there's not necessarily any value in advertising their existence until they are activated. Public documentation, including release notes, is part of the product you're releasing. It's something that users see. Even though it's not code, it's still a feature. That means it's up to the product manager, or any other interested parties, to determine what would be most useful for your users to include in the release notes, and prioritize it relative to other features and determine whether they're satisfactory. Users of release notes are anybody who might read them. If you're subject to formal obligations regarding the contents of your release notes, then obviously you must meet them; if there's ambiguity in these obligations, then this is a legal question rather than a development methodology question. If some change to the program is not detectable by users, there's no point in describing it in the user documentation, except maybe under a catch-all weasel-word like "optimizations to improve stability and performance" or some poo poo like that. But it's still worth including internal improvements in the issue tracker, so that the team is aware of what's being done, has some consensus about why they're doing it, and can make an informed decision about how important it is. Exactly how you measure it is highly context-dependent. The risk of introducing a bug is irrelevant. Bugs happen. Your regression tests should catch them. You've got tests, right?
|
|
#
?
Apr 16, 2020 05:06
|
|
|
Bongo Bill posted:Any behavior that is detectable by any user should be verified. "User" is a broader term than just your customers; it could include, for instance, server operators. Metrics are detectable by users, because operators are users, and as a result they're features. Disabled features should still be verified, but there's not necessarily any value in advertising their existence until they are activated. Thanks for the reply. Lots for me to mull over. In the mean time, how about this scenario. One of us engineers requests a new (engineering) feature, which gets added to the password-protected Advanced User screen. To be extra super sure the end-user can't get in there, we remove the button. At this point, we now have a release with a bunch of code that literally cannot be executed. To what extent would one still document this? Does this become essentially a disabled feature and so does not need to be advertised? quote:The risk of introducing a bug is irrelevant. Bugs happen. Your regression tests should catch them. You've got tests, right? Uh, sort of. Right now, we just have QA-Type tests, testing the functionality against the requirements. We do not have any sort of automated regression testing, yet.
|
|
#
?
Apr 16, 2020 06:26
|
|
|
Users don't care about code, and that goes double for dead code that cannot be executed.
|
|
#
?
Apr 16, 2020 06:54
|
|
|
Cyril Sneer posted:Thanks for the reply. Lots for me to mull over. Look at your question in the other direction: "should I advertise to users features that do not exist to them?" Your releasee notes are not your internal documentation.
|
|
#
?
Apr 16, 2020 12:29
|
|
|
Cyril Sneer posted:Thanks for the reply. Lots for me to mull over. It feels like you're conflating what are/should be two different things. We have internal release notes and external release notes—while some of their contents are the same, a lot of them aren't. In your particular example, our internal release notes would note that we added blah blah blah feature for engineering that does XYZ and it wouldn't be mentioned in the public release notes because external users can't interact with it in any way. If your internal and public documentation is the same you're either going to have internal documentation that is woefully inadequate or public documentation that is massively over complicated and full of irrelevant poo poo. Wallet fucked around with this message at 14:28 on Apr 16, 2020 |
|
#
?
Apr 16, 2020 14:25
|
|
|
Cyril Sneer posted:Uh, sort of. Right now, we just have QA-Type tests, testing the functionality against the requirements. We do not have any sort of automated regression testing, yet. This effectively means that you don't have tests. The software industry has known for decades that manual QA is, at best, a highly unreliable signal of quality; it results in far too many false negatives and far too many false positives.
|
|
#
?
Apr 16, 2020 15:02
|
|
|
So my boss who seems to not understand that we are capable of doing our jobs from home and are in constant contact with each other on Slack came up with a very dumb scheme where we get a daily, randomized phone chain and everyone has to call each other in the daily sequence until it ends at my boss This has, of course, been failing which has naturally resulted in a big email chain about how to improve this very useful process: quote:So, here's a suggestion: add a feedback loop to track down & recover from missed/forgotten phone calls. Since calls should be made between 9 - 3, a 6 hour window, and there's (max) 20 phone calls to be made each day, then each phone call should ideally take place in an (360 minutes) / 20 = 18 minute window. So if we're assigned, say a 15 minute window to make the call, starting at 9, then we should be done by (the latest) 2 pm. So I suggest assigning to each cell a designated time to call, in 15 minute increments, since we should all now be able to see the spreadsheet online. Then I'll know when to expect a call, and if the window in which I should get called expires, I could call my failed caller and make sure they're ok, and so down the line in the opposite direction until the last successfully called person (or a person with a problem) is reached. Then I'd make my "forward" call as scheduled. This will short circuit any chain breakage and recover from where the failure is, and still keep the subsequent calls on track. Gray boxes can still exempt people from the chain.
|
|
#
?
Apr 16, 2020 16:31
|
|
|
Fellatio del Toro posted:So my boss who seems to not understand that we are capable of doing our jobs from home and are in constant contact with each other on Slack came up with a very dumb scheme where we get a daily, randomized phone chain and everyone has to call each other in the daily sequence until it ends at my boss that is remarkably stupid. have you considered all getting together and telling him to install slack?
|
|
#
?
Apr 16, 2020 16:35
|
|
|
What's the point of this phone chain? Just to make sure everyone is working? Does he not realize you can pause your nintendo for a sec to pick up your phone and say "oh yeah I'm totally working"
|
|
#
?
Apr 16, 2020 16:45
|
|
|
prom candy posted:What's the point of this phone chain? Just to make sure everyone is working? Does he not realize you can pause your nintendo for a sec to pick up your phone and say "oh yeah I'm totally working" 
|
|
#
?
Apr 16, 2020 16:56
|
|
|
There's gotta be a whole lot of managers scrambling to justify their jobs during all of this.
|
|
#
?
Apr 16, 2020 17:31
|
|
|
I think what I/we are really struggling with is how to deal with experimental features. Experimental features - things-we-want-to-play-around-with somehow feels very different from "released" features - things-the-end-user-actually-uses. At a previous company we actually had two different applications - an engineering app, and our commercial app. Things we want to play around with went into the engineering app and, if deemed successful, would then get formally implemented in the commercial app. The reason this distinction mattered was the test burden. Experimental stuff could get tossed into the engineering app without much more than a "hey did it work?" between the developer/user. As well we were not required to maintain any particularly detailed design documentation. Compare this to the commercial app, where any changes required substantial testing, and considerable documentation updates. At my job now, we only have one app, so this all gets squished together in a confusing way. leper khan posted:Look at your question in the other direction: "should I advertise to users features that do not exist to them?" This makes sense. Wallet posted:It feels like you're conflating what are/should be two different things. We have internal release notes and external release notes—while some of their contents are the same, a lot of them aren't. In your particular example, our internal release notes would note that we added blah blah blah feature for engineering that does XYZ and it wouldn't be mentioned in the public release notes because external users can't interact with it in any way. If your internal and public documentation is the same you're either going to have internal documentation that is woefully inadequate or public documentation that is massively over complicated and full of irrelevant poo poo. I think this is a good framing of the issue. It pushes the question up the chain in the sense that maybe we need to figure out what constitutes an internal vs. external document, under our regulatory frameworks.
|
|
#
?
Apr 16, 2020 19:07
|
|
|
Sounds like you also need to deploy different code to Production than you do to whatever environment you experiment with.
|
|
#
?
Apr 16, 2020 19:11
|
|
|
Or use feature flags
|
|
#
?
Apr 16, 2020 19:32
|
|
|
Blinkz0rz posted:Or use feature flags Can you elaborate?
|
|
#
?
Apr 17, 2020 02:09
|
|
|
Cyril Sneer posted:Can you elaborate? Keep your codebase fully integrated and configure which features are accessible via flags. It can be as complex as you need (i.e. user groups and only certain groups have the flag on) or as simple as you need (if this configuration variable/environment variable is set, unlock feature x).
|
|
#
?
Apr 17, 2020 02:29
|
|
|
Cyril Sneer posted:Can you elaborate? Also known as feature toggles. Any of several methods for enabling or disabling functionality at runtime using a configuration setting accessible to developers or operators but not, generally speaking, to end users. I'm not sure how well they'd fit into a mobile app, however.
|
|
#
?
Apr 17, 2020 02:30
|
|
|
|
| # ? May 10, 2024 12:23 |
|
|
Bongo Bill posted:Also known as feature toggles. Any of several methods for enabling or disabling functionality at runtime using a configuration setting accessible to developers or operators but not, generally speaking, to end users. I'm not sure how well they'd fit into a mobile app, however. Most mobile games I know of use them heavily
|
|
#
?
Apr 17, 2020 04:01
|
|