This project was centered around an application capable of being an end point of a link mailed to my client customer. Where they would be able to accept and download some PDF contracts and the like.
- - too much on my table, bad planning again I was suddenly doing two apps at the same time
- - stress resulting in best practice neglect, when bugs was reported unit-test were not implemented, the time constraints was probably to blame, but still
- - design flaw in app. The application ended up having a serious design flow in the flow, so going back to a certain page in the flow of pages
- - bad bugfixing introducing new bugs, in line with the above point on use of unit-tests. The bug fixing was somewhat hectic, resulting in introduction of new bugs
- + true to in-house process, we followed the in-house process, I do not like the process, but we used it
- - in-house process as I wrote above, I do not like it, it is a rigid waterfall process.
- - bad communication on key parameters in technical solution, some key parameters in the project ended up in emails and places, these should be communicated clearly on what I refer to as the: Project Data Sheet
- - lacking promised flow diagram, never received a flow diagram promised in the specification
- - too short estimate, the estimate was perhaps a bit on the low-side
- + Hash::Flatten, this module is very nice – it took some time to get it working with XML, I consider integrating it into hour application server and framework, so it’s use become transparent
- + good tests could be re-used to assert deployment, some of the unit-tests really proved their worth when deploying, since the setup could be asserted as working
- + good scope for application, project size was good, not too big
- + release based strategy, the back-end team used a released based approach, which lacks many places in the organization
- - should have been tracer bulleted, the whole project should have been run as tracer bullet development
0 Comments.