How Mendz.Data.* Improves Productivity
Mendz.Data.* helps teams delegate and separate concerns. Not everything needs to be done in a single project. You can use Mendz.Data to distribute tasks so that deliverables can be created concurrently, tested independently and later assembled/integrated together for functional testing.
Full-stack developers are great! However, for teams designed to work like an assembly line, it can help compress the project calendar if different members of the team can work concurrently with the tasks and items to deliver for a requirement. For example, if you are using Mendz.Data.SqlServer with stored procedures, you can have a developer assigned to creating the stored procedures, another to create the POCO and repository, another to create the controller, and another to create the views. This distribution can appear costly, because of the number of players involved. However, should the calendar matter for the project, this assembly line strategy can help speed up development, testing and delivery. If you are doing two week sprints, this means more items getting created and tested per day. Potentially, it also maximizes how much of the product can be delivered at the end of the sprint.
Mendz.Data allows for contexts to be created as separate DLLs. Repositories can also be created as separate DLLs. Even POCOs can be created in separate DLLs. As needed, these class libraries can then be referenced by the application. The modularization and separation of concerns can help in staggered product deliveries. For example, parts of the back-end can be created and delivered ahead of the front-end. Sprint 1 can focus on delivering the back-end and the front-end designs. Sprint 2 can focus on implementing the front-end designs while new back-end requirements are being developed. And so on and so on...
The ability to deliver back-end requirements as products by themselves, and delivering front-end requirements as products of their own re-defines what a minimum viable product (MVP) is. By splitting a requirement as part back-end and part front-end, with each part considered a product on its own, teams can better plan their projects and deliverables with consistency and quality as the main/primary drivers. A "rolling" strategy can be tried out per sprints, helping to maximize the potentials of the team.
All that seem grand. In fact, Mendz.Data really has nothing to do with it. But if such distributed development strategy is applied and practiced by the team, Mendz.Data is ready to support it. Mendz.Data is not designed to be intrusive or normative. It is not designed to restrict. In fact, Mendz.Data does not claim or pretend to be bigger than what it really is. For all intents and purposes, Mendz.Data is designed to be "guiding". It suggests how something can be done consistently. If used right, Mendz.Data can help teams start right the first time, immediately avoiding the traps of producing a big ball of mud.
Get Mendz.Data and give your project a head start, done right the first time.
Full-stack developers are great! However, for teams designed to work like an assembly line, it can help compress the project calendar if different members of the team can work concurrently with the tasks and items to deliver for a requirement. For example, if you are using Mendz.Data.SqlServer with stored procedures, you can have a developer assigned to creating the stored procedures, another to create the POCO and repository, another to create the controller, and another to create the views. This distribution can appear costly, because of the number of players involved. However, should the calendar matter for the project, this assembly line strategy can help speed up development, testing and delivery. If you are doing two week sprints, this means more items getting created and tested per day. Potentially, it also maximizes how much of the product can be delivered at the end of the sprint.
Mendz.Data allows for contexts to be created as separate DLLs. Repositories can also be created as separate DLLs. Even POCOs can be created in separate DLLs. As needed, these class libraries can then be referenced by the application. The modularization and separation of concerns can help in staggered product deliveries. For example, parts of the back-end can be created and delivered ahead of the front-end. Sprint 1 can focus on delivering the back-end and the front-end designs. Sprint 2 can focus on implementing the front-end designs while new back-end requirements are being developed. And so on and so on...
The ability to deliver back-end requirements as products by themselves, and delivering front-end requirements as products of their own re-defines what a minimum viable product (MVP) is. By splitting a requirement as part back-end and part front-end, with each part considered a product on its own, teams can better plan their projects and deliverables with consistency and quality as the main/primary drivers. A "rolling" strategy can be tried out per sprints, helping to maximize the potentials of the team.
All that seem grand. In fact, Mendz.Data really has nothing to do with it. But if such distributed development strategy is applied and practiced by the team, Mendz.Data is ready to support it. Mendz.Data is not designed to be intrusive or normative. It is not designed to restrict. In fact, Mendz.Data does not claim or pretend to be bigger than what it really is. For all intents and purposes, Mendz.Data is designed to be "guiding". It suggests how something can be done consistently. If used right, Mendz.Data can help teams start right the first time, immediately avoiding the traps of producing a big ball of mud.
Get Mendz.Data and give your project a head start, done right the first time.
Comments
Post a Comment