0

Currently the software development lifecycle followed in the IT company I work at is:

  • The "Business" works with a solution manager to build a Business Requirement document

  • The solution manager works with the Program manager to build a Functional Spec

  • The PM works with the engineering lead to develop a release plan and with the engineering team to develop technical specifications

  • If there are any clarifications required, developers contact the PM who contacts the solution manager who contacts the business and all the way back introducing a latency of nearly 24 hours and massive email chains for any clarifications

  • By the time the tech spec is made, nearly 1 month has passed in back and forth

  • Now, 2 weeks go to development while the test writes test cases

  • Code is dropped formally to test, test starts raising bugs. Even if there is 1 root cause for 10 different issues, and its an easily fixed one, developers are not allowed to give fresh code to test for the next 1 week. After 2-3 such drops to test the code is given to the ops team as a "golden drop"

( 2 months passed from the beginning)

  • Ops team will now deploy the code in a staging environment. If it runs stable for a week, it will be promoted to UAT and after 2 weeks of that it will be promoted to prod. If there are any bugs found here, well, applying for a visa requires less paperwork

This entire process is followed even if a single SSRS report is to be released.

How do other companies process such requirements? I'm wondering why, the business cannot just drop the requirements to developers, developers build and deploy to UAT themselves, expose it to the business who raise functional bugs and after fixing those promote to prod. (even for more complex stuff)

  • 2
    What would you consider efficient? If you're talking about a project with ten million lines of code involving multiple organizational structures, you may need all this infrastructure. If it's just 100,000 lines, not so much. – Robert Harvey Jun 10 '14 at 16:38
  • @RobertHarvey < 10k LOC per release here. 99% of the work is onboarding systems to ETL processes, absorbing changes from upstream systems and requests from downstream systems, and creating SSRS reports. Wondering why a process like I've mentioned in the last 2 lines isnt used in the industry – user87166 Jun 10 '14 at 16:40
  • 1
    Looks like a system where, when the product is done, they know beforehand the features they will get, and that it will stable... it is way more efficient than letting the programmers guess what is needed, and asking the stakeholders about it after finishing the modifications. – SJuan76 Jun 10 '14 at 16:47
  • 9
    You're complaining about waterfall, go read about it and realize everybody else recognizes it's terrible inefficient too. That said it's still used because for all it's inefficiency, in a variety of cases given the correct set of constraints, it actually works to the point of getting well-functioning IT products and services to business users. While it's unarguably inefficient, sometimes the inefficiency is worth it for the decreased risk waterfall has in the right scenario. It sounds like it's working well at your place, even if frustratingly overbearing... – Jimmy Hoffa Jun 10 '14 at 17:13
  • 1
    Agreed that this sounds like waterfall development. I'd suggest you contrast against methodologies like Extreme Programming, Agile, and DevOps. Sometimes waterfall is the right answer (e.g. NASA can't iteratively launch a rocket), but usually it is frowned upon in general software development. – Allan Jun 10 '14 at 19:30
3

How do other companies process such requirements?

Differently.

Different businesses have different processes because they have different needs, different risk tolerance, different resources...

I'm wondering why, the business cannot just drop the requirements to developers

Often, because it's difficult/impossible/expensive to find developers that are good at being developers and also good at talking to business people. The opposite is of course a problem too - finding business people who are good at business and can talk to developers.

developers build and deploy to UAT themselves

Often, because letting Ops do it frees the developers to focus on the code. It also let's the Ops people learn how the system works and maintain/support it. That support can make or break a product.

But all of this is (mostly) devil's advocate on my part. Too often, process is implemented by managers who don't trust their employees to do their jobs rather than documented (and continually re-evaluated) by managers so that new employees can more easily learn how to do what everyone else does.

0

•The "Business" works with a solution manager to build a Business Requirement document

Your team must be ready, willing and able to work with the "Business" and create requirements. They may want to keep the same document formats and probably interpret those as some type of agreement or contract between them and the developers. If your development team has a preference to some other type of documentation (sticky notes on a board is still documentation, just not traditional), you may be able to convince the business to accept this. Ideally it is something everyone understands and agrees on.

Now all you have to do is decide what all these other people are going to do. Whether you realize it or not; you not only declared war, but fired the first shot.

0

Short answer: Other companies that don’t use the waterfall approach that you’re describing to build IT solutions often use an Agile approach, e.g., Scrum or eXtreme Programming.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.