Few thoughts on how some early projects went using Shape Up.
The extra work put into the shaping, clear expectations/boundaries really shine through with this approach. From a developers point of view it should be a more enjoyable way to work with clear expectations but enough freedom to be creative while implementing a solution.
1) Need a review app up and running as a part of the project setup. Main reasons for this:
The extra work put into the shaping, clear expectations/boundaries really shine through with this approach. From a developers point of view it should be a more enjoyable way to work with clear expectations but enough freedom to be creative while implementing a solution.
1) Need a review app up and running as a part of the project setup. Main reasons for this:
- Stakeholders can view progress and provide input as and when needed
- While performing PR's we shouldn't need to check out the code, install the gems, run the migration, build the assets etc just to check the functionality is working. Its the developers job to make sure the review app is fully functional.
- Always want a fully working version that could in theory be deployed at any time(we managed to get a V1 live very quickly with the core functionality providing value to the business). The outstanding items delivered later.
2) Stakeholders shouldn't be waiting until the end of development to see the functionality, regular updates/pushed as and when ready. No matter how small push them, one command line can achieve this. Make this as easy a possible using CI or Heroku Pipelines(auto deploy's on every commit).
3) As part of regular commits expect some type of test coverage, start knocking back PR's for changes that don't have adequate test coverage. It's the developers responsibility to make sure the tests are passing, the reviewer won't always have time to run them as apart of a PR. The CI will help this further so the developer doesn't need to think about it.
4) Don't treat tests as an afterthought, the earlier you write them the more benefit you get. They provide the following amongst other things:
- Quick feedback making sure you are working towards the end goal
- If you need to change approach you can quickly achieve this by running the specs to make sure the functionality is still working once you have made changes
- Documentation
- Proof the new functionality works and is achieving the goal
5) Try and focus on the most important/next immediate item on hand. If you think too far ahead by creating/mapping out all the various other components/possibilities the work will become too daunting and the developer is likely to get sidetracked. It may be the case that a project is abandoned if an early piece of work throws up an unknown/unexpected rabbit hole. That time spent mapping items further down the line may be a wasted effort.
More to come....