Notes to Developers
I’ve been both developer and manager for years on both large and small projects with various sized teams. During the week to week management of these teams I tend to send little notes to help guide our work process. This week I have been breaking in a new team.
I thought it might be useful to other technical project managers and team leaders if I shared some of this week’s raw notes. I hope it’s useful for other managers to have a glimpse into the day to day notes of another in their same place.
Time Sheets
Please enter your time regularly into Fresh Books. Smaller more frequent time entries are preferred. Try to break them down by tickets and tasks in those tickets. Please always include the ticket number you were working on.
Please keep your entries up to date daily while on a project.
SVN
I believe in update and commit often.
Make sure you update and resolve conflicts before committing.
Enter in notes about what you are committing and when possible, enter the relevant ticket number.
Commits will auto deploy to the server within a few minutes. If you break something, you can roll it back but email the rest of the team to let us know so we can make sure to match our revision to the latest version on the dev server.
To roll back, log into [Spring Loops], choose the project, and then deploy the previous version number.
Remember that other devs are working in SVN too. So, update often, typically before starting a new change set. And commit often. I can help with any merging issues if you need it.
[Info here on how to contact me for an urgent need.]
Further Notes on SVN
The following is just a brief reminder about steps to take to not over write others work.
When you start coding in a file, first update that file from SVN to start your code on the latest version. Then code your changes. When you check back in the code your SVN client should tell you if your check in conflicts with the latest version. You should do a quick compare between the file you are checking in and the file in the repo. If there are no conflicts then great, but if there are conflicts, try to merge them or just send me your file. I’ll merge it in for you. [This is for junior devs.]
Tips: Make changes and check-ins on a file by file basis. Don’t code for six hours on six different files and then check them in. You will break code because this project is not segmented out into separate areas. Check in and update often. Test your check-ins to see if they work on the dev site.
If you think someone broke your changes, go to the [Spring Loops] site and browse the last few check-ins. It shows a nice diff between each version. Free iTunes song if you catch me over-writing your changes :)
Project Wikis
Each project has a wiki. Some may have two.
There is always a main wiki for projects. It follows the client name then will link to the project name. This is where most info is stored. Please note the client sees this wiki as well as you.
In addition to the client wiki, devs also have access to their own wiki. Some jobs have their own page in this wiki. I may use these pages to post developer specific info, or even sometimes general info that the client does not need to know.
I work more on the “pull” type of communication rather than “push” interrupt type, though I’ve been emailing you each lately because you’re new to working with me.
In general, I’ll post stuff in the wiki area that you will likely need to know, such as user names and password. If you like, you can subscribe to a project’s wiki page, but you don’t have to. Just check it when you need the info. Email me if you don’t find it.
Tickets
Most tickets will have the default priority of 3.
Please work tickets in order of the soonest milestone and then highest priority.
When you receive a ticket, please enter an “estimated time” in the field of the same name.
When you start a ticket change the status to: Active (Checked Out)
This tells me that this is THE ticket you are working on right now. I tend to move tickets around sometimes based on your schedules and when something needs to be completed. So use this to tell me the one ticket you are working on or left off on. That way I won’t swipe it.
Don’t worry; you are not going to be held strictly to the time estimates. This field tells me two things:
-
You’ve seen the ticket.
-
A general idea on how long you think it might take you.
As you work a ticket and make commits please enter small notes about what you’ve done. Nothing too fancy or formal is required. Remember clients may see ticket notes. Anything that is dicey, or a comment which may offend a client, please email me separately.
Once complete please assign the ticket back to me with any notes I’ll need to review it.
If you need a question answered, please enter the question in the ticket and assign it back to me. I only guarantee I’ll see tickets that are assigned to me.
Time on Tickets
Please note that I try to break tickets out into 4 hours or less. I generally put an estimate in their (usually when estimating the whole project.) When you start the ticket, I want you to put in your own estimate. It does not have to match mine. In fact it probably won’t.
You may use the estimated times as a guide line to keep yourself from getting lost in the weeds. If you find yourself spending significantly more time than what you or I estimated, let this be a trigger to ask for help. A second eye on the issue can help. Plus, I may want you to take a break from that ticket and work on something else.
Ticket Filters
Under the “Filters” Menu you should see a shared filter with each of your names, plus one called “Up for Grabs” (see below.) Select your filter to see all tickets assigned to you, order grouped by milestone then ordered by Priority. If you are working on more than one project, please make sure you track and enter your time separately.
Up-for-grab Tickets
I may assign tickets to the up-for-grabs user. This means that the ticket is up for grabs. If you want more hours, feel free to take the ticket, assign it to yourself, and enter an estimate. Assigning the ticket to yourself is a notice to everyone that you have it now.
Please note, if I need the ticket complete before your next working time, I may have to reassign it.
DB Changes
Views
If you make some changes to a view locally, you can export it and then import it into the dev site, commit the exported code in trunk under a new directory called exported views, or use the following method:
http://treehouseagency.com/blog/steven-merrill/2008/11/05/speed-and-version-your-views
I prefer the later but am okay with quick import and exports as this site is still in dev.
[Blog post note: features, contexts, and spaces are my current favorite for pushing changes via code.]
Share or Comment via Twitter