Sprint 6 Retrospective

-
Yet again my biggest problem during this sprint was finding time to work on it. Considering the time of year, this isn't really a surprise. All the same, I had hoped to have more time than I did. During sprint 7 I'm going to try as hard as I can to work on the project at least a little every day. I've got a lot of stuff to do before next semester, so I want to get to doing it! I also thought of a number of things I had overlooked and discovered a few odd bugs, so the product backlog grew a bit during this sprint.

I finished rewriting the new file link page (3 hours), the new user page (1 hour), the new task page (2 hours), new comment page (1 hour), the task page (3 hours), and I fixed the bug with navigating to the projects page (15 minutes). Some things took a good deal longer than estimated...

There were no big issues during my development time, however I realized I had completely neglected to include time for making editing of tasks and projects work. Basically I was just concentrating on making things show up correctly and work when creating new entries. Whoops. So I added an issue to the product backlog for that.

In addition I realized I needed more guidance on how and when users should receive emails about updates; I got clarification from my adviser during our meeting so that's all good, and now in the product backlog.

During this sprint I also started looking into options for places that host git repositories. My adviser uses SVN, but I use git at work and really love being able to do local commits. I also want to back up my work more often but not check in code to the SVN repository when it's half usable, and git would allow me to do that (or I suppose any other version control system I choose to use that would be under my control, but I like git). So anyway I looked at the options and decided on Bitbucket, since I can have free private repos there. I'd feel rather odd making my Masters project public at this point, and I'm not sure my prof would approve of that anyway. Now that I've decided where and how I want to do this, I really want to get git set up and working during the next sprint. Having my code backed up in another location will also be rather reassuring, so it's a good plan for many reasons.

So in summary, the only real problem I had was a lack of time, so I'll be trying VERY hard during sprint 7 to work on the project more consistently. Wish me luck!

I did remember to actually keep a burndown chart this time. I only put in the days when I actually worked in the project (thus it highlights how few days that was):


I guess it highlights the problem in my process, which scrum is supposed to do, so yeah. It's rather guilt-inducing though...

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