This is a good point. In our most recent Java project, one of the first things we did was to set up Maven to package the project correctly. This allows for quick deployment and makes way for continuous deployment.
This is a good point. In our most recent Java project, one of the first things we did was to set up Maven to package the project correctly. This allows for quick deployment and makes way for continuous deployment.
2:53 PM
For your next project, consider adding this story to the very first sprint: As an administrator I want to install the program with an installer so that I can have everything in place without manual setup.Acceptance criteria:Application should run and show an empty screen Application should produce a log file that shows debug diagnostic information that can be used to trace through application runtime (timestamp, thread, logging level, component, message). Any fatal errors during start-up should be recorded with helpful diagnostic details. Any prerequisites for the installer must be known in advance or bundled with the installer The installer should have a minimal user-interface and optionally support running unattended The installer should put a shortcut on the desktop and start menu Sure, this is great, but why should this be the first story in my project? The short answer is this is the best time to do this. An installer created at the beginning of the project is often very simple as it will likely only be a handful of files. If you’ve ever written an installer, you’ll know that it can be a lot of work establishing all your dependencies and user-interface. If you wait until the end of the project when time is often a critical resource, you’ll fall into the trap of dropping this feature. The beginning of your project is also a really good time to start thinking about deployment. By creating an installer you’ll have a packaging mechanism for your testers and business stakeholders and every time they install your application they will be regression testing the deployment. Bugs will be found, and the installer will get better and more robust as the project advances. From a development perspective you might think of this as re-work. Try to break out of that mindset and think of it more like spreading the work over the project in small increments. As a final note, you may notice that some of the requirements refer to non-functional requirements like diagnostic logging. I’ve found this is a great way to set scope for the developers when referring to the initial “empty screen” and has an added benefit that lets testers know the location of the log files. Also, it allows you to associate defects for weird start-up errors and crashes to a User Story. Happy coding.
"The first User Story for your next Project"
2 Comments -
This is a good point. In our most recent Java project, one of the first things we did was to set up Maven to package the project correctly. This allows for quick deployment and makes way for continuous deployment.
2:53 PM
This is a good point. In our most recent Java project, one of the first things we did was to set up Maven to package the project correctly. This allows for quick deployment and makes way for continuous deployment.
2:53 PM