Our First (Mini-)Sprint for EIP

I Lied! I went to bed after my Tuesday post so I’m writing my Wednesday post now.

Wednesday, May 14

EIP stands for Employee Involvement Program and it’s the main project for the software development boot camp I’m in. The basic Idea is to create a web site where Improving Enterprises employees can log time spent on projects and have it sent to quick books automatically. The site will also be used to allow management to track who has and hasn’t logged time and how often they’re doing it. We started our first (mini-)sprint by generating a product backlog made up of whatever user stories we could think of. We then planned our sprint, which I don’t think went very well. We ended up cranking out a bunch of different tasks somewhat independently because we had a pretty small time box. This isn’t bad on its own; the problem was that we didn’t take time to make sure that we all knew what each task was. We weren’t staying on the same page (this has been a problem for us before).

The first “day” was about an hour. We split up into three pairs, and each took a task and got to work. Well, we tried to anyway. We quickly learned that there was some setup we needed to do before any of us started working independently. After that, we realized that because all of the tasks were related to time entry we needed to get that set up before we worked on anything else. So we split time entry up into three parts and my partner and I got to work. This part was easy enough; we just created a few tests to make sure our properties weren’t null and stubbed out and wrote the code from there.

The second “day” (also about an hour) got a little rough for me. After we finished our first task I started to look at the others on the board. Several of them had something to do with time and clocks, but because I wasn’t a part of the conversation that generated those tasks I didn’t know what to do with them exactly. Unfortunately the others were in the middle of their tasks so I couldn’t really ask them about the time tasks. My partner and I got to work anyway managed to generate some tested and working code (I was still a little frustrated because of not knowing the end goal of our task).

DAY 3: WALL OF GIT. At some point early in day 3 I attempted to push our build to the teams Github repository. Pushing involves rebasing, and that can cause a merge conflict. It turns out that none of us were set up to deal with a merge conflict. We started trying to configure git to use Visual Studio’s merge tool, but it took the entire “day.” Jef and I managed to get mine working just in time for the sprint review and retrospective. The consensus of the retrospective seemed to be that we need to work on how we generate tasks (and do some modeling to help with that). After Jef left the team played around with Git a bit in order to better understand pushing, pulling, commits, and merge conflicts (We also wanted to make sure it worked for all of us).

Hopefully (Mini-)Sprint 2: Electric Boogaloo will go a little better.

Our Second Day in an ASI Course at Improving

Welp, this one’s a full day late, but I’ll be writing the post for today right after this one so I’ll be back on schedule.

Tuesday, May 13

We started the second day of the exercise course talking about planning and estimating. Planning and estimation is the stage in Scrum where you estimate the required resources for a project (time, money, and talent) and how much you can do in one iteration. We leaned about using estimation units, which are used to estimate the size of just about anything (features, task, etc.) in terms of whatever measurement may be relevant (e.g. difficulty, time needed). To help learn this process the groups went through an exercise where each group estimated the size of various dogs using Planning Poker. Finally we learned about prioritization and various progress-tracking artifacts. Prioritization can be achieved through a value/risk matrix. Progress tracking usually involves a Scrum board (which tracks task completion), a Burn-down chart (which tracks sprint completion), and a Burn-up chart (which tracks project completion). One other tracked measurement is velocity, which is how much effort has been handled in each sprint.

The final chapters of the course were Requirements, QA, and Development. Generally, requirements can be put into one of three categories (Functional, Non-functional, and Business Rules), and are made up of Use Cases, which are broken down into Scenarios, which are then broken into tasks. We were given a new project for the next exercise, which was to come up with 10 functional and 3 non-functional requirements. In Agile, QA and development are all about TDD. Acceptance is defined, tests are written, and then code is written. The QA person helps add and define user stories and acceptance criteria while also helping build tests and building some tests themselves. For the second part of the exercise we spent a short time creating acceptance criteria for 3 of our requirements. Developers focus on priority, building things right, using TDD and continuous integration, and finishing each sprint with a shippable product. Other than some miscellany the development chapter was the final one of the course. I learned a great deal about Scrum in these two days, and I hope I can retain at least most of it to use in the upcoming sprints we’ll be doing in the boot camp.

I spent way too long on this post as well; I think it keeps happening because I’m still not sure exactly what to post about other than just summarizing my day (and there’s so much to summarize).

 

Our First Day in an ASI course at Improving

(Oops, I started drafting this last night at the office but forgot to finish and publish it when I got home)

Monday, May 12

ASI stands for Agile Scrum Immersion, and the course is basically an introduction to the Agile software development methods and more specifically the Scrum method. In this first day we first touched on the 4 core values and 12 principles of Agile. Agile at its core values people, communication, and adaptability over strict plans and processes. We also touched on basic definitions of some of the popular implementations of Agile such as eXtreme Programming, Kanban, and (the focus of the course) Scrum.

The room was naturally split into groups because everyone was sitting at one of three (collections of) tables. Each group went through a couple of exercises together. The first was to plan a trip from Dallas, Texas to Anchorage, Alaska (no flying, just driving), but in the middle of the exercise the destination changed to New York. The exercise was meant to demonstrate that while some planning is necessary, too much planning can be wasteful because things can change and you have to be able to adapt.

Finally we focused in on Scrum, defining it as an empirical and iterative process comprised of organized sprints that each result in a working piece of software. We also went over each specific role in Scrum, along with the artifacts and events involved. Throughout this section we would proceed through parts of the second exercise, which was to create a vacation resort brochure using Scrum. This exercise ended up being a great hands-on demonstration of what it’s like to go through an entire sprint in Scrum. The day ended not long after we finished the exercise,  and I look forward to starting the second half of my Scrum training.

I spent way too long on this blog post.

My First Week of Software Development Training

This last week I started at a software development boot camp at Improving Enterprises. I was supposed to start a blog Monday and update daily but I didn’t really know how to do that so I put it off until now. Because of that, in this one post I will try to cover (what I remember of) the whole week. Next week I will make an effort to build a habit of documenting my day as it goes on and make a blog post each night.

Monday, May 5

Monday was mostly orientation, meeting a few people (including my fellow boot campers), and getting set up. We were given a general introduction to Improving Enterprises and told what was expected of us. Each of us in the boot camp received a MacBook Air with Windows 8 installed to work with during the boot camp (that’s what I’m writing on right now) I spent some time during the day installing the software I needed/wanted including Google Chrome, Start8 (which is a program that gives Windows 8 a start menu similar to the one in Windows 7), Git, NUnit, and the Microsoft Office Suite. Along with the laptop we received a t-shirt and hat, a flash drive, a pen, and a notebook, all with the Improving Enterprises colors and logo. The notebook and pen will certainly come in handy for taking notes each day, and I plan to use them for just that. The day ended with the 7 of us (Me, my fellow boot campers, and Jef Newsom, out instructor) going to dinner with our CEO, Curtis Hite. All in all I’d say that Monday was good. I was excited to get started and it was nice meeting the people that will hopefully be my new coworkers in 8 weeks.

Tuesday, May 6 and Wednesday, May 7

I don’t remember much about the specifics of Tuesday and Wednesday, so I’m combining those two into one section. On Tuesday we dove into our C# training. At the beginning of each day we work on what are called kihon katas, which are fundamental C# exercises meant to build muscle memory for writing commonly used code like a % b;, searching through a string, or using basic control structures. We get through as many of the exercises as we can, gradually decreasing the amount of time it takes to write the code for each exercise. These katas come from a project called Squire, which we acquired through Git. I had not used Git before so I’m still getting used to it, but I’ve at least gotten the hang of opening up Git Shell each morning and resetting the katas so I can go through them again.

I learned a lot about C# these two days, but I think the most important part was beginning to learn about Test Driven Development (TDD) and how incredibly easy, useful, and just… great it is when using it in Visual Studio. As I understand it you start by creating the test for what you want to build before you do anything else. From there you can stub out any classes, properties, or methods that you need to create the test, which is super handy and awesome. I’ve learned that Test Classes are often either built for each event that occurs in the program or each class (or you could just do I mix of the two). I was taught to name each unit test according to the event or class being tested, and each test class should be named according to different specific things that should occur for either the event or class (and there should only be one assert for each test). I haven’t yet mastered this process, but by the end of the boot camp I should at least be competent at building a project entirely through TDD.

For this first week of the boot camp, we’ve been working on creating a piece of software from scratch using TDD. I’m not sure I remember its exact origin (I believe a guy a Improving created it), but it’s called The Consulting Game. It’s intended to simulate running a consulting business (similar to how Monopoly simulates property trading). We played a paper/spreadsheet version of it early in the week, and after playing it and becoming familiar with it we decided to try to create a software version of it. We had the choice of either trying to build that or start working on the program we’ll be creating for most of the boot camp (I’ll describe that in a later blog post).

Thursday, May 8

I actually have some notes for this day so I’ll be able to write more specifically about what I did. I started the work day as usual with my katas and got up to the third one, which was the Control Structure Kihon. In the lecture portion of the day we learned about coupling and the Law of Demeter. The Law of Demeter (or LoD) can be summarized as saying “You can talk to yourself, you can talk to your neighbor, but you can’t talk to your neighbor’s neighbor.” The “talking” in this summary is referring to coupling, which is basically when one object depends on another in order to function.

When we started coding we started to work more on tests for the Company class, but when we got too deep into that we started the tests for the Consultant class. Once we worked out some Consultant tests we went back to company and added Payroll and Net Profit tests in order to create methods and get those working. After Jef left that day the group was left to work on figuring out what happens with the Company class at the end of the month. A few of the other members of the group were not ready to move on, so I made the mistake of working on the EndOfMonth method on my own. This meant that the group as a whole was no longer on the same page, and after realizing my mistake I made a note to try to stick with everyone else in the future.

Friday, May 9

Friday we learned about Inheritance, superclasses, and the Is-a, 100%, and Liskov Substitutability Rule regarding those two concepts. These three rules basically this about superclasses: it needs to make conceptual sense that a subclass is a member of a superclass, everything about a superclass needs to apply to a subclass, and you should be able to have every subclass swap out with any other subclass of the same superclass and have your code still function. I was excited to hear about this because it seemed very useful. In the Consulting Game project we made the Consultant class into a superclass and created the Employee and Contractor subclasses. We added tests for the Consultant RollOff method with the idea that it would be different for Contractors, allowing us to practice creating and using a virtual method. I ended up making RollOff the same for both subclasses, but I’m not sure that everyone else did the same. We also added Gig tests including one for closing the month, so I was able to share a little of what I had learned making my CloseMonth method previously.

.