Back To Work!

This past week we had spring break and not much happened, except for everyone here getting sick... I was able to do some good reading in a book about hacking web applications. It is a pretty long and intense book, but so far it is a pretty interesting read, it is well written (didn't put me to sleep), and I have learned a lot so far! I also did some learning of the python programming languages and how to create classes as well as using Tkinter.

One of the things that is pretty annoying is that Tkinter doesn't have, in Java terms, a combobox built in. I had to download Pmw or try to write one from scratch. I guess I took all of the work that developers have created and added to the Java API for granted. Tkinter looks pretty rough around the edges but it is always good to have the experience of learning a new language and having new concepts under one's belt.

Today In class prof Kniss went through a few of the team's wikis/websites and basically had a lot of things to tell us about how we needed to be better. One of the things that I asked him was about how requirements are handled in the Scrum method. In a lot of the documents that I read about Scrum it seemed that requirements are looked at very differently in comparison to other software development processes. Instead of starting the project with a detailed analysis of the desired functionality and creating requirements from that, the Scrum method starts a sprint by talking with the Product Owner/ client and derives a product backlog from what is said. A sprint backlog is then created and work is done to try and accomplish the different tasks.

After a lot of searching online for getting requirements that would fit with what CS 460 asks of us I finally found a good website. The main points that I got from this website as well as some of the things that we discussed in class are the following:

• User stories are to be written out describing what we want the product to do. An example of one kind of format for user stories from the website: "As a I want to so that I can ."
• The user stories are then parsed to figure out what tasks need to be completed to achieve these higher level requirements, these then create the product backlog
• The user stories need to have a section describing on how these are validated, through tests and what not.

Scrum is interesting in that in each sprint there may be many tasks that aren't accomplished and that may not end up in the next sprint or in the final product. This was difficult for me at the start thinking the following:

"How can I give all the sprint tasks a unique identifier and create a requirement from them if I am not sure it's going to actually make it in? Are we just going to have a whole bunch of requirements that weren't completed? That doesn't look to nice on our record!"

My conclusion is as follows, as we create the backlog and add to it, each of the items will have a column showing the necessity of the item. Namely we will have a decent idea of requirements that we must be accomplished as well as requirements that have a necessity of "if we have time it would be nice" or just labeled as "features". That way by the end of the project yes we will have requirements that aren't met, but that will be ok because we didn't intend on implementing that feature, it was intended as an extra.

Something else that I want to do is make sure that everything is tied together:

• Each User story has a list of the requirements that were derived from it
• Each Requirement has a test tied to validate it
• Each section of code which is implementing a requirement and each test which is testing a requirement contains the unique identifier in a comment either at the top of the file or in a comment right above it. This way we can create a script that will go through all our code and output which requirements are accomplished and which ones are not.

It's a lot of stuff to think about! The development process is something that is pretty tricky when you actually sit down and think about it. The problem that I think we are running into is that we are all trying to figure out how to make the program function and there is a lot of overhead in dealing with requirement creation, setting up meetings, doing documentation, and ensuring that validation of our requirements are being carried out. It seems like we will need one person who is in charge of all the overhead stuff and not so much involved in the coding. We shall see if that happens or not. It seems like I am the one that came to this conclusion, I should probably be the one to carry it out... We shall see...

Self Evaluation

In our Software Development class we were asked to give a self evaluation to fight for the grade that we think we deserve, showing both what we have done, as well as what we plan to do. Here is my self evaluation.

Startup Business Findings

I had a goal of looking up statistics about startup companies and getting a grasp of what were the major components of the startups that succeeded versus those that failed. I was pretty disappointed at the resources that the web had to offer in this area. I found sources that said 90% of all startups fail, and another that described that 2/3 of startups make it through 2 years and 44% make it past 4 years. The only knowledge that I came out with after researching this, was that there really isn't any easy answer to the question, what is the success or failure rate of startup companies. No one seemed to agree with each other and for the most part those that gave actual numbers were just random people who don't seem to be very credible.

So the question is why do we have so little information about this topic? Is it because there are just too many startup companies to keep track of their dealings? Is it because there is too much gray area, if a company gets bought out is it considered successful? The major consensus was that it is hard to have a successful startup company. Many opinionated voices share their opinions on why many flop, or what characteristics are needed for a successful startup.

Many flop because the market is just really fickle, or because there is no room for the little guys in the realm of giant companies. Many flop because they underestimated the amount of work needed to complete a project. Many flop because they don't have sufficient funds to get started. Many flop because they are just terrible ideas!

In order to have success you need:

- a lenient market

- a solid business plan

- Consultations from those who have already been successful

- A good idea

- Clever Marketing

- A healthy economy of the target audience

- and sometimes Luck!

Agile vs Scrum

In class we talked about a couple of different processes. My group is using a Scrum process. We have adapted it a little bit to fit our needs, but I believe that we have the main principles.

SCRUM

Scrum get's it's name from rugby, "the whole process is performed by one cross-functional team across multiple overlapping phases, where the scrum (or whole team) "tries to go the distance as a unit, passing the ball back and forth"."(Taken from wikipedia, but originally from "The New New Product Development Game" ) The scrum methodology is actually an agile based method. Some of the key factors:

Scrum Team:

Product Owner: The voice of the customer. Selects which items should be accomplished during the next sprint, places priorities on the different tasks.

ScrumMaster: Enforces the rules of the Scrum. That the sprints take place, keeps the team focused and takes care of anything that may be impeding the teams focus or work (ie. resolves conflicts, removes distractions, enforces time limits on meetings).

Team: Developers who will be carrying out the sprints and creating the software.

Ideally a scrum team would meet everyday for 15 minutes in what is called a daily scrum. Each member is asked the following three questions: What did you do yesterday? What are you planning on doing today? Are there any problems that are preventing you from completing your tasks?

This is a great way to keep the members of the group accountable, as well as keeping them focused.

At the beginning of the sprint there is a meeting where have of the meeting is the Product Owner talking to the group about which tasks are priorities and what they would like to see done or what the customer would like to see done. The second half the team will meet and assign points to each of the tasks and describe how the tasks are going to be broken up and implemented. The team then picks out what tasks they believe they have time to accomplish and sets the others in the sprint backlog. The sprint backlog will have tasks that the team works on after they have completed the other tasks.

A product backlog will be created that has a pool of all the tasks that the product owner desires to have completed by the end of the project. The sprint tasks are taken from that pool. Any tasks that were not completed in the sprint get put back into the product backlog and tasks are selected for the next sprint.

Pros:

Anyone involved with the product gets an update everyday so there are no "Surprise we are three weeks behind schedule!" moments, corrections are able to be made at the start of "slacking".

After each sprint the product can take a completely different route if desired, which gives it an enormous amount of flexibility. Also allows the team to not have to know and plan for every detail in the beginning

Developers are forced to, as our professor says, "eat the elephant one bite at a time" because of the smaller tasks that are meant to be completed in a couple of weeks or so.

Cons:

It is kind of stressful for developers to have to be able to perform everyday, but I mostly believe that it is stressful because human beings are naturally lazy, and programmers are even more so! "I'd rather write programs to write programs than write programs." -D. Sites

Distributed development could be pretty difficult, in getting the team to work properly and to get the desired end product.

AGILE

In Feb 2001 17 developers met together in Utah to relax, ski, eat and find common ground about lightweight software development. They created a manifesto which is the basis for agile development. Twelve principles behind the Agile Manifesto is also something important to look at to understand agile.

Some basic characteristics:

Small team size

Prefer face to face interaction over paperwork

Must have a Customer Rep

Iterative process

From what I looked at it seems like agile will have the same pros and cons as the scrum method which I have stated. There are a few different methods that are considered agile methods, like crystal clear, extreme programming, etc that will have different strengths and weaknesses. But it seems like scrum is a good example of a agile method. Now just like there are many ways of implementing a program, there are many implementations of the agile methodology.