Good morning/afternoon and welcome to Web Application Project Management 101. My name is Jeff Chastain and I am a senior architect and project manager with Alagad. Basically that means that I am supposed to know what I am talking about, and as long as Doug (my boss) believes that, I am in good shape. For those that don’t have the dubious distinction of working with me, I am a perfectionist and believe heavily in process – thus the point behind this presentation.

Regarding my expertise, or lack there of to be giving this presentation, I will start out with this disclaimer. There are no good project managers – only lucky ones.

However, the goal today is to show you some tools that can help you become a bit luckier in your future endeavors.

Before we get started for all of those fastidious note takers out there, a copy of this presentation is already on line at this web address and includes all of the notes as well. So, just sit back, relax, and open up your mind.

So, to get started, has anybody here ever been on a project like this? The better question is, how to we keep from getting to this point?

With small projects, many developers can get by with a little up front discussion and then fly by the seat of their pants. With larger projects, you have many developers working together over months or even years. At this point, without a structure approach, you are asking for disaster.

Project management is such a big topic, you can spend days talking about it. I have been through week long classes before on project management and given that we only have an hour, I am going to focus on two main areas. Resource management – How do you keep developers from stepping on each other? How do you get new developers up to speed? How do you roll developers off a project? Code management – How do you maintain a code base with lots of activity? How do you keep the bugs in the code to a minimum? How do you get a clean, easy, repeatable release?

So what are the different phases of a larger project that you must look at ahead of time? - Requirements gathering and planning - Task management - Source control - Testing - Issue tracking - Release management

So the first thing we need to figure out is what are we going to build, right? Has anybody ever written a requirements document before? What is the saying about the plan – the first thing to go is the plan. So why bother?

Being developers, few of us want to admit this to each other, much less to a boss or client, but we all know, the reason you plan is because the sooner you begin coding, the later you will finish. So, we need to gather requirements before jumping in with our trusty code editor, but how?

There are several development approaches out there that you have probably heard of before. One of the big ones right now is called Agile development. With Agile development, the whole point is to take the project in small chunks and generate results as fast as possible. This has the benefits of requiring less up front work in gather requirements – you only need to know a few things to start work. In addition, you can generate results faster, thus having something to show the customer sooner. On the flip side though, there is no big picture of the entire project. You are working one piece at a time and when the next part does not quite fit, you have to go back and refactor. Granted refactoring is part of any application over time, the less you initially have to do, the better as you will have a more cohesive result.

The other traditionally popular development approach was called the waterfall approach. With Waterfall development, the project is approached in horizontal layers. First you get requirements for the entire project, then you lay out the architecture for the entire project. Then development is done for the entire project before it is presented for testing. The obvious benefits here is that you have a big picture view of the entire project and thus can lay out a cohesive approach for development. The drawbacks are equally obvious in that your deliverables take a long time to show up and once they are presented for feedback, things are so locked in that changes are very difficult and painful.

Since both of these approaches have benefits as well as significant drawbacks, lets take a look at a more hybrid approach. First, approach the project requirements from a very high level, big picture stand point. I don’t know about your projects, but most of the time on mine, the client does not even completely know what they want and thus they won’t be able to tell you. Once you have a general concept of the whole project, start with a prototype. Prototypes are visual aspects of the project – user interfaces. This allows the client to see a picture and be able to walk through the application before you have put all of the time and effort into modeling and development. This is the point at which you narrow down the details – which fields should go on this form and which ones are required. This can also be done in pieces, prototyping one section of the project and getting feedback as you move on to the next. Once you have agreed upon all of the functionality with a prototype, then you begin development. By delaying development until this point, you have a comprehensive plan to develop from and the client has already seen and agreed to what you will be building.

Okay, we have a plan now and we know what we need to do. Time to start coding? Wrong …. this is where project MANAGEMENT comes in. Why should we track tasks? What needs to be done? Are developer’s working on tasks on the critical path? Or worse, are developer’s working on the same tasks? How far along are you?

What you really need is a good way to track tasks. Tasks need to be visible to everybody on the team and everybody needs to have access to them. Having one person with the “master” document just makes a bottleneck in the process and we don’t need any more of those. On the good side are free and open source applications like Trac and Redmine. Both offer the ability to create tasks, group them by milestones and assign them to different users. If you don’t want to setup and maintain your own server, Basecamp is a hosted service by 37Signals that makes tracking tasks very simple. Things you want to avoid include email, spreadsheets and even Microsoft Project. Email is way to easy to get lost and there is no big picture as to who is doing what. Spreadsheets are not easily maintained and typically suffer from the “master” document issue. MS Project can be a good solution, but only if you go the full Project server route which means you have very deep pockets. Otherwise, it is no different from a spreadsheet with regards to maintenance and visibility. So, setup a task management app, outline your tasks and assign them. Both your and your development team will appreciate it.

Phase 2 – Source Control. Has anybody ever seen this scenario go down? Ever been on the receiving end of it? If you have ever worked on a larger project with multiple developers, having a source control system is a no-brainer. - All of the code history is kept and tracked … you can always go back. - Multiple developers can work in the same file and have their changes merged. - Diff … who changed what, when and why? Source control comes in a variety of forms with Subversion and CVS being the most popular. There are many hosted solutions out there for source control or you can easily deploy your own SVN or CVS server – they are both free and open source.

I know, you never have bugs in your code, but on occasion one sneaks into my code. I swear one of my colleagues put it there, but I get to deal with it. So, how do you handle issues when they come in? Do you just fix them on the fly or do you track them …. Hint, we are talking about project management tools here.

Why would you want to track issues instead of just fixing them on the fly? By tracking the issues, you can know things like … - Is anybody working on an issue or was it forgotten? - Has the issue been fixed or is it still pending? - Which issues are more important and are those issues being focused on? - Has this issue appeared before? Lucky for us, tracking issues is not that different from tracking tasks, so many of the same tools can be used. Once again, open source applications like Trac and Redmine make the list as well as Lighthouse, a ColdFusion solution by our own Ray Camden. Again, solutions like email and spreadsheets are not good for the same reasons they are not good for tracking tasks – it is not easy for everybody to access them or to keep a big picture view of where multiple issues stand.

We have completed this masterpiece of coding and now it is time to release it for testing, development, client abuse …. how do we do that? As this says, do you have a strategy or do you cross your fingers? Most times, there is more to code release than just copying a few times. For example, when you pushed out that last set of changes, did you remember to clear the trusted cache on the server? I don’t know how many times this one has bitten me before. So what makes up a code release? - Getting the latest code, packing and compressing it - Moving the code to the proper location … staging, testing, production - Configure any settings … data sources, file paths, server addresses - Initialize the application, clear the cache, etc. - Test … did it really work? There are so many steps involved with releasing a new version of code, how do you make sure you get them in the right order and don’t miss one? If your answer is a spreadsheet, then you missed the point of this session.

A good code release process is easy, easy reproduced, and automated. First off, you need to script your build. Apache ANT is a simple XML based scripting language that allows you to define a set of steps to perform … everything from checking files out of source control, packaging them, ftping them to a server and just about anything else you can think of. Second, once your build is scripted and easy to reproduce, the next step is to automate it. CruiseControl is an open source Java based application that allows to do things like run all of your unit / functional tests on a nightly basis or setup a nightly build to your testing environment. The more automatic you can make your release process, the fewer nightmares you will have … I promise.

Finally, it is time for the post-mortem …. in this case otherwise known as Q&A? I promise to listen to your questions, though whether or not you get a good answer is to be seen.

no notes exist for this slide

no notes exist for this slide