-1

Introduction

In our development team, we divide developers into back-end and front-end teams. To develop a feature for a website, the 2 teams have to work in parallel. We starts by analyzing the requirement, talk about all possible business cases that should be handled, and have agreement on APIs interface specification that regards the solution for all cases. The back-end team then build the mock version of the APIs according to the specs (using Spring Boot). The front-end uses the mock APIs to develop the UI (using VueJs).

During the development, when the developers focus deeply into the real code, they always find more business cases that the team has never talked about. Meetings are arranged to discussed about this, and often the API interface specification will have to be changed. The developers always have to rework, and the project is delayed.

This problem reoccurs everytime in our development cycles. The management challenges us to find a solution so that all the business cases have been considered during specification design and no cases should be popped up during implementation that affects the specification.

As a developer, I list the cases as much as I can think in the design phase, but they are never completely covered all the cases. Only way I can discover the missing cases is to write the code.

Question

Is it common (and okay) to have specification change during implementation phases?

If so, how do you handle the change to minimize the impact that causes project to delay?

If not, could you please suggest what might be wrong for development process in general that obstructs development team to have clear and complete specification before implementing.

  • How would you describe your development process (Agile, Waterfall, etc.)? It looks like your team is attempting to do a Big Design Up Front, which might not be appropriate for your project. – Vincent Savard Mar 15 at 15:58
  • @VincentSavard We don't have a clear definition of our process. We tried to be agile from the beginning. We have sprints, in which we decided what feature should be done at the end of the sprint. We also have sprint planning at the start of each sprint, in which we analyze the requirement and design the specification. The program is expected to be delivered to the customer for acceptance test for each sprint. And the defects are expected to be minimized. For the next sprint, we continue developing the next features. – asinkxcoswt Mar 15 at 16:08
  • My PM often considered our process a mini-water fall as we have a fixed plan to deliver which features on which dates. It is not a full water fall because features are not recognized and designed by development team until the time they are put in the sprint back log – asinkxcoswt Mar 15 at 16:23
  • 1
    You're doing the design phase in sprint, or before? If you're doing it during your sprints, do you think your stories are too large? It's entirely normal to find new stuff during development, and a story shouldn't be a reference of exactly what should be implemented, it should be the start of a discussion. It seems to me that you're putting a lot of emphasis on design during sprint planning, and that might be a bit too premature. – Vincent Savard Mar 15 at 16:58
  • thank you for the enlighted suggestion. Our technical design is done at the start of each sprint. And it has been being attempted to minimized unplanned stuff. I seems to agree with you that the attempt often is premature that we often spent most time talking about littile cases. From your suggestion, does this mean that we should not make an agreement with customer that a feature will be fully done at which date, instead, we should say that a feature will have 2 or 3 versions and the first version delivered at date X should not expected to be fully usable, right? – asinkxcoswt Mar 15 at 17:36
1

You need to redesign how you approach your development. You have an application team, not front and back teams. These people need to work together and collaborate all the time. They should be co-located for better collaboration, or have appropriate remote communication tools. Changes should be expected as you develop, most software projects have massive unknowns, you adapt to this by adopting processes that make changing things as easy as possible.

If you have a story to add a new Foo detail screen in a sprint, assign front end Jack and Back end Jill to the story and let them create a rough draft of an API in about 15 minutes and let them develop from there. Then if Jack discovers that foo details sometimes have special property X that wasn't in the initial spec, or if Jill discovers they need some Bar details, then they talk to each other and redefine the API spec as needed. Then when they are both confident development finished write up the final version of the API if you really need that documentation. Another important thing is to integrate changes as early and frequently as possible, because you will start uncovering issues faster as well.

Separate teams all designing to a spec only works if the spec being designed to is perfect. I'm willing to bet that in your current set up the time between when the first person finds a problem with the spec to the time when all teams agree on a solution is measured in days, that puts you behind very quickly. Then, you have a team spending time developing against a known bad spec, which puts things further behind while they believe they are progressing. The more integrated your teams become, you can get that time between identifying a problem and having a solution down to hours or minutes.

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.