|
Sander Rossel wrote: As far as I know he's not on the autism spectrum.
Also (with few exceptions), everyone is on every spectrum -- hence the name.
|
|
|
|
|
I like waterfall so any last minute changes are things that will take 2 more years to add to the project. Then again clients don't exist in my line of work. 
|
|
|
|
|
I agree, Waterfall is just Scrum with two-year sprints. 
|
|
|
|
|
This comment will add very little to Sander's post but it is posted to say I admire the intelligence and thoughts of the folks who responded to the query. What a bunch of smart people.
When I started coding VB 6 I would use what I learned in an elective Basic Programming on a DEC writer NO screen. That was to draw a flow diagram. It was a terrible idea as I had no idea what the VB 6 project would do. Slow forward too many years and I have learned to draw my screens (Forms) and think about the controls that might be needed. This makes the process of writing the code easier. Yes I am up to vb.net now.
Last summer I started woodworking table saw the whole nine yards. Wanted a workbench/outfeed table.
So I did a sketchup drawing made a cut list. It dawned on me that this process was the very similar to my rudimentary design process for coding.
I had to farm out my milling for the table legs as I have no jointer or planner. I wanted the 4 by 4's to be 3 in square.
I have no friends that code and have often thought it would be fun to work on a BIG project with a fellow coder.
I have no idea how working on a BIG project with someone else would work
After reading every comment on this post I am guessing 70% of the people who responded work solo.
It would be nice to know. So someone make a post posing the question.
While I have been here for sometime that type of post for me is above my pay grade.
|
|
|
|
|
The process goes a bit as follows.
An analist meets with "the business" and divides the work into stories.
To create and organize stories the team uses a scrum board with backlog, like Jira, Trello, Azure DevOps, etc.
You then have meetings to estimate how long the stories take to complete the complexities of the stories (complexity can be expressed in T-shirt sizes or numbers from the Fibonacci sequence, for some reason).
A product owner prioritizes the stories based on other meetings.
You then meet to plan the next sprint (any stories you didn't complete from the previous sprint are moved into the next).
During these meetings you also divide the stories into tasks.
Any stories that aren't 100% clear can't be estimated and have to go back to the story owner (mostly the person or manager who requested the change).
After a while you should know just about how much complexity your team can handle in a two-week sprint, so you can plan accordingly.
Every day you have a stand-up with the team to briefly discuss what you did, what you're going to do and if you need any help.
During this stand-up you'll move tasks and stories from "to do" to "doing" or "done".
At the end of the sprint you'll have meetings about how the sprint went and what could've been done better.
You'll have at least two or three one to two hour meetings a week (I've even heard people say they should be three to four hours!) plus a daily 5 to 15 minutes stand-up.
During the sprint it is possible to move some stories around if priorities change, but that should be avoided.
At the end of the sprint you should be able to deliver the stories, and so real value, to the business.
As for the code, you'll use tools such as Git and GitHub, obviously.
So yeah, prepare to lose at least half a day a week on meetings while being more or less agile in two-week increments.
Keep in mind not all teams do everything like this, but this seems to be a popular format.
I've been in three-week sprints, half hour to hour stand-ups, teams skipping meetings like the retrospective, teams doing only the stand-up with a Kanban board and calling it scrum...
Scrum absolutely has its merits, but it's not the golden bullet some people would have you believe.
|
|
|
|
|
Scrum is the absolute minimum amount of process that can be imposed on an organization that is process-averse. That you find it too rigid makes you less of a cowboy and more of a wildman. (I might have said wild indian to carry on the cowboy motif, but that's not politically correct).
If you let customers change horses in the middle of a two-week sprint, you are embracing a degree of chaos that probably hurts your profit as a consultant, or needlessly raises costs to your customers. I bet this is not your friend's first rodeo (Yee-hah! More cowboy metaphors). His experience says this is a bad way of working. That's certainly what I would say.
More discipline is called for. It's better for you, better for your partner, and better for your customers.
|
|
|
|
|
Most of my clients don't have enough work to plan in two week sprints anyway.
It would be a sprint for multiple customers.
So let's say the sprint starts on Monday, a customer (who may or may not have work in the current sprint) calls on Tuesday, and I have to tell him they'll have it at the end of the next sprint (four weeks from now)?
That's a recipe for losing clients.
There's a lot less than scrum that can still count as a process.
SeattleC++ wrote: His experience says this is a bad way of working. That's certainly what I would say.
I'm actually more experienced than him in pretty much every way possible (number of jobs, time in the field, methodologies used, etc.), but he is by far the better front-end programmer.
He's never done anything else than scrum, I have, and that's probably why he's having trouble adapting.
And in my experience, I'm saying everything we do besides what we're doing now is absolute overkill as far as work planning goes.
Although I'm now making sure his tasks are a bit less open for interpretation, some people need a bit more management and I accept and respect that.
So, instead of "can you start with whatever form and fix it like we said last month, tell me when it's done." I'm now saying "can you make sure fields x and y on form z are positioned like a and b and I want it by the end of the week." (this is an example, not a literal conversation, before people start making assumptions based on this too).
modified 21-Jan-22 5:50am.
|
|
|
|
|
I've mostly worked on multi-man-year projects. It's hard for me to imagine a whole project that takes less than a week, but requires iteration and needs more than one worker. You have to do what works for you, and sprints are apparently not part of it.
Your partner was suffering from a need for a more concrete design to grind on, and you have learned to provide it, which is good.
|
|
|
|
|
SeattleC++ wrote: It's hard for me to imagine a whole project that takes less than a week
More like tasks than projects (or tasks that are part of an ongoing project, if you like).
The tasks usually don't require more than one worker, it's just that I'm not a (graphic) designer so those aren't tasks I can do myself.
So this guy goes from a full scrum team from another employer to a task here and a task there for me.
Maybe it's good to mention he doesn't work for me full time, but a few hours a week.
I'm getting a full time employee later this year, will probably switch to a more scrum/kanban approach when that time arrives.
It still won't be a full fledged project team, but hopefully getting there in the next two years or so
|
|
|
|
|
Everybody hates SCRUM. I do, too. But I think, the larger the team and the more innovative the project, the more SCRUM you need. Unfortunately! Haven't seen anything better for teams of 5-8 or more people yet.
|
|
|
|
|
If everybody hated it we'd be doing something else by now.
It's true lots of people don't like it, especially the overhead, but there are still many people who follow scrum religiously.
|
|
|
|
|
With "everybody" I meant every developer. The religious people are usually managers. 
|
|
|
|
|
That's a challenge. In your shoes I would look for parts of the work which can be compartmentalised and ask him to work on them. That means he can work his way and you in your way.
|
|
|
|
|
|
yep, the wife got 4 yesterday for the family.
|
|
|
|
|
|
Unfortunately too accurate. Too many people get the PCR test too soon, so they test negative and then come down with COVID. The antigen test is useless unless you've already been sick.
|
|
|
|
|
That would make much more sense than what they do now...
|
|
|
|
|
I have always wondered what purpose self tests like for COVID and sugar levels serve. I do not think medical professionals care about the results from those and hence the question - why do these exist?
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
In theory they identify Covid-positive cases before they infect others - before symptoms develop.
And that means infectious people can isolate earlier, reducing the spread of the disease.
Reporting results to a central authority means that people who have already been in close contact get told earlier and can get tested / isolated before they start infecting others as well.
That's the theory: in practice it depends on people to do them properly, report them always and accurately, and isolate when they get a positive result. Which I'm betting doesn't happen in many cases, particularly if you play tennis at the highest level the pub is open.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: In theory they ...
"In theory, there is no difference between theory and practice. In practice, there is." - (author in dispute) 
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
dan!sh wrote: self tests like for COVID and sugar levels
You chose a poor example.
Monitoring insulin and sugar levels is essential for diabetics to know how much insulin to inject, as both too little and too much can lead to life-threatening results. Doctors might not be interested in all readings, but they certainly will be interested if one or the other changes without a corresponding change in diet or other factors.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I am an insulin dependent diabetic and I can tell you that I have skipped testing myself on many occasions. Not recommended, but it actually occurs a lot with diabetics like me.
|
|
|
|
|
As you say, it's not recommended. But if your daily diet etc. doesn't change much, you may be able to get away with it for a while. The danger is that you may miss changes in your medical condition because you didn't do the tests.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Bascially what OG already said plus the fact that you can get yourself a short while of security that you are not infected, nearly dead or whatever.
I mean for sugar level tests as another example, they do at least tell you that your current level is either good or bad, so you can react before the professional has to take actions and measure how bad your level is.
There are so many medical self-care things, just because we don't have enough professionals to do all the work for us
Rules for the FOSW ![ ^]
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? "This is my signature: " + Environment.NewLine + _signature
: "404-Signature not found");
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
