Tag Info

Hot answers tagged

6

Summing up information from this blog : The analogy is trains are releases, passengers are features Trains are planned at regular intervals, without knowing what they will contain If features aren't ready for departure train, they can go on the next one Once a version is shipped, the development splits between support/patching shipped code and developing ...


4

You're trying to use a bulldozer to hoe a garden. Stop it. The client & your management are happy with the current (primitive, simple, dangerous) process. This process works for a small app with a single trusted developer. Since you're making all your changes on production, if you introduce a bug it's likely that someone will spot it quickly. Not ...


4

Ah, the client with a small website who doesn't want to pay too much. You can't argue your way is better when the client has evidence that the other developer was able to make it work. Let the client know that your group is not use to working that way and if you have to drastically alter the way you work, you cannot predict how effective you'll be. From a ...


4

It's about integration. The vast majority of software exists simply to integrate systems together so that tools and data and various things can all interoperate to make larger more robust products. The amount of any industry that is inventing novel products rather than taking known products and combining them is terribly minuscule, this goes for the ...


3

It is not possible to give a perfect answer without specific details. However, I could make some general remarks. Yes, software of this kind is complex to implement. It takes lots of programmer time, but even more so it will require a business process analyst type of role that can map your processes to the software. This is often the meat of the work and ...


3

This has the potential to end up as a bike shed argument. Nevertheless, what I found are the biggest discrepancies between academia and "the real world" are: Don't expect to make a good living only by knowing the tools. Learn a domain instead, and apply programming to that. To quote this website: People who can code in the world of technology ...


3

You've come up with the answer you want and now you're just soliciting confirmation. STOP IT. The correct question isn't "Why shouldn't we...." -- rather it's "Should we...." Research the underlying question, don't just try to support the answer you want. Here's some starters: PRO Lower cost (multiple thin clients) Higher flexibility (any machine will ...


3

An RDP connection is going to be slower to work on due to the latency. You'll type a line of code, and have to wait a bit for it to show up. On a fast connection (LAN) this probably won't be noticeable, but on a slow connection (like over an ADSL link) this will be noticeable, and (in my experience): Make you work much slower (as you wait for the keyboard ...


1

In simple words: user stories are not use cases, and user requirements are more fine-grained document of requirements that are usually approved (or pre-approved) by client. The user stories don’t provide the details the team needs to do their work. The Scrum process enables this detail to emerge organically, mainly by removing the need to write use cases. ...


1

At first you could try to collect the different requirements from all stakeholder in a brainstorming workshop. Normally this is a good starting point to get a first overview about all the different expectations and use cases. With this you can start to develop a first global picture of the system. It is much easier to discuss your concerns when you know some ...



Only top voted, non community-wiki answers of a minimum length are eligible