-
Do you know how to manage Tasks/Product Support?
If you are the Primary or Secondary developer on a project ensure that you follow
this standard for managing support and enhancement requests from external users
and/or your SSW manager.
Developers need to know how to allocate high priority bugs, over low priority bugs.
This is how you should triage the emails
you receive:
- SUPPORT
- If a known issue - then reply with KB (****link)
- BUGS
- If it is a bigger issue (i.e. > 1/2 hour), move it into the project's Public
Folder using Incident PRO! usually to the current release eg. Release09
- Note: Reply to the customer using (****Link: Client Diary Category "Product
- Support - Product Suggestion")
- IMPORTANT EMAILS
- The decision needs to be made if in this release or the next release
- The developer should be able to work it out and if not sure then ask the customer
- LITTLE INCIDENTS
- If it is a quick issue (i.e. < 1/2 hour) then action immediately
- Note: Reply using Incident PRO! (as an additional item in the current release)
- STANDARD EMAILS - enhancements and suggestions
- (ensure enhancements are approved), e.g. user interface improvements, changes to
reports
- Move to Public Folder using Incident PRO! usually to the next release eg. Release10
- FUTURE FEATURES - things we don't need at SSW and are not high priority, e.g. examples
are adding security support to Data Renovator
- Move to Public Folder using Incident PRO! to a folder named zsFutureFeatures
If you are the primary developer and are overloaded (that is you are not able to
action the Incident within 48 hours, get help from the secondary developer (or contact
your manager). e.g. if you are working on site for 3 weeks and have 10 customer
emails that you cannot do immediately.
Note: a developer should not have any support emails from customers (in their
inbox) that are older than 2 days.
-
Do you know how to manage your files?
We need to differentiate between web projects and Windows projects. But we want
the two different types of projects to exist in basically the same location. So
we use the following method.
Create a folder on your working drive (usually C: drive) called Data<firstname><lastname>
using your first name and last name.
e.g. C:\DataAdamCogan
Then create the following folders underneath that folder
- ProjectsWinTFS - To store Windows Project / TFS e.g.
C:\DataJohnPrince\ProjectsWinVss
- ProjectsWin - To store Windows Project / Non-TFS e.g.
C:\DataJohnPrince\ProjectsWin
- ProjectsWinTemp - To store Windows Project / Demo/Temporary e.g.
C:\DataJohnPrince\ProjectsWinTemp
- ProjectsWebTFS - To store Web Project / TFS e.g.
C:\DataJohnPrince\ProjectsWebVss
- ProjectsWeb - To store Web Project / Non-TFS e.g.
C:\DataJohnPrince\ProjectsWeb
- ProjectsWebTemp - To store Web Project / Demo/Temporary e.g.
C:\DataJohnPrince\ProjectsWebTemp
What projects do we use Team Foundation Server with:
- Yes - .NET. The master version for VB6 and .NET projects should be kept in
TFS.
If the settings are in Access then the .mdb is in TFS
- No - Access Frontends. As it corrupts the .MDB with all the forms in it
The .MDB and associated files should be stored on a network share
- No - Web Site. Stops you from using front page
- For further information see
Do you know how to use source control properly?
-
Do you keep Backup Versions?
Often we will be asked to "fix up" existing Web or Windows applications. We should
always keep a copy of the original version so we can compare the latest version
with the original. We also keep a rolling 4 versions of the application saved on
a weekly basis. The versions should be saved as following:
- ApplicationName - Current version
- ApplicationName_v001 - Original version - This is NEVER deleted
- ApplicationName_v008 - Oldest version apart from the original
- ApplicationName_v009 - Second oldest version apart from the original
- ApplicationName_v010 - Second youngest version apart from the current version
- ApplicationName_v011 - Youngest version apart from the current version
At the end of the forth week the oldest version is deleted (in the above example
_v008) and the youngest version saved (_v012).
-
Do you create product documentation and make it easily accessible?
- For client projects:
- Make a HTML file for the Client to read. E.g. http://www.ssw.com.au/projects/PA_FRDC
- On that page refer to the:
- For internal products:
-
Do you do Continuous Integration when Developing and Testing? (aka Don't use TFS
as a Network Share)
|
What is Unit and Integration Testing?
Erich Gamma and Kent Beck started a framework for writing tests during your design
phase. These are widely accepted as very good programming practice (in fact, some
may consider it extreme).
Some background for these people. Erich is a major contributor of the book "Design
Patterns" (must read!). Kent is the author of "Smalltalk Best Practices"
 . These are some of the very smart people who pulled together
years of experience and patterns that can be used in the design and development
of goods software.
Their work is JUnit on http://sourceforge.net/Projects/junit/
but that is a framework for Java.
A .NET implementation has been ported, and is at http://sourceforge.net/Projects/nunit/
.
There is a very good article you should read http://junit.sourceforge.net/doc/testinfected/testing.htm
|
Development is to be done in pairs. The process is:
- Check out code
- Do the development (you write test code first)
- Run your tests - keep the errors to 0 - (unit testing)
- Get Latest
- Run your integration tests - keep the errors to 0 - (checks the new build including
setup.exe) (daily)
- Check in code (aim for twice a day, lunch and prior to going home)
Add version numbers to your application. If the code is reviewed by a manager it
must be commented that it has been reviewed. Every application should have a version
table. For every change a new version number with comments should be added into
the version table.
Modules/Classes should have enough comments to explain the logic for a second developer
to understand. After commenting put your initials, this way other developers know
who made the changes.
The project manager should check it before you release the first few versions to
the client, he should finds things like tab order etc...
-
Do you enforce Collective Ownership of code by all developers?
- Developers should not have ownership of code - if you see something wrong fix it
and them email the original developer the fix you made (with the aim he/she learns).
- Pair Programming - two people together write production code
- People move around e.g. Work on other people's code, that way they see all the code
and they work with all the developers
- Developers must write readable code
-
Do you make the first release a Setup.exe (aka Setup.msi) ?
Zero Feature Release - Setup.exe is your first version. This is done because if
you are having problems with no feature, then you are in trouble This will be the
setup.exe with one empty page:
- Create the db
- Create the virtual web
- Copy a page to it
- SELECT @@SERVERNAME
The Wise Setup Script should be kept in TFS under a folder called setup inside the
product folder.
-
Do you make sure you have a Release plan for any project longer than 3 days?
Get an OK on a "Test Please" email
Release with a "New Release and Debrief" email generated by Incident PRO
(prefered) or Time PRO! Smart Tags.
So, this is the basic release pattern:
Send Pre-Release Summary for Release 1 to Primary Contact
Complete Release 1
Send "Quick Test Email" to one Tester/Customer - wait for "OK"
Send "New Release and Debrief" to SSWAll/Customer
Send Pre-Release Summary for Release 2 to Primary Contact
Complete Release 2
Send "Quick Test Email" to one Tester/Customer - wait for "OK"
Send "New Release and Debrief" to SSWAll/Customer
And so on.... for the other releases
-
Do you give customers a daily update (aka Reply "Done" to your emails
every day)?
Keep the customer informed. Every time a feature is complete (1 to 3 days)
then let the customer know. You don't have to do this but keeps the customer confidence.
As per above there are a minimum of 3 mini releases (see the breaks in the bullet
list).
See Rules to
Successful Projects regarding project plans and deadlines.
-
Do you send a confirmation of Change Requests to clients?
We prefer not to create unnecessary admin when clients request to know "how
much" a new piece of work is. Our preferred method is to send and email, saying
"we estimate the work will take about this long, would you like me to go ahead?"
Unless specifically requested, don't create a document.
|
From: John Liu
Sent: Friday, 11 January 2002 9:36 AM
To: Gary
Subject: RE: IMPORTANT - For Sales Analysis
Done
John
This email was generated by www.ssw.com.au/IncidentPRO
-----Original Message-----
From: Gary
Sent: Thursday, 10 January 2002 19:25
To: John Liu
Subject: IMPORTANT - For Sales Analysis
OK
-----Original Message-----
From: John Liu
Sent: Thursday, 10 January 2002 19:25
To: Gary
Subject: IMPORTANT - For Sales Analysis
Approx 2 hours. Do you want me to go ahead for this release?
-----Original Message-----
From: Gary
Sent: Thursday, 10 January 2002 19:25
To: John Liu
Subject: IMPORTANT - For Sales Analysis
Need to have an EmpID on the OrderDetail. How much?
|
As per the prior email the customer is encouraged to email you with requests/bugs.
Generally you will accumulate these for the next release. However the things that
are easy or very IMPORTANT you will probably do. e.g. Say after the first release
the customer notices the GST calc is wrong - complete it - reply 'Done'.