Our Crunch Time

My morning at work began with remaking our burn-down chart like I mentioned in my last post. After our daily scrum I asked the group how they felt about our progress in the sprint, and (with some Scrum Master coaching from Jef) we started a discussion about whether or not we could finish everything in our backlog and the possibility of removing some features. We decided to reduce our scope a bit and removed features that were heavy on design/graphics.

I think this was a good move and will allow us to finish sprint with all tasks completed. Today was however our last full day of work so we still had a lot to get done. We will have some time to work tomorrow morning but the second half of the day will be taken up by our review (including preparation) and our retrospective. Judging by what was left on the board at the end of the day I’m fairly confident that we will complete all tasks on the board in time for lunch tomorrow.

I don’t want to get into the technical details of the work Dave and I completed today because I don’t think there’s much to comment on. I will say that Dave and I have worked fairly well together this week. We’ve gotten a lot done despite both of us being new to MVC and Razor. Dave does have some HTML experience which has been very helpful. I still need to work on pairing; I tend to get in the zone and I neglect to communicate what I’m doing and actually involve my partner. Dave is pretty good at just working on whatever HTML stuff we might need when I do that but that doesn’t excuse my communication issues.

This week has been enlightening and challenging. I look forward to the end of it.

 

Our Slow Pace

This morning we decided that we as a group needed to know more about MVC and Razor syntax, so we watched some tutorial videos on those subjects. The videos were very helpful, but they took up a lot of time and I’m worried about how little we’re getting done this sprint. We made some effort to break tasks down to a finer grain but we still have very few completed. Even though I believe tomorrow will be very productive, I plan on calling attention to our lack of progress after our scrum tomorrow.

Today Dave and I moved forward a bit on the view we’ve been working on. We were originally thinking of using partial views for our different badges after seeing them illustrated in one of the tutorials. We played with that a bit before Jef steered us in the direction of using display templates, which seem like a much more appropriate option. The tricky part with that was figuring out a way to go through the list of badges and display each one according to its template (I think I need to study Razor and lambdas a bit more, along with a few other things).

Dave had an obligation that forced him to leave a little earlier than me. Soon after he left, I (well, Jef) figured out what I was doing wrong and fixed it. After that was done I just needed to generate and refine the display templates for each badge. Once I completed that task and confirmed that everything was working as it should I pushed up to the git repository. At that point I figured I was done for the day. I thought about remaking the burn-down chart since we changed/added to our tasks a bit, but I decided to do that in the morning.

Our MVC Sprint

Today was the first day of the work week, which means it was the beginning of a new Sprint. This week we’re focusing on building out our UI using the MVC (Model-VIew-Controller) architectural pattern. I’ve never had to build a UI, so I’ve never used MVC, so I am entirely out of my element. Did I mention that I’m also playing Scrum Master for this Sprint? This week will certainly be a learning experience.

The day started with Jef talking a bit about MVC, and after that we planned out our sprint. That’s all we managed to get done before lunch. During lunch I performed one of my Scrum Master duties and created a Burn-Down Chart for us to use throughout the week. After lunch Dave (my partner for this week) and I started working on the Badges page. It took us some time, but we figured out how to write a basic controller and view for our page and after confirming that it built and ran as it should we pushed it up to the git repository.

Dave and I then discussed how to display progress towards each pending badge, which took some time. After a while Dave left for the day and I stayed a bit longer to play around with an idea. I don’t think we had reached a final conclusion, but I can be pretty stubborn and I can’t expect him to stay all night. Our conversation would likely have been much shorter if Jef was around to answer questions (as the Product Owner), but unfortunately he had something important to do. We’ll ask him tomorrow. 

Our Retrospective

This will be the last post catching me up on blog entries from last week.

Friday, May 23

I started the day by spending thirty minutes in the break room practicing something called silent pairing with Jef. Silent pairing is simply pair programming without audible speech; the basic idea is to let your code speak for you. After I returned from that I worked on finding a way to name/organize our tests and test structure in order to make them more readable. I think I came up with a pretty good general model, but we have yet to use it so we’ll see how it goes. Finally, Jon and I wrote one or two more tests for the Know-It-All badge in order to finish up that task before our review.

I think this was our first formal review. It went… ok. While we produced a large chunk of code with (mostly) passing tests I don’t think we quite knew how to go about reviewing our work for others. This is something we talked about in our retrospective so hopefully we’ll be more prepared next time. Our retrospective this week was run by a couple of Agile coaches at Improving: Cherie Silas and Allison Pollard. We went into great detail about what we did and didn’t like about the last week and came up with ways to do things better. This discussion resulted in a list of working agreements, which we will begin using in the next week.

Our Momentum

This is post number three of four catching up on my blog posts.

Thursday, May 22

We started with a lecture portion again, but this time it was mostly about LINQ. I had already looked into LINQ a bit and Jef had previously shown me a few things so I had an easier time understanding everything he was showing us. I was working with Jon again but this time we started working on the Know-It-All badge, which is awarded for attending all four Quarterly Town Hall meetings. I was still a little uncomfortable with pair programming, but Jon and I managed to get some tests written and passing. We made progress even though I was having a few problems with the process.

We got to a point where I realized that I wasn’t sure that we had every possible scenario covered and I began to try to fix that. I became a little overwhelmed with this and ended up surrounded by cards with all kinds of notes and graphics trying to understand all of it at once and map it all out. I was Goldbluming, and that was bad. I hang around to avoid traffic every day anyway but I should have been decompressing from the day (and/or writing this blog post) instead of spending a couple of hours on that and not really getting anywhere.

For those who didn’t understand the “Goldbluming” reference:

My Control Issues

This is the second of four posts written in an effort to catch up on blogging for the last week.

Wednesday, May 21

I started the morning by moving some of the tests I had written the day before to appropriate test files. We started the day by going over some concepts Jef felt we could use in our game. A lot of it (most of it) went over my head at the time, but I have since begun to understand and use the tools he was trying to give us. I have in my notes that I updated the model a bit that morning; I think I mostly just updated the Improver object but there might have been a little more (I should probably make my notes a little more detailed). I worked on MonthStreaker tests a bit before moving on to the Two Bits badge.

In our game the Two Bits badge is awarded for attending a Quarterly Town Hall meeting (This is achieved by answering a question about the meeting). I was working with Jon on this (I probably should have been working with him before) and I was having trouble getting used to an agile software development technique called pair programming. In pair programming one person writes code while the other observes and helps guide the person writing code. This was difficult for me because when I was observing I had to explain everything about why I thought the code should be a certain way instead of just writing it. I understand and agree with the benefits of pair programming, but I think it might take a little time for me to be comfortable with it.

My Unsustainable Pace

I got waaay behind on my blog last week so the this and the next few posts will be catching up on that.

Tuesday, May 20

My notes from this day are light, but I’ll write what I can. I apparently did some work on the Badge abstract class before lunch, but I remember the thing the really consumed my day was working on the badge called Month Streaker. This badge is awarded when a person enters time each day (for that day) for an entire calendar month. This is one of the first badges added to the game and that means Badge behavior was not very well defined at this time. I knew this going in (and I think I tried to bring it up earlier) but I decided to start working on it anyway.

If I remember correctly Month Streaker was my task so the problem wasn’t that I was working out of task, the problem with what I did was that I did way too much coding before I wrote any tests for it and I did it for way too long. I got so caught up in fleshing out the MonthStreaker class according to how I thought it was going to end up working (instead of just making the test pass) that I forgot about testing entirely. After a while Jef reminded me by asking if I had done any testing, but after I wrote several tests testing what I wrote there were a few that were failing and I couldn’t figure out why. I eventually did (it was something small and silly) but that night I stayed at the office until 9pm trying to figure it out, which was bad. I need to learn to work at a sustainable pace, and by that I mean that I need to work at a pace at which I can work every day of a sprint. 

Our Day of Progress

Today was a step forward for us in terms of figuring out Scrum and being productive. We started with a quick review of our work last week and then we got into the retrospective. Everyone was able to voice what we liked and wanted to change and we came up with pretty good lists for both. Jef helped us categorize the needed (or wanted) changes so that we could find solutions for each category. The easiest one was fixing a problem with Git so we took care of that before breaking for lunch. After lunch, Jef named our Scrum Master for the week (we each voted and Jon was picked) and created user stories for our product backlog. We then began working on weighing and prioritizing each story before tasking them out. The highest priority tasks were unrelated to these new user stories; we still had a number of previously-written tests that need to be fixed.

After our time box ran out for planning, most of the group starting fixing tests while Jon and I continued creating tasks and putting them up on the Scrum board. On that topic, I have to say that the Scrum board is looking much better now. I think we have a much better idea of how to use it; now we just need to sort through the stories we were working with in our first mini-sprint. After a few minutes Jon pointed out that it would be better to work on fixing tests than creating tasks (because we wanted all tests passing by the end of the day), so we started working on that. After reaching a stopping point with tests I worked on tasks a bit more. Somewhere in the day (I can’t remember when exactly) I redrew some of the model in order to reorganize it a bit and make better use of the space on the board. The day ended with most of the group attending the Q1(-ish) Town Hall meeting for Improving. We didn’t need to be there, but it helped us gain a better understanding of how things work at Improving. 

Today was good. Also, I managed to write my blog post on the right day. (With 5 minutes to spare!)

Our Day of Autonomy (and My Thoughts on the Status Quo)

I’m still running a day late on these, but Friday was somewhat uneventful and I think I was a bit worn out from the week.

Friday, May 16

Jef wasn’t around, so the group was left to drive itself. My memory isn’t great (I really need to start doing these at the end of each day) and I don’t think we did much that merits lengthy description or comment, but I’ll write as much as I can. Most of the day was spent simply working on the project or fixing whatever merge conflicts (or other problems) that came up, but we did start the day by taking another look at our project model. I don’t remember exactly what we changed, but I feel that in general we have a pretty good handle on modeling and I think that part of the project is going well. There are other things about the project that still seem a bit messy to me. Right now we’re handling things in pretty small chunks and that makes it easier for us to step on each other’s feet. It’s like having 6 people rearrange furniture in a small apartment all at once. But that’s fine; that’s just the way it is for now and it’s going to get better. Later, once the project expands, it’ll be more like a large house and we’ll each get a room to work on separately. I also think our Scrum board isn’t quite right but that too will get better. I still think we’re working pretty well as a team and making great progress on the project.

So I’d say that my first two weeks at Improving went well, and I’m looking forward to starting the third one.

Our… Less Structured Day Working on EIP

I’m getting closer to getting these posts done each night, but I’m not quite there yet.

Thursday, May 15

Wednesday was a bit of a mess, but I think we learned a lot from it. Also, I’ve been led to believe that we were meant to crash and burn so that we would learn from it, so really everything went according to plan. We started Thursday with Jef teaching us a bit about generating tasks from requirements. We learned about creating user stories (from our list of users and their requirements) which can usually be expressed briefly as “To <Why>, A <Who> <What>.” Underneath each one of those, you have scenarios that need to be tested/demonstrated. These can be expressed using Gherkin Syntax, which essentially boils down to:

Given <Condition>
  And <Condition>
  ...
 When <Event>
 Then <Condition>
  And <Condition>
  ...

We were also told that each “Then” should be 1 of 5 things:

• Object created or destroyed
• Attribute set
• Relationships formed or broken
• Messages/Exception to external systems or user
• Objects returned to user

For example:

To prevent unauthorized account access, a user logs in to the system.
     Test/Demo:
      - Valid username/password
      - Unknown username
      - Valid username/ invalid password

So the first one could be expressed in Gherkin Syntax like this:

Given valid username
  And valid password
 When logging in
 Then display welcome message
      navigate to dashboard

Each “Then” can then be made into an individual test (with its own Assert) and grouped into a test class.

After we learned all of that, we made some more stories for Logging in and wrote tests for them before going to lunch. After lunch, we created a model for the project. That went pretty well, but I do think the model needs to be changed a bit. I added what I thought should change to the model (with a different color marker), and I’ll probably bring it up for discussion today. The rest of the day was mostly spent stubbing and filling out the classes, methods, and properties used in the tests in order to make them pass. I also had a one-on-one meeting with Jef, which went well.

It was a good day. A productive one, too.