#33 of 40 Release 0.1.3 Planning

We are already on our 4th iteration of the project. I’ll be having a semi-long break after this iteration for a trip overseas, so I don’t want to end the release in the middle of some major feature.

Here are the customer user stories for this release:

• Allow student users to view the classes they are enrolled in (show class name), as well as which study group they belong to (show study group name). The class name and study group name should link to the view class and view study group pages respectively, with the appropriate parameters selected. Also, this should be the first page they come to after logging in.
• Allow student users to see the profiles of other students in their class and/or in their study group, by clicking on their name in the class enrollment list, or their study group page.
• Add support for viewing an instructional unit for a class. The view class page should list all the instructional units for the class, with relevant data.

Ok… whew. That’s a lot of story, so let’s see how the estimates come up from the development perspective.

• Allow student users to view their classes enrolled in and the study group they are in. These names link to view class and view study group pages. Make this the page to redirect to after login. (1 hour)
• Allow student users to see the profiles of other students in their class and/or in their study group, by clicking on their name in the class enrollment list, or their study group page. (1 hour)
• Design an instructional unit table and update the database. Add test data. (1 hour)
• Show the instructional units for a class in the view class page, with associated fields. (1.5 hours)
• Make an administrative area for admins and teachers, where they can create and edit instructional units. (1.5 hours)
• In the list of classes in the view my classes page, show the current or latest instructional unit for each class, along with their mastery goals. (1 hour)

As you may have seen, we just don’t have the bandwidth to tackle the last customer story, which may be just as well, considering it opens a whole new can of worms. The stories already committed for this release are fairly significant in themselves, and the estimates assume that the pace will start to quicken more.

 

#32 of 40 Release 0.1.2 Retrospective

Although some early stories were much more difficult to implement, the release ended with some real, tangible progress in using ASP and in moving the application forward. With the implementation of a few more pages, I expect that most of the groundwork for the user accounts will be laid down, and we’ll get into the meat of the mastery learning application.

I’ve written at length in this week’s posts on some of my complaints about ASP, but at the same time, I don’t want to give the impression that ASP is a flawed approach. I think it, like many Microsoft products, has to be many things to many people, simply since MS is so dominant in the marketplace… and I can certainly understand how trying to market for the widest audience possible would make certain design decisions difficult.

That being said, I think I need to start revisiting the books I was reading at the beginning of the project to review some of the examples and tutorials. As I’ve encountered roadblocks, I’ve typically found answers in a variety of places and done all sorts of my own experimentation. I’ve noticed that at least with my own foray into Agile programming, there’s been an unconscious pressure to keep adding functionality, without taking enough time to evaluate what other alternative approaches exist. Maybe this is just my own fault for not building this in to the process, but I find it hard to see how a developer could go to a customer and ask for time to explore and evaluate design alternatives that may not even exist. I guess what I’m saying is that the Agile process seems to fall a little short for me in terms of promoting the kind of learning and analysis that would pay big dividends later on. But in pretty much every other respect, I thoroughly like the fact that an Agile approach has kept me focused on getting things done.

I think I can improve on my estimates, but it’s the estimates on tasks I’ve never done before, which are still going to feel like shots in the dark. I made several design errors that put me back a few days in the last few weeks, but that’s pretty much to be expected given my inexperience. And it’s to be expected in the future for at least some time as well.

I have time for 1 more iteration before I am going overseas for vacation, so I hope to build something worthwhile on this past release, and cement some of the ASP concepts I’ve been running through so that when I get back, I haven’t totally forgotten how to do things.

 

#22 Release 0.1.1 Retrospective

Well, this was an interesting release. Or… considering that we’ve only had two releases, maybe all it is is that it’s just more interesting than the previous one.

Anyhow, some observations about this release and my continuing experiences with ASP:

• I’ve definitely started to become more comfortable with the things I learned and picked up in release 0.1.0. So many of the tasks that were similar to last release were noticeably quicker to implement. I also feel that I’m starting to get a better sense of how the ASP controls relate to each other, although I want to stress that I’m still at the very beginning of a very long journey.
• I’m starting to feel more comfortable with typing out the ASP.NET controls by hand in the Source view instead of dragging and dropping them with the Design view. This is certainly different than my preferences with drag-and-drop when developing Windows Forms applications. I think it has to do with the fact that with Windows Forms, there are tons and tons of possible settings for each control, and it’s must easier to have the Designer manage that. So far, the controls I’ve been working with in ASP are astoundingly simple when I look at them in the source code. I think this also relates to the fact that since web UI is mostly controlled through CSS instead of in the ASP.NET control, it reduces the amount of properties assigned to each control.
• The above observation is somewhat related to my lament on how ASP abstracts things in such a way as to obscure what is really going on. Using the drag and drop is quick and seems “magical”… but someone who is a little anal retentive and who has insisted on hand-coding HTML for the past decade or so, I don’t like the fact that I tell Visual Studio to do something, letting some “magic” happen, and then seeing the raw HTML and form controls on the other side, in a form I really don’t want. What’s even more unwieldy is the “abstraction above the abstraction” that ASP provides… things like Login controls which is a composite of many different controls and behavior. In some instances, when there are very few different ways someone would want to implement it, it can be a handy time-saver. But when there are several ways that people want to use it, you either hit your head on the wall trying to fight against a bunch of rigid constraints and eventually giving up and writing your own control; or you get swamped with a myriad of options and properties that must be set on the control, of which only a handful are relevant to you.
• OK enough about ASP. What about the development process under (quasi-)Agile/XP? I think it’s helped hone my focus, and pushed me to keep moving forward. Although I’ve had some problems this past week, they were good learning lessons, and I don’t think the mistakes/oversights I’ve made are going to be too difficult to get out of. Could some of these errors be avoided with BDUF (Big Design Up Front)? I’m not entirely convinced that this is the case, because the errors were mostly attributed to lack of experience in DB-driven development. If anything, one improvement I can make is as the customer — thinking out the requirements a little more thoroughly. But I’m a fickle customer who doesn’t know what he wants, and won’t until he sees it. The kind that developers really love.
• One more note about ASP (sorry). I’m not writing any unit tests, which bothers me. Mainly because I’m not even sure how I’m supposed to under this kind of environment. Clearly there is a test-driven way to develop in ASP, but Microsoft and the books I’ve read sure don’t push it. I know there are a bunch of online resources out there dealing with the so-called “ALT.net” way of .NET development. I’ve done a fair share of this with my Windows Forms C# development, but the model is different under ASP, and it’s something I want to learn. Maybe I can push the customer to include this in the next release, or the one after.

 

#15 of 40 Release 0.1.1 Planning

I spend some time brainstorming and planning for release 0.1.1. Here are my initial user stories from the role of the customer:

1. Create a user’s “My Account” page, which allows the user to view and edit email address, first name, last name, password (twice), and an “About Me” textarea. (pushed from last release)
2. View a class and its associated students and study groups. The class name, a list of enrolled students, and a list of study groups should appear.
3. View a study group and its associated students. The study group name and a list of the students who are part of it should appear.
4. Support Teacher accounts.
5. As an Admin, or as a Teacher, support creating a study group. Allow students to be assigned to study groups. The students cannot be assigned to more than one study group.

As a developer, I’m going to push back a little on having an editable email address. Yes, it’s true that there is a way (by cloning the user information and creating a new user, then deleting the old one) to make this editable, even though it’s also used as the username in the DB. But it’s probably not worth the effort considering the scope of this project, and the fact that students would probably in fact be using the email address given by their school, and this is unlikely to change. The customer relents and agrees.

I broke these down into the following chunks:

1. Create a My Account page which allows the user to view email address, first name, last name, alias, and an “About Me” textarea. (1 hour)
2. Allow the user edit first name, last name, alias, and About Me. Also allow them to reset their password. (1.5 hours)
3. Setup a simple master page with navigation bar, sidebar, and footer. (1 hour) I added this since it’s better to do this earlier on than conforming to it after a lot of pages have been written.
4. In the master page, add standard navigation options that show up for the appropriate user type. (1 hour)
   
5. Create a page to view a specified study group and the students that belong to that student group. (1 hour)
6. Create a page to view a specified class and the associated students and study groups that belong to that class. (1.5 hours)
7. Allow teachers and admins to assign users to a study group. (1.5 hours)

So in total, we have 8.5 hours of estimated work, which is conservative for a 2 week cycle. We’ll jump into the first story next time…

 

#14 of 40 Release 0.1.0 Retrospective

Well, I’m at the end of 2 weeks, and release 0.1.0 is done.

I’d say that this release went fairly well, although there were some challenges towards the end. The good news is that all the user stories committed were implemented. We didn’t implement the last story (My Profile), but this was not committed in the release plan.

Positives:

• The division of tasks into user stories seemed really to help keep the project moving forward and on track.
• Even though there was a hiccup at the end, we were able to recover somewhat gracefully.
• We have something working!

Things to Improve:

• Many of the starting features were relatively straightforward and built into ASP, so there was a wealth of tutorials in print and on the web on how to set them up. As soon as I wanted to deviate, though, things took much longer. I need to give longer estimates for features such as these.
• The user stories could be a little more specific, as some details on some features were ambiguous. I’m lucky since I’m the customer and the developer, but in a real-world setting, as the developer I would need to ask the customer for more detailed requirements.

It’d be nice if I could upload what I have so far to a web host so that my latest build is there for people to see, but my current web host isn’t a Windows server, so I’ll have to see about finding some budget or hopefully free ASP.NET hosting.

Next up: Release 0.1.1 planning.

 

#4 of 40 Release Planning v0.1.0

The exploration phase of the Planning Game involves the customer writing “stories” for the requirements of the proposed software release.

So what is the proposed software release? I’d like to try out a 2 week release iteration cycle, as that seems to be a common timeframe for other projects I’ve read about. Since this is not a fulltime job though (and far from it), the cycles are not going to be very feature heavy.

User Stories

Playing the role of the customer, I’d like software release 0.1.0 to essentially support student user accounts, and simple display of the student user’s classes. Here are my user stories (I’m technically supposed to write this on index cards, but those are a little hard to show onscreen without some effort):

1. Allow the user to login using their email address and a password. Logging in takes them their student main page. Failure of login credentials shows an error.
2. Create an admin page which allows me to create users by supplying first name, last name and email address. Also allow me to add them to up to 5 classes.
3. Create a user’s “My Account” page, which allows the user to view and edit email address, first name, last name, password (twice), and an “About Me” textarea.
4. Create an admin page which allows me to create and edit classes.

Ok, time to switch roles. As the developer, I need to look at the user stories, and split them if necessary so that they can be expressed as estimate-able chunks.

I came up with this:

1. Setup project and commit to SVN. (1 hour)
2. Create initial DB diagrams. (1 hour)
   
3. Create SQL tables and input test data. (1 hour)
4. Support student login via a home page, using email address and password. Failure of login credentials shows an error. (1.5 hours)
5. Create an admin page to create classes (for now, just a class name and ID). The class name should be editable. (1 hour)
6. Create an admin page to create test users by supplying first name, last name, email address. (1 hour)
7. On the admin test user creation page, allow users to be assigned up to 5 classes. (1 hour)
8. Create a My Account page which allows the user to view and edit email address, first name, last name, password (twice), and an “About Me” textarea. (1.5 hours, not committed)

So basically, pretty much the same requirements, but added some technical setup details. Also, I’m going to give myself about 8 hours per release, so I can’t commit to having user story #8 in this current release. Instead, it’ll be a “nice to have” if things are going extra smoothly.

There’s a commitment phase which involves scheduling these items according to risk and business value, and then setting development velocity and scope. This is more of the formal process I should have gone under to decide on deferring story #8, but since this is my first go at XP, I’m going to skip this step for this iteration and just use my gut. The items I listed pretty much have to be implemented in the order I presented them anyway, so I’ll just do them linearly.

I’ve tried to give myself a little cushion on the estimates, but since I haven’t done much ASP.NET, I may need the full time. Hopefully my velocity will become a little more respectable further along in the project.

 

The Planning Game (#3 of 40)

In eXtreme Programming, the gathering, formulation, and assignment of software requirements is accomplished through the “planning game.”

What is the planning game? As someone who is fairly new to XP, I’m not ready to give a play-by-play breakdown of what it entails. (Maybe something I can describe more eloquently and accurately after trying it and refining how I do it). The big picture, however, is that there is a responsibility on the customer’s part, and a responsibility on the software developer’s or developers’ part.

The customer (that is, the intended user of the system who is working with the software team) must first write user stories to describe how he or she conceives of what the software needs to or should do. For the purposes of this project, although less than ideal, the customer is none other than me! Incidentally, the software team also happens to be… me.

Anyway, back to user stories. I’m sure there is a story (sorry bad pun) behind why these came to be called user stories. To me, the term makes them sound really long-winded, rambling, and touchy-feely. What user stories really are, though, are succinct (usually 1 or 2 sentences) and specific requirements in the language of the user on how the software should work.

For example:

User forgot password
- When the user forgets their password, they navigate to the forgot password page. After supplying their email address, their password is emailed to them.

The customer writes all the user stories they can think of on index cards. Any user story which is too ambiguous, too vague, too complex, etc. must be rewritten. User stories are not written in stone — in fact, part of the whole point in XP methodology is to accommodate frequent and rapid change. However, when user stories are written, they should be specific and exact, even if they turn out later on to be specifically and exactly wrong. Nothing is worse than building something that the customer never wanted in the first place because the requirements were misunderstood.

One other important requirement for user stories is that the software team feels they can make an estimate on the story. If the team can’t give an estimate, it’s usually a sign that the story needs to be split into several stories.

Once the user stories are satisfactory to both the customer and the software team, we move to the commitment phase. (Sorry, I neglected to mention the first phase is the exploration phase).

In the commitment phase, the customer  assesses the business value of each of the user story cards. One approach is to divide user stories into 3 categories — critical, valuable but not critical, and nice to have. In parallel, the software team assesses the risk level of each user story. Risk is defined by the degree of complexity, uncertainty, and volatility of that business requirement. The degree of risk and the business value help determine the order in which requirements are fulfilled.

The final phase is called the steering phase, which allows changes and adjustments to be made.

The process I’ve just described is probably a weak description of the planning game; and in fact, I’m already pretty sure of this as there are actually two different parts to the planning game, each with an exploration, commitment and steering phase. What I’ve described above is known as release planning. The other part is iteration planning, but I think we’re fine with just starting with release planning since this is the first step.

So… in our next episode… I’ll pay the role of customer and come up with my user stories for my first planned release.

 

The World of Agile (#2 of 40)

I want to expand a little on the explanation of Agile methodology that I started in the previous post.

First, Agile could be classified as an iterative approach; where some form of running software is produced at the end of each iteration, and is gradually improved in each iterative cycle. But iterative development, at least as its commonly understood in software development, usually plans iterations on the order of months, whereas iterations in Agile methodology are in weeks. In fact, I think the more “purist” Agile calls for an iteration in one single week. I’ve heard of many teams, however, that do 2 week iterations, feeling that the 1 week iteration was a little too much “pedal to the metal.”

Taking a step back, having short, tight iterations makes practical sense when there are many unknowns in a project. A big part of the rationale behind the origin of Agile methodology was the reality that in many environments, business directions change frequently and drastically. As someone working in a startup environment, I can attest to this. I often inwardly laugh to myself when asked for a software plan for the next year at work, because I know that even the items we’ve charted out for the current quarter will change a lot by the time the quarter is over.

Another big benefit of Agile methodology is getting feedback very quickly from the customer. Since the focus is on frequent iterations from the very start, and on working software, no matter how trivial, the customer will get to see something early on, and have the chance to divert the direction of the project if there is a misunderstanding of the requirements, or if plans have changed.

In Agile methodology, the customer is basically the stakeholder most readily accessible who is committed to giving frequent feedback and is part of the requirements planning and verification of working software. For that reason, the “customer” may be an actual customer in a business setting, but more often than not the customer is actually a project manager, someone else internally, or even the programmer. In my case and under my time constraints, the best person to play the role of the customer is none other than me!

There are actually many flavors of Agile methodology. Probably the two of the best known flavors are XP (eXtreme Programming) and Scrum. I’m much more familiar with XP than Scrum, so I’ll use XP as a starting point, and if I have time, evaluate and/or try out Scrum somewhere along in the process.

Next post: More on XP…

 

40 posts in 60 days… (#1 of 40)

So, here are the facts…

It’s been a month since I’ve updated this blog. Although I have been doing a few things with the project (including finishing up on the ASP book and working out a few draft database schemas), for all intents and purposes, work pretty much screeched to a halt. The short story is that an extra busy work schedule put me behind, and I was inclined to only blog when I actually had accomplished a big chunk and more or less caught up to the schedule. Ironically, this desire actually contributed to falling even more behind.

So, it’s time for a fresh start, along with the realization that sometimes in solo projects, you need to manage yourself. And in fact, this might be a great opportunity to try something I’ve wanted to do for awhile, which is called “Agile programming.” Agile methodology is a different way to do software than the traditional project management oriented approach. In the traditional approach, there usually is an end goal with significant milestones. Typically, requirements and specifications are designed in detail upfront, and the final product is not usually available until the end part of the project.

Agile, on the other hand, calls for less specification upfront, an emphasis on getting something working and runnable, no matter how trivial, right away; and then incrementally improving the product with frequent, tight interaction with the customer. Agile is designed to deal effectively with change to product requirements, and also to keep a project moving forward and on track.

Some programmers and project managers swear by Agile. Others feel it is a faddish waste of time. But I think Agile has established itself enough in the consciousness of the software development industry that it’s an accepted practice, although some may disagree with it, and I’d love the opportunity to try it after reading a bit here and there on it. Doing it on a school project also might be a good opportunity as well, since I won’t get fired if I miserably fail. (Although I might further delay the prospect of graduation… but that’s another story).

Anyhow, I will write more on Agile as the process continues. This is the first time trying this as well, so there will be some adjustment and learning period at first.

Ok, so in keeping with my new “Agile” framework, and also because I want to graduate someday, I’m making a goal of writing 40 posts in the next 60 days. Why 60 days? On July 12, I’ll be heading off to China for 3 weeks, where I’ve been doing a yearly trip teaching English as a volunteer  at a secondary school. (I’m not Chinese, by the way.) I’ll have roughly 60 days before I go, so I’d like to make some real progress on the project before then.

My intent is that each post would correspond to one or more small steps on this project, so about 3 or 4 a week for about 8 1/2 weeks. This may not amount to much for each post, but if I follow through, I’ll at least be somewhere better off than where I am currently.

By the end of this week, I’d like to have posted at least 2 more times, and by the end of the week, I want to start Agile and get refocused on where I am in the project. I also want something running, no matter how trivial or non-functional.

Now that I’ve called myself out on this, it’s time to either execute successfully or fall flat on my face. Here we go…