|
CDP1802 wrote: By taking architecture and the target platform out of the picture as a prerequisite, you can concentrate on the work at hand.The language is JavaScript. that of Mordor, which I will not utter here
It's like that almost all the time - before agile.
Braking project up into bit-size pieces, making sure they all work, &etc. What's really so novel about that? Now creating a test before you've something to test - honestly, that's like taking a dump before you drop your pants. (i.e., you heart's in the right place - nothing else is.)
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Most people don't know the difference between strategy and tactics.
Strategy is when many bigwigs stand around a plan and take a look at the big picture. Tactics are when the little soldiers are actually fighting in the trenches and must react to constantly changing situations and see only a small part of the picture.
You are in trouble when you treat one like the other. Treat architecture and the 'how tos' strategically and take all the time you need to think them through and make your troops familiar with the plan. Have them out of the way when the actual work begins.
I see agile as a way to handle the implementation tactically and to help you to react quickly to unforseen situations or changes.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
The detailed documentation of the requirements is the most important point. How detailed, these are the specifications that your team will build to. Most helpful are the expected inputs and outputs, which you get from questioning the customer or the marketing dept. IPO mapping is best for this, then the internal processes and objects. From these, the team designs the architecture and user interfaces.
|
|
|
|
|
When done right, Agile works great. Used it at my last job and took parts of Scrum that I liked and it worked very well. But everyone needs to understand their role.
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
RyanDev wrote: But everyone needs to understand their role.
That was already the case when they built the pyramids. One guy holds the plan, a handful of guys hold whips and the rest of the guys are in charge of hauling the stones. If they are not agile enough, the guys with the whips come and motivate them.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Wrong. It was the aliens who did it. 
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Congratulations, you work for the PHB.
Dilbert Comic Strip on 2007-11-26[^]
Are you the only one who "doesn't know and has no experience in the methodology" (according to him)? If there are others in the team, get him to explain to everyone what exactly he has in mind by this methodology.
Why are changing requirements labelled as your misunderstandings anyway? Requirements are allowed to change, since most people don't know what they need right away from the start.
|
|
|
|
|
Nighthowler wrote: Requirements are allowed to change, since most people don't know what they need right away from the start.
Yes, but in most other cases I will get a nice bill if I can't make up my mind. Only in software development customers like to mistake us for nice little elves who instantly can do anything at no cost.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
What Pete said. It doesn't matter if it is training for Fairyball, learning the guitar or developing the latest doohickey for app stores. There has to be a reference point of how and why things are done and the bosum must be able to tell you not just the what but the all important why.
If he can't explain that, ask him to explain why you should stay.
veni bibi saltavi
|
|
|
|
|
First off, Agile was created mainly by software developers (wikipedia):
In February 2001, 17 software developers met at the Snowbird resort in Utah to discuss lightweight development methods.
If you take two of the principles:
Simplicity—the art of maximizing the amount of work not done—is essential
Best architectures, requirements, and designs emerge from self-organizing teams
It should be self-evident that this requires people with technical, personal, and inter-personal skills. Furthermore, because there will always be a mix of skills, it requires that those with skills that others are lacking become mentors, or, amusingly, manage those with less skills in a particular area. For example, would you conclude that a junior developer can produce "best architectures"? Would you assume that everyone is good at defining requirements? Would you assume that anyone can be placed in front of the customer?
Assuming you answer no to hopefully all three of those questions, the cracks in the Agile castle start to show up because 1) people have different skills, 2) because skills vary, a hierarchy of skill is necessary. This is unavoidable, necessary, and the only way that people have the opportunity to learn.
The idea of self-organization is great, but only when you have highly skilled people in just about every area that the task requires. If not, you can get some self-organizations that result in terrible work. Therefore, again, organization requires management skill - someone to decide who the right people are to self-organize.
Some of this can be compensated for in item #12 of the manifesto:
Regularly, the team reflects on how to become more effective, and adjusts accordingly
However, self-reflection is also a skill, and one many people, in my experience, are not skilled at.
V. wrote: Yes, but you don't know, and have no experience in, the methodology we're using here.
Agile is not a methodology[^].
V. wrote: Though I see a benefit in using this when doing prototyping and/or proof of concepts, I fail to see any value when doing real (operational) products which could (and should) be defined.
I see the reverse for a few reasons. Often prototype code becomes production code without review of design, architecture, simplicity, etc. Second, the production development phase often requires a delivery schedule of features, customer feedback, and requirement changes. If you have a good foundation for your code, these changes are considerably less painful. And in theory, Agile's practices of having a solid customer relationship, frequent review of work with the customer, good feedback to the customer of delays, tradeoffs, etc., really helps in creating a successful application. If you're creating a mass market product, someone needs to pick a cross section of people that can play the roll of the "customer."
Unfortunately, I've seen Agile used, not by managers, but by developers, as carte blanche for not doing documentation, design, etc., and management, that doesn't understand Agile (how can anyone actually, since it's not a methodology) wonders why yet another "methodology" for software development fails, produces the same number of bugs (or more), and has cost and time overruns.
The reality is, it's not the so-called methodologies that determine success, it's actually the people and the skills they bring.
Marc
|
|
|
|
|
I could give a long reply to several statements, but in short:
a) I can see how it could work, you did put some good arguments for solid use of the method.
b) You convinced me even more that our organization should never, ever (!) use this. 
|
|
|
|
|
V. wrote: You convinced me even more that our organization should never, ever (!) use this.
My job is done.
Marc
|
|
|
|
|
Agile development - Think of it like a hot potato; no one wants to touch it, it just gets tossed about and the last one to have it takes the blame.
I say toss it back to your manager?
New version: WinHeist Version 2.2.2 Beta I told my psychiatrist that I was hearing voices in my head. He said you don't have a psychiatrist!
|
|
|
|
|
Mike Hankey wrote: I say toss it back to your manager
sooner or later it will get tossed to the managers' manager 
|
|
|
|
|
Why not, as long as they are busy giving each other the fault and duke out their little rivalries, you are safe. You must only see to it that they never realize what's going on
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
The process involves new cover sheets on the TPS reports. BTW most pf the communication these days happens passive-aggressively.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Call this issues "challenges" and deal with them professionally. Maybe it is time for a raise (or leave). 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
