The Lounge - CodeProject

First Prev Next

Re: opinions software methodology

Kirill Illenseer13-Dec-16 21:28

Kirill Illenseer

13-Dec-16 21:28

Well, even if one follows agile (let's not discuss if it's good or bad), if the requirements change all the time, that is if if the requirements giver declares his own words from last week wrong, he either has a latent case of split personality disorder or is plain stupid.

Re: opinions software methodology

JackPeacock14-Dec-16 2:02

JackPeacock

14-Dec-16 2:02

In many organizations it's more important to do something rather than the right thing. With agile coding can start immediately, without a design. Since progress is measureed in lines of code, "something" is progressing well. After all, it's gonna be late anyway, put off the design till halfway through the project.

Re: opinions software methodology

Ygnaiih14-Dec-16 4:33

Ygnaiih

14-Dec-16 4:33

My agency let's a woman with no technical skills run fake scrums. No substantial comments are allowed. If there is an issue (you can't say problem)follow up if any is a mob meeting where the A types dominate the floor blathering on about irrelevances.
I need a day off.

Leadership equals wrecked ship.
If you think you are leading my look behind you. You are alone.
If you think I am leading you, You are lost.

Re: opinions software methodology

mbb0114-Dec-16 5:31

mbb01

14-Dec-16 5:31

There are lots of criticisms that you could make of agile and supporters would suggest that you are not doing it properly.

But from what you've posted, it seems more like you have a bad manager, but you know this already. I'm guessing you're dealing directly with your boss? Agile is just a smoke-screen for do it all as fast as you can; use weekends and evenings for all I care?

If you can, you need to educate your manager with the true costs of software development in terms of time that it takes to do the job properly. You need to try to establish that there is an overhead in constantly re-writing the same software when requirements change. Granted, this is a part of the natural evolution of software, but (for simplicity's sake) at the very least you should be able to confirm the version you've just released before you start working on the next version.

Changing team company or team culture won't happen overnight. It will be a process over a long period of time. Collect your data and facts before having that argument.

Hope this helps.

Re: opinions software methodology

Gerry Schmitz14-Dec-16 5:32

Gerry Schmitz

14-Dec-16 5:32

As long as the majority thinks all you need to run projects is "people skills" (and little or no technical expertise), software development teams will continue to produce sh*t.

Eastern Europe and China are now cranking out all the (good) code ... because they are still a bit more hungry than the average Westerner and don't need the BS.

Re: opinions software methodology

Leng Vang14-Dec-16 6:43

Leng Vang

14-Dec-16 6:43

In my experience, Agile/Scrum works best in consultant line of work where as long as the customer keep paying the hours, the team will keep coding, changing to the will of the changing requirement.

It rarely works with projects that have deadline and budget constraints. These type of projects required the full understanding of the scope to properly estimate budget. The requirement must be approved before any development can take place.

Unfortunately far too many managers are in place without really understand the technical difficulties of managing the unknown. Compounding to the problem is that some managers are having ego issue, not willing to listen to the team. When I have this kind of problem, I either go directly to the upper management (yes stepping on toes and risk getting fired) or if the manage is the upper management, find another job quick. There is no reason to be stressed out and stick with a moron.

Re: opinions software methodology

SeattleC++14-Dec-16 7:59

SeattleC++

14-Dec-16 7:59

Point out to the person bringing the changing requirements that you make the same hourly wage whether he is wasting resources by changing requirements, or planning and executing effectively, and wouldn't it be better for the business if he did some planning and analysis. Or don't point it out, but just remember it yourself.

Really the only thing that requires changing is the blaming you for his changing the requirements. Be a stickler any time you get blame. Ask for misunderstandings to be explained in writing, preferably with reference to a previous document, and keep the memos. If he won't document it, then you do, and send him an email recapping what he said was the issue. At the end, you'll have a complete list of requirements. And you may get lucky enough to catch the manager in a 360, where he first says, "go left", then says "go right", then says "go left" again, which you can call him on, with documentation. A reasonable person will "get it" when you show him such evidence of bad planning.

Requirements don't really change. What changes is the team's understanding of the requirements. Software development is knowledge acquisition, plus crystallizing that knowledge into executable form. You don't know what you don't know, until you try to build the thing.

Re: opinions software methodology

Kirk 1038982114-Dec-16 7:59

Kirk 10389821

14-Dec-16 7:59

Wow, your boss sounds like he is clueless...

After listening to the overall goals of the project,

We start with a metaphor which frames the conceptual expectations:
- A Web Kiosk, A Public Web, A 3-tier Client, a 2-tier Client...
- Then we discuss this with the client to make sure they understand the limitations/abilities
(you probably don't want a remote interactive video editing tool)

Then we choose an even better metaphor
- Like Twitter, Like Facebook, Like....
- But NOT like, and will not

Now we have a framework concept. We still have not started any coding.

Then we meet and identify the various user "groups" (admins, managers, users, clients, etc)

Then we assign Points of Contact for each group that we can FREELY ACCESS as developers.
We start collecting the Use Cases (user stories) at a HIGH Level. Looking for exceptions.

And we mock up an presentation to demonstrate how interactions will work (no coding yet).

Now we have a PROJECT. We have wasted ZERO programming hours. We should have a general consensus.
We know the stake holders. Stake holders know where everything is going in general. They also know they are NOT the only users of the system.

Then we start the real work, which feels a lot more agile, because we are always delivering a usable system with high quality.

Did we specify EVERYTHING up front in detail? NOPE.
Did we leave everything until after the programming started? NEVER.
Will we prevent the programmer from talking to the user? (Not unless we have a to)

==
What you are describing meets my definition of death by a thousand cuts.

Your baby step is to be in the meeting with your boss so you can ask the detailed questions when required.

iDespair

Nagy Vilmos13-Dec-16 1:10

Nagy Vilmos

13-Dec-16 1:10

So, tis the season to be ~~jolly~~ bloody miserable!

Youngest had a very good report this term including going from no experience to A in French in one term! My dear darling love MRs Wife said she can have whatever she wants [usual terms apply] for Christmas and my, otherwise apparently intelligent child, wants a bally iPad! Sigh | :sigh:

I have never owned an Apple device and not really wanted one since the days of the Apple ][. So, dear hive mind, it looks like I have to buy a Crimbo iPad. Which model is bestest for an 11yo? I only want wi-fi so mobile use doesn't come in to it.

veni bibi saltavi

Welcome to the Lounge