opinions software methodology
-
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 fucking 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. -
Not really. If - there is a well defined architecture - there is a detailed documentation of the requirements - every member of the team is familiar with this architecture and the platform - a realistic sprint planning, producing a list of managable tasks it can work. 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
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking 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.And that's my point, 2 choices to make agile methodologies work: 1. as you've done simplify the target / break it up .... (even seen attempts to waterfall ahead of the project plan) 2. (like RyanDev - next reply) take 'parts of' the methodologies .... so it's not really agile or scrum, it's a hodgepodge of what sounds good 3. most commonly combinations of 1 and 2 .... so true to the definition it's not agile, it's ad-hoc pm. But in fairness, to 100% perform properly to many tasks become impossible, slippage is almost not allowed and even small failure definitely not handled properly without throwing out the entire plan for the workaround, lack of flexibility, just unreasonable to ever perform 100% purein the real world. (Achieving real word pure agile ranks alongside the traveling salesman / 4 colors puzzles.)
Sin tack ear lol Pressing the "Any" key may be continuate
-
Agile software development[^] I'm currently in a situation where I constantly run into changing requirements, "misunderstandings" (=other name for changing requirements, but I get the blame), dependencies on moving targets, ... When I challenged the person in charge (for the lack of design) I got: Yes, but you don't know, and have no experience in, the methodology we're using here. Personally I believe agile is a methodology invented by managers who failed to understand the importance of design and documentation. Furthermore, I'm pretty sure this person has no clue about any methodology, bu rather "goes with the flow". 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. Opinions?
V.
(MQOTD rules and previous solutions)
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.
-
This is something I hear often. It's the idea that agile means you can skip the requirements gathering phase altogether. That is not, and never has been, the case. You still need a rough idea of what you're going to build. And it's your responsibility to work, with a representative of the client, to determine at the start of each sprint, what you are going to deliver. That means that they have to have provided enough detail going into the meeting to work out the rough shape and size of each task.
This space for rent
Even more: Get everything out of the way you can. Your team has to know enough of the architecture and the technologies used so that you can assign them tasks that tell them what needs to be done, not how to do it. In sprint planning I want to define tasks like this: We need a new entity named that has the following properties: (list), possibly some reference to the requirement documents. Also, we need a data access object with data access methods to cover the following requirements: (another list of references to the requirements and possibly some elaborations) No need to lose a word about how to do that, where to place these objects or what technologies to use. My boys know that before writing the first line of code and there probably will be more assignments like this coming their way.
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 fucking 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. -
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 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.
(MQOTD rules and previous solutions)
-
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 fucking 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. -
true, so he blames in the client. Which is partially true, but personally I would have told the client what they needed to do first before we started anything... :doh:
V.
(MQOTD rules and previous solutions)
Actually, and with mixed but increasing success, I try to explain to the client* what they need and how they need it. They're a clue-less lot and if I didn't (or they just don't want to listen) then the effect is much more like what you've experienced. Interestingly, word of mouth (?) has it that IT knows what it's talking about when it comes to IT. Imagine that! * Client as in defining users as these are in-house users.
"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
-
Not really. If - there is a well defined architecture - there is a detailed documentation of the requirements - every member of the team is familiar with this architecture and the platform - a realistic sprint planning, producing a list of managable tasks it can work. 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
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking 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.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.)
"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
-
Agile software development[^] I'm currently in a situation where I constantly run into changing requirements, "misunderstandings" (=other name for changing requirements, but I get the blame), dependencies on moving targets, ... When I challenged the person in charge (for the lack of design) I got: Yes, but you don't know, and have no experience in, the methodology we're using here. Personally I believe agile is a methodology invented by managers who failed to understand the importance of design and documentation. Furthermore, I'm pretty sure this person has no clue about any methodology, bu rather "goes with the flow". 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. Opinions?
V.
(MQOTD rules and previous solutions)
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! -
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! -
Actually, and with mixed but increasing success, I try to explain to the client* what they need and how they need it. They're a clue-less lot and if I didn't (or they just don't want to listen) then the effect is much more like what you've experienced. Interestingly, word of mouth (?) has it that IT knows what it's talking about when it comes to IT. Imagine that! * Client as in defining users as these are in-house users.
"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
-
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.)
"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 fucking 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. -
Mike Hankey wrote:
I say toss it back to your manager
sooner or later it will get tossed to the managers' manager :~
V.
(MQOTD rules and previous solutions)
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 fucking 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. -
Agile software development[^] I'm currently in a situation where I constantly run into changing requirements, "misunderstandings" (=other name for changing requirements, but I get the blame), dependencies on moving targets, ... When I challenged the person in charge (for the lack of design) I got: Yes, but you don't know, and have no experience in, the methodology we're using here. Personally I believe agile is a methodology invented by managers who failed to understand the importance of design and documentation. Furthermore, I'm pretty sure this person has no clue about any methodology, bu rather "goes with the flow". 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. Opinions?
V.
(MQOTD rules and previous solutions)
-
Agile software development[^] I'm currently in a situation where I constantly run into changing requirements, "misunderstandings" (=other name for changing requirements, but I get the blame), dependencies on moving targets, ... When I challenged the person in charge (for the lack of design) I got: Yes, but you don't know, and have no experience in, the methodology we're using here. Personally I believe agile is a methodology invented by managers who failed to understand the importance of design and documentation. Furthermore, I'm pretty sure this person has no clue about any methodology, bu rather "goes with the flow". 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. Opinions?
V.
(MQOTD rules and previous solutions)
-
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.
(MQOTD rules and previous solutions)
V. wrote:
You convinced me even more that our organization should never, ever (!) use this.
My job is done. :) Marc
V.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
Agile software development[^] I'm currently in a situation where I constantly run into changing requirements, "misunderstandings" (=other name for changing requirements, but I get the blame), dependencies on moving targets, ... When I challenged the person in charge (for the lack of design) I got: Yes, but you don't know, and have no experience in, the methodology we're using here. Personally I believe agile is a methodology invented by managers who failed to understand the importance of design and documentation. Furthermore, I'm pretty sure this person has no clue about any methodology, bu rather "goes with the flow". 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. Opinions?
V.
(MQOTD rules and previous solutions)
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.
-
Agile software development[^] I'm currently in a situation where I constantly run into changing requirements, "misunderstandings" (=other name for changing requirements, but I get the blame), dependencies on moving targets, ... When I challenged the person in charge (for the lack of design) I got: Yes, but you don't know, and have no experience in, the methodology we're using here. Personally I believe agile is a methodology invented by managers who failed to understand the importance of design and documentation. Furthermore, I'm pretty sure this person has no clue about any methodology, bu rather "goes with the flow". 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. Opinions?
V.
(MQOTD rules and previous solutions)
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.
-
Agile software development[^] I'm currently in a situation where I constantly run into changing requirements, "misunderstandings" (=other name for changing requirements, but I get the blame), dependencies on moving targets, ... When I challenged the person in charge (for the lack of design) I got: Yes, but you don't know, and have no experience in, the methodology we're using here. Personally I believe agile is a methodology invented by managers who failed to understand the importance of design and documentation. Furthermore, I'm pretty sure this person has no clue about any methodology, bu rather "goes with the flow". 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. Opinions?
V.
(MQOTD rules and previous solutions)
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.
-
This is something I hear often. It's the idea that agile means you can skip the requirements gathering phase altogether. That is not, and never has been, the case. You still need a rough idea of what you're going to build. And it's your responsibility to work, with a representative of the client, to determine at the start of each sprint, what you are going to deliver. That means that they have to have provided enough detail going into the meeting to work out the rough shape and size of each task.
This space for rent
That is absolutely horrifying.
