How should process be different for front-end vs back-end?

I’m looking for references that might help explain what I’ve seen in software engineering regarding processes for developing in the front-end vs the back-end. They are both difficult, but I tend to feel that the front-end is easier to write stories for, and to possibly estimate the amount of effort (time).

There might be a number of reasons for this: sand-boxed tech (js, css, html), the visual aspect lends it self to themes/grouping/modularization, etc, Users interact with the UI and process artifacts tend to be called “User” stories which implies that the process wants to capture a goal that entirely is visible and improves the quality of life through the front-end.

As for the back end in contrast: there aren’t typical UIs, and the data varies greatly to provide details for operations (logs, metrics, deployments, etc). Yes data for the front-end can be varied as well. The User is almost always either a dev or support, but these people rarely sign-off or “accept” these stories, and they are rarely the stake-holders for the implementation, much less control the budget for the implementation. Also, there doesn’t seem to be any notion or complete set of back-end tools like js,css,html are for the front-end, and therefor also no compatibility layer.

With this in mind I’m hoping to understand if it makes sense to use the same software development process for both the front-end and the back-end? Yes there are users of either system and breakdown of work needs to occur, but the biggest difference hidden in the above descriptions is that the front-end Stories are after some visual design, while the design in the back-end is coupled with task breakdown for back-end.

Perhaps, as is generally the case, this is a bias from my own experience? Other approaches are sure to exist, especially based on project size and scope, etc. I’m simply looking for some more insight. How should process be different for front-end vs back-end?

Go to Source
Author: lucidquiet

(Scrum) Does an increment involves always a working prototype?

I would like to ask a question about Scrum.
At the end of a Sprint, when we have the Sprint Review, we present an Increment

The guide says that this Increment has to be potentially releasable.

My question is, does this mean that every increment should involve a running prototype of the software we are building? (even involving some mock functionality or data at the beginning)

(I know that it does not have to be fully operational of course)

EDIT: Perhaps my understanding of the word “prototype” is wrong. What I meant by “prototype” was a operational ( if not fully functional) piece of software that can be run and be executed

Go to Source
Author: KansaiRobot