16 December, 2015 · 4 minutes to read · written by Rob Gregory
When it comes to delivering a quality digital product having a killer development strategy is where the top software development companies standout. In this post I'll cover how our technical team plans bespoke software development projects with clarity and purpose.
You are redeveloping a digital product. So as a project team you've planned your architecture using great decision making tools and methods and you've settled on the correct technology choices for your product redevelopment. Next up you need a strategy to actually deliver the development.
There are 3 key areas to creating a software development strategy:
In software development there are no exacts when it comes to estimating and planning tasks. It simply isn't possible to know everything before you start. This is why the industry has moved (still moving) from the more strict Waterfall approach to a more flexible and reactive Agile / Lean approach.
The Agile approach is about being better at planning as you go rather than doing all of the planning up-front. So how do you provide estimates for a task and how do you plan them into your teams schedule?
First you need to break your development into tasks - a senior technical person and a project manager or product owner will do this. Next up you need estimates for these tasks.
Planning Poker is a great way to get estimates for development tasks based on team consensus. Through gamification each team member is asked to throw down a poker card (values 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100) that represents their estimated effort for a task.
If there is consensus then that is the estimated used. If no consensus is reached then estimates are discussed with the highest and lowest estimators sharing their reasons. After this discussion the estimators are all required to reselect a card throwing it down at the same time. This is repeated until a consensus is reached.
We have our estimates next we need to plan and manage our tasks. kanban has established itself as the best way to manage tasks, and more importantly the way to manage the progression of tasks. The kanban principle, established by Toyota back in the 1940's is a way to visulaise tasks in order to manage them in a "Just-In-Time" way.
kanban has been adopted by the tech industry to help development teams to plan and progress development tasks.
Development tasks broken down, estimated and planned the next job is to settle on a development methodology. There are a number of options here.
Test-driven development is a style of developing code where three activities are linked together: coding, testing (writing unit tests) and design (refactoring). Here's the process.
TDD is a good choice for bespoke software projects as it ensures test are written for much of the code.
Similar to test-driven development, ATDD uses automated acceptance tests with the additional constraint that the tests are written in advance of implementing the corresponding code.
In the ideal situation (although not that easy in practice), the product owner, customer or domain expert should be able to specify new functionality by writing new acceptance tests or test cases, without needing to consult with developers.
BDD takes TDD and ATDD and adds a few new tactics:
BDD offers more precise guidance on organizing the conversation between developers, testers and domain experts.
Extreme Programming is a pragmatic approach to software development that again puts the emphasis on business results by taking an incremental, get-something-started approach to building the product. XP uses continual testing and revision.
Also, rather than specialise, all team members write , test, analyze, design, and continually integrate code as the project develops. Because there is a lot of face-to-face communication, the need for documentation is minimized.
The final part of setting out your development strategy is to consider code integration and how you are going to deploy your digital product.
Continuous is the buzzword of the moment and there are certainly merits in keeping a low-friction pipeline from developer to live.
Back in the summer I wrote a post Continuous Integration vs Continuous Delivery vs Continuous Deployment that looks at what Continuous means.
Your strategy should include how developer code is integrated into a central branch or trunk in source control, how that is delivered to a staging or test environment and finally how your code get's deployed to a production environment.
Tools to look out for are:
At Magnifica when it comes to building bespoke software products we are fanatical about ensuring our development strategy is fit for purpose. That means we take each project on its merits and put together a custom development plan at the start of each project.
If you have an digital product that you are looking to redevelop please give us a call on 0114 3863186 to speak to one of our software experts based in Sheffield.