The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
I was sent a job spec that seemed right up my street. It's an old vb6 application that does what it should and they don't really want to replace it yet. What they do want is a link out to a reporting engine.
Generate data sets I think, maybe XML or even populate an external db. Sadly no, the Eejit running the project wants to use a certain product that I will not speak of - lets call it Chrystal Meths. I have politely said I would gladly build the interface to any third party tool they choose, but I will not go near that product.
But surely after you've built the interface it'll be easy to create the reports? "Fnufff!" was my muffled reply.
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.
Yes, but you don't know, and have no experience in, the methodology we're using here.
Then it is up to him to explain the process to you - and you should be able to challenge every assumption, logical fallacy, incorrect belief that he comes out with. If the process is so strong, he should have no problem with you questioning it.
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
Last Visit: 31-Dec-99 19:00 Last Update: 20-Feb-17 16:46