Sprint 4 Retrospective

-
Sprint 4 is over. It was somewhat of a disaster. I completely and utterly underestimated the amount of time it would take me to rewrite the data access layer, application layer, and presentation layer. In retrospect it was insane to think it'd go that fast; this is a rewrite of almost the entire project, which I originally created over the course of 3 months. Whoops.

Anyway I got through parts of the data access layer rewrite, and that's about it. I've increased performance in a lot of areas and improved the code overall. I'm now taking advantage of Java 7's try-with-resources statement, which is AWESOME and makes JDBC code much less hideous, and I'm no longer doing any catch (Exception e) but rather actually specifying the exceptions e.g. catch (SQLException e). I did also tweak my database tables, which necessitated rewriting my database creation and fake data creation code. I also wrote a test class to make sure the code I wrote is actually functioning properly. All of this more or less fell under the "Improve database access code so that pages load faster" backlog item.

I also realized pretty quickly that I did a horrible job creating the backlog items for this sprint. I did horizontal slices instead of vertical, which is, aside from being a huge agile violation, just a bad idea in general, as it left my project in a mostly unusable state. The data access code methods that I worked on work, but as the other layers were untouched, they don't work with the updated database code. So the project can't be run in order to actually demo the changes I made, other than through command line tools.

I stopped trying to keep a burndown chart pretty quickly, because the estimated hours basically kept going up... I spent at least 20 hours working on the project during this sprint, but it's hard to get more exact than that as I was also spending my lunch breaks and other short bits of time on it, as well. I do feel that I got in more hours during this sprint, so that's good.

So this sprint really didn't go particularly well from an agile standpoint, but I am pleased that I was able to work on the project more consistently and for more hours. Going forward in the next sprint I will definitely be rewriting my backlog items into vertical slices rather than horizontal. The next sprint will be odd though, as the next demo would fall during the week of Thanksgiving, which is a vacation from classes. So it will most likely be either one week or 3 weeks. I'll have to see what my professor wants to do tomorrow during the demo.

And that's it for sprint 4, since my burndown chart is useless due to my awful estimating and backlog item creation.

Comments

Post a Comment

Popular posts from this blog

"Does it get easier?" Yes, but Also No...

-
Image
Image by Arek Socha from Pixabay It's complicated... "Does it get easier?" I see some form of this question asked a lot in beginner programming groups. I always struggle with how to answer this honestly and clearly, because the truth is not that simple. In some ways it does get easier, but in other ways it is almost always going to be difficult if you are advancing in your career . If you are a programmer and your job is easy for years on end, the most likely explanation is that you're in the kind of dead-end position that people try to avoid, not the kind of position people dream about when they think of becoming a developer. Most likely you are not getting better at being a dev, not working with new tech or solving new kinds of problems, not being given more responsibility, etc. etc. etc. I've seen some pushback from other newbie programmers on the idea that it could remain difficult past the initial learning stage. Notably I have never once seen somebody who...
Read more

How to Land Your First Dev Job: Develop Yourself, Market Yourself

-
Image
Image by magnetme from Pixabay In the coding and tech groups I'm in, I see the same question asked over and over by folks who are just learning to code, finishing up a bootcamp, degree, or other training program, or who have been looking for that first job for awhile and not having any luck: "what do I need to do to get my first dev job?" There's a whole ton of info out there on this topic, but it's scattered all over, so I thought I would gather together the best resources I've come across and share them, along with a bit of context, to try and help everybody struggling with or just plain wondering about this. There are a lot  of things you can do to improve your chances of finding a job and hopefully shorten your job search. They are broadly divided into 2 categories: developing yourself and your skills, and marketing yourself and your skills. Note that you don't need to do everything on this list, nor do you need to do it all at once. This is an "...
Read more

Git. The WHAT and WHY Edition.

-
Image
Lately I've seen a lot of new/aspiring developers talk about difficulties learning git . I was confused at first, because there are approximately a zillion git tutorials out there. But then I started really looking at what people were saying AND what all those tutorials contain. The problem is most tutorials start out with "here are a ton of git commands to memorize", and this is not where people are having problems. People are having problems with "what is git, why should I learn it, and what does it look like to use it in a real-life project?", and those questions are largely not answered in all those millions of tutorials. So at the risk of redundancy, I'm going to attempt to address these questions in Yet Another Article About Git. First, I want to make it clear that if you want to be a programmer, any kind of programmer, you need to know git. You just DO. This is the short version of the answer to "why should I learn it?".  The medium length a...
Read more