views:

70

answers:

6

You work on an important project that contains 7 independent modules, and you do not have enough time to finish the project in time. In front of you is a choice: to complete 3 modules in full or to start work on all the 7 modules in parallel, but not complete any of them within the planned period. Which strategy you choose?

A: 

Complete the 3.

Then they can be released for testing to the client, and you can get to work on the other 4.

Noon Silk
+1  A: 

Whichever is better for a customer/business. If it's possible to have all 7 "feature" in semi-complete state -- then go for it. If they prefer 3 polished "features", go this way.

Anton Gogolev
+2  A: 

Explain the situation to the manager, let him decide. That's why he's there.

If you're in charge, then you need to consider all possibilities. I'd say, focus on what the customer will need in the first turn, and complete the second-priority functionality afterward. If possible, talk to them, explain and try to reach an agreement. The customer may have a different opinion on what he will need the most and give you direction to focus your efforts in.

Developer Art
A: 

That very much depends on your development model and the customer requirements. In an agile environment I'd rather show the complete product (even with unfinished/mocked parts), so the customer gets an impression of it in its entirety and can give you early feedback on the unfinished modules.

If there are clear, precise specs however, then delivering the 3 finished modules is probably a better idea.

Matthias
+1  A: 

It depends on what your customer values.

Are the modules really independent? Are they really needed in full, or can they provide value even if implemented partially?

A useful strategy is to implement vertical slices accross the system or even a module, not horizontal layers of modules. Implement one end-to-end feature/use case/user story at a time. It is these features that bring value to your customer, not modules (unless the customer is an odd one valuing modules and not features). This way you get something useful ready for testing and release, and your time is not spent on writing code that is not used by anyone. However, when adding new features, you need to keep on refactoring the codebase in order to avoid the stovepipe system anti-pattern.

In any case, implementing the 7 modules only halfway there is not the answer. Whatever you do, do it right the first time. ("Right" being of course context-dependent: different standards apply for throwaway prototypes, life-critical production code and everything in between.)

laalto
A: 

Client has a clear picture of exactly what he wants, and my job is to show him something that will attract his attention and give me additional time to complete the project. Each module requires one month of work, but after three months the client decides whether to continue the cooperation or not. The user interface is the only thing that interests him. I can not explain to him that I spent two months making engine if he does not see it on the screen.

šljaker
laalto