![]() Now this was ten years ago and my memory is a little fuzzy on how the team split up the work and how long it took them to complete the feature. This feature required protection rights to be included in every document purchased from the website. In the industry this is called digital rights management, or DRM. The files were not encrypted or protected in any way from being copied or shared with anyone else. These very expensive documents were stored on a file server in the cloud. To give a better example, I worked on an e-commerce website that sold very expensive documents, books, and subscriptions in PDF and delivered electronically. The part of the iceberg that requires the most effort, the backend in this case of the example above, is split into separate vertical slices, with one of the slices containing UI changes. But slicing through an iceberg is not as difficult as it sounds. So how does a development team split up the work when it is in the shape of an iceberg? Slicing through an iceberg is not like slicing through a delicious, soft and moist cake. So instead of the work representing a slice of a layered cake, the work to be done is shaped more like an iceberg. You may have often seen the case where the backend code is very complex, but the UI only consists of a single button on a form to perform an intended action. Sometimes there is significantly more work in one or more of the software architecture layers than others. In Shape Up they refer to user story splitting as scope mapping and they explain what’s an “Iceberg.” The authors of the book briefly touched on this topic, but I’ll go over it at length and give a concrete example. The first time I heard about icebergs in relation to user story splitting was when I first learned about and started experimenting with Shape Up. Altogether, code gets shipped quicker with less rework and time wasted, than with splitting the stories horizontally by the different software architecture layers. Developers become responsible for the end-to-end development, integration is easier, and the team gets immediate feedback from the users. This typically leads to a lot of rework until the team gets it right.īy splitting feature or stories into vertical slices, the above pitfalls can be avoided. Whether the work is done in parallel or sequentially, integrating all the layers is more error prone and difficult to do.This makes it harder and longer to course correct in case the team is building the wrong thing. The feedback loop is a lot longer because users have to wait until all layers are done and integrated.This leads to developers that are experts in only one thing, as apposed to having “t-shaped” developers on a team. Developers may become siloed where developers only work in one area.There are three problems with this approach. When they do that, nothing works until you complete coding of all the software layers. Traditionally software developers would split a story horizontally into the different software architecture layers.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |