Sprint 5 Retrospective

-

So on Sunday I finished sprint 5. It went fairly well, although I didn't have as much time as I like, despite it being a 3 week long sprint. I was out of town for 4 days, plus there was that whole Thanksgiving thing, so it came out to be more like 2 weeks after all. Considering the amount of time I had, I think it went ok.

There were a few oddities and bumps in the road. First, I was highly annoyed when I discovered that in JDBC the table name/alias isn't included in ResultSet column names. Instead, you have to alias the actual column if you need to distinguish between column names in the result. Grr. Second, I discovered that it's really kind of a pain to call static methods using JSTL.  Since I use static methods in virtually every JSP to format the output for HTML/links/etc. to ensure user input doesn't do whacky things, this is a problem. For now I'm putting off rewriting the JSPs to use JSTL, because I'll have to write custom EL functions and maybe tweak the web.xml file to use the servlet 3.0 standard and all that will take awhile and probably a lot of tweaking.

I also somehow managed to forget when I did my sprint planning that I needed to change the database schema to include last login date/time for users as well as last edited by and last edited at fields for both tasks and projects. This is needed to do nifty stuff like show the user what updates have been made since they last logged in. So that was an unplanned item that I needed to take care of, and it required rewriting the database creation code, fake data creator, and some of the data access code. The fields aren't yet actually being updated properly nor are they being used for anything, so that will have to go into a future sprint.

So anyhow, the items I got done were:
  1. Change the database schema to include last login date for users and last edited at/by for projects/tasks: 4 hours
  2. Rewrite users page: 3 hours
  3. Rewrite user page: 1 hour
  4. Rewrite projects page: 1 hour
  5. Rewrite project page: 3 hours
  6. Rewrite new project page: 1 hour
  7. Rewrite instructors page: 1 hour
  8. Rewrite config page: 0 hours (I'd done the database part and found everything else still worked, yay!)
And there's also the time I spent investigating the whole JSTL/custom functions issue, starting to implement it, and figuring out it was going to take way too long, which was another 3 hours.

Unfortunately I completely forgot to record my progress as I went along, so I don't have a burndown chart for this sprint. I'll try and do better for sprint 6, although really, upon further reflection I'm not sure how useful these charts actually are for this type of project. At work they're extremely useful because we have a fairly consistent amount of time for each sprint. Even if we have unusual meetings or events they don't take up that large a percent of our time (2.5 developers x 40 hours a week x 2 weeks per sprint). When it's just one developer working in her spare time, it's a whole lot more unpredictable as to how much development time is even available in a sprint... Perhaps there's some better way to show the chart, possibly excluding days on which no work takes place? I don't know, but I shall ponder.

At any rate things went fairly well this sprint other than the nearly-ubiquitous lack of development time I've been facing. Luckily the next two weeks should be less busy, so I think I can get a fair bit done in before my last meeting with my prof for the semester.

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