When a release is to be made to customer, ensure that you have seen what is going across.
Ensure that QA had had a look at what is promised by developer.
Otherwise customer will get a error dump with long SQL statements and his feedback will be a bible that you will spend rest of your time analysing what went wrong.
A disaster of a delivery in the earnest of making by blindly trusting the developer is something that you should learn early in your birth else you are doomed and will need to search a vacant spot inside redwood tree.
Friday, September 18, 2009
Wednesday, September 16, 2009
tools
Image editing
Project Management - OpenProj
Bug lifecycle - Bugzilla
Test management - Testopia - can plugin to bugzilla
Google sites for managing project specific data management as well as for organisational specific data.
Google email and chat for project communication.
Security
- Online image editing tool - http://www.pixlr.com/
- Firebug - javascript/html/css debugging
- Web Developer - javascript/html/css/forms debugging
Project Management - OpenProj
Bug lifecycle - Bugzilla
Test management - Testopia - can plugin to bugzilla
Google sites for managing project specific data management as well as for organisational specific data.
Google email and chat for project communication.
Security
- SQL Inject me
- XSS me
persist
A PM rhetoric - not in time perse but from project manager desk.
Are you smart?
Are they not?
They are young and you are old.
They have come and you have seen.
Will you show the way or will you be runaway kid?
Patience pays but it also kills.
Nurture talent but tap appropriate one.
Lead by example but look back to see if someone is there.
If you are smart then you will move fast. What is smart?
Did you understand what I wrote?
Is my clearer or my vocals neat?
Am I ambiguous or clear?
Are you smart?
Are they not?
They are young and you are old.
They have come and you have seen.
Will you show the way or will you be runaway kid?
Patience pays but it also kills.
Nurture talent but tap appropriate one.
Lead by example but look back to see if someone is there.
If you are smart then you will move fast. What is smart?
Did you understand what I wrote?
Is my clearer or my vocals neat?
Am I ambiguous or clear?
Project vs Organization
Youth has tendency to do quality work and has general perception about that is. They believe anything done for customer is good work and anything that surrounds it is not priority work.
It's like, as long as my house is clean I don't care about the garbage that's collecting in the neighbourhood of my house.
Its like, as long I write code its heaven but if thats not a quality code or if customer does not accepts it its not my problem.
How to educate about ownership, towards self, towards organization that gives you salary, towards customers who give money to pay for salaries?
The above seems like simple maths. There are A B C and they are interlinked and they create a mutually sustainable eco-system. You have certain talents and skills for which you are paid.
I am not here to revolutionize but this is a challenge that you will obtain early in your company. Unless you have super-duper heroes who can carry hills on their shoulders but beyond them you will be clueless.
How do you find the flame in your team that will burn your enterprise furiously and over greater length of time? I dont know.
How do you detect that? I dont know.
How do you create that? I dont know.
But experience will tell you soon, what not to do and whom not to have?
It's like, as long as my house is clean I don't care about the garbage that's collecting in the neighbourhood of my house.
Its like, as long I write code its heaven but if thats not a quality code or if customer does not accepts it its not my problem.
How to educate about ownership, towards self, towards organization that gives you salary, towards customers who give money to pay for salaries?
The above seems like simple maths. There are A B C and they are interlinked and they create a mutually sustainable eco-system. You have certain talents and skills for which you are paid.
I am not here to revolutionize but this is a challenge that you will obtain early in your company. Unless you have super-duper heroes who can carry hills on their shoulders but beyond them you will be clueless.
How do you find the flame in your team that will burn your enterprise furiously and over greater length of time? I dont know.
How do you detect that? I dont know.
How do you create that? I dont know.
But experience will tell you soon, what not to do and whom not to have?
Reminders
You have to remind your team members to
- come on time.
- update status everyday
- make the status more descriptive
- share your learning in common knowledge portal
- share your learning in presentation to team
- show them their leadership potential
- tell them that their amiss and ignorance can cost them severely especially on quality issues
- watch their behavior and presentation
- tell them that it was supposed to be done on Monday and now its Friday
- improve their forgetfullness, no tablets or syrups here,
checklist
When you do repetitive tasks you tend to forget. When you have too many things you tend to lose track. When you are smart you think some things are trivial. When you are ignorant you simply don't know that such things exist.
Then checklists are born. They list all and collect information based on your running experience and helps you to stop and reflect and wonder Aha! how could I miss that?
A checklist template needs to be created to manage all the relevant items based on the stage you are in, say in coding you will have checklist to stop and wonder, Did you do all that was expected of me in terms of coding standards, communications?
The template should be made available in publicly shared area. Everyone should know where nice and easy things are kept.
It should be tailored and kept in your project repository.
You should decide on a frequency for running the checklist, like before you go on a trip to moon or once a week sharp at noon.
The updated checklist can be kept under project repository for audits and PM to know that you really run that check.
It will help you to improve areas that you ignore or miss and thus organization as whole.
Do you check list?
Then checklists are born. They list all and collect information based on your running experience and helps you to stop and reflect and wonder Aha! how could I miss that?
A checklist template needs to be created to manage all the relevant items based on the stage you are in, say in coding you will have checklist to stop and wonder, Did you do all that was expected of me in terms of coding standards, communications?
The template should be made available in publicly shared area. Everyone should know where nice and easy things are kept.
It should be tailored and kept in your project repository.
You should decide on a frequency for running the checklist, like before you go on a trip to moon or once a week sharp at noon.
The updated checklist can be kept under project repository for audits and PM to know that you really run that check.
It will help you to improve areas that you ignore or miss and thus organization as whole.
Do you check list?
Monday, September 14, 2009
scope - tracing
The following steps are expected to happen in scope management.
1. Customer requirements are broken up into manageable use cases.
2. Each use case can have multiple screens/UI.
3. Customer sign off on both use case as well as UI.
Tools used.
1. An excel with list of
1. Main Use case number
2. Main Use case description
3. Actors or users of usecase
4. Sub use case number
5. Sub use case description
6. Sub use case UI mockup/screen link on local as well on client location.
7. Efforts estimation
8. Developer assigned
9. Planned start/end date
10. Actual start/end date
11. Bugs raised and their types
12. Customer raised buges
2. Second section in excel will list the changes requested by customer
1. The changes will be continuation with main use cases but will be separated tracked and costed.
2. Newer requests will be fresh use cases.
1. Customer requirements are broken up into manageable use cases.
2. Each use case can have multiple screens/UI.
3. Customer sign off on both use case as well as UI.
Tools used.
1. An excel with list of
1. Main Use case number
2. Main Use case description
3. Actors or users of usecase
4. Sub use case number
5. Sub use case description
6. Sub use case UI mockup/screen link on local as well on client location.
7. Efforts estimation
8. Developer assigned
9. Planned start/end date
10. Actual start/end date
11. Bugs raised and their types
12. Customer raised buges
2. Second section in excel will list the changes requested by customer
1. The changes will be continuation with main use cases but will be separated tracked and costed.
2. Newer requests will be fresh use cases.
performance parameters
The quality attributes will form significant part of appraisal cycle.
The following items will be considered based on your project type
1. Code Reviews
1. How many lines of code was created?
2. What percentage was code reviewed?
3. Did code review follow scheduled time?
4. How many times was the code review missed?
2. Code Delivery
1. Was the code self reviewed and unit tested?
2. Did all task meet scheduled completion date?
3. What percentage of task missed deadline?
4. How many times did code mismatch happen because developer forgot to do an update before working on piece of code?
3. Bugs
1. Did you provide estimated time, deadline and actual time?
2. How many bugs were critical?
3. How many bugs were reported by customer?
4. Tracking
1. Did you provide actual start and end time on regular basis?
2. Did you provide daily status?
3. Was your daily report detailed enough with your effort?
5. Knowledge management
1. What new areas were covered in your projects?
2. Did you illustrate the challenges and your resolutions in your daily status?
3. Did you share your findings in knowledge forum?
4. Did you share your findings in person?
6. Contributions to organization
1. Training
1. How many seminars you took to train your colleagues?
2. Question bank
1. How many questions and to which technology area?
2. What were your ratings in online moodle test?
3. Helping other projects
1. Which other projects benefited from contributions?
2. Which other developer or QA or any other role benefited by your suggestions?
The following items will be considered based on your project type
1. Code Reviews
1. How many lines of code was created?
2. What percentage was code reviewed?
3. Did code review follow scheduled time?
4. How many times was the code review missed?
2. Code Delivery
1. Was the code self reviewed and unit tested?
2. Did all task meet scheduled completion date?
3. What percentage of task missed deadline?
4. How many times did code mismatch happen because developer forgot to do an update before working on piece of code?
3. Bugs
1. Did you provide estimated time, deadline and actual time?
2. How many bugs were critical?
3. How many bugs were reported by customer?
4. Tracking
1. Did you provide actual start and end time on regular basis?
2. Did you provide daily status?
3. Was your daily report detailed enough with your effort?
5. Knowledge management
1. What new areas were covered in your projects?
2. Did you illustrate the challenges and your resolutions in your daily status?
3. Did you share your findings in knowledge forum?
4. Did you share your findings in person?
6. Contributions to organization
1. Training
1. How many seminars you took to train your colleagues?
2. Question bank
1. How many questions and to which technology area?
2. What were your ratings in online moodle test?
3. Helping other projects
1. Which other projects benefited from contributions?
2. Which other developer or QA or any other role benefited by your suggestions?
Review process
Reviewee is the person whose code/doc is being reviewed. It is reviewee responsibility that all his code is self and peer reviewed.
Reviewer is the person who does the review.
The following are review steps-
1. PM
1. Creates review schedule in project plan
2. QA
1. Creates review plan in Bugzilla
2. Creates calender invite for reviewer and reviewee from schedule.
3. Reviewee
1. creates a review document/code.
2. Places it in ForReview folder before scheduled review time.
4. Reviewer
1. Obtains the relevant code/doc checklist from Quality--> Checklist folder.
2. Performs the review
3. Updates tracking
4. Submits the checklist at reviews folder.
5. Files bugs in bugzilla against the review plan.
5. Reviewee
1. Checks the relevance of review bugs.
2. Fixes bugs
3. Updates tracking and bugzilla
4. Informs QA for verification
6. QA
1. Verifies that all above step is followed.
2. Verifies the bug fix.
3. Closes the bug as fixed.
4. Closes the review plan in bugzilla
Reviewer is the person who does the review.
The following are review steps-
1. PM
1. Creates review schedule in project plan
2. QA
1. Creates review plan in Bugzilla
2. Creates calender invite for reviewer and reviewee from schedule.
3. Reviewee
1. creates a review document/code.
2. Places it in ForReview folder before scheduled review time.
4. Reviewer
1. Obtains the relevant code/doc checklist from Quality--> Checklist folder.
2. Performs the review
3. Updates tracking
4. Submits the checklist at reviews folder.
5. Files bugs in bugzilla against the review plan.
5. Reviewee
1. Checks the relevance of review bugs.
2. Fixes bugs
3. Updates tracking and bugzilla
4. Informs QA for verification
6. QA
1. Verifies that all above step is followed.
2. Verifies the bug fix.
3. Closes the bug as fixed.
4. Closes the review plan in bugzilla
Folder Hierarchy
The following folder hierarchy is recommended for your project. You will have to customise it according to your project need. All folders will be present in SVN under project specific repository.
In the below sample you will find main project name and under which you have project divided into multiple phases. Your project need not have phases.
Use dev/QA/prod directory structure for managing the development, testing and release/deployment to customer for acceptance.
1. Development is active in dev branch by developers. Developers label the build for QA and then copy it to QA.
2. Testing is active in QA branch by QA. QA files bugs against the build label in bugzilla. Developers fix the same in dev branch. Qa verifies the fixed bugs in next release from developers.
3. Customer gets copy from prod branch. He can file bugs against the release and/or provide feedback. Then cycle 1-2-3 starts again.
4. Any issue that come against a build in QA/prod are marked and logged in bugzilla against a label of build.
The following hierarchy is recommended for SVN
1. Trunks - Mainline of development. Touched by developers and unit testers.
2. Branches - Created on need basis for major feature, changes, QA or for intermediate deliveries.
3. Tags - A snapshot of deliverable to customer. Untouched and unchanged. Only for reference. Created by QA just before delivery to customers.
Projectname
|_
Phase 2[if required your project can have phases]
|_
Docs
|_
Design
|_
For Review
|_
DesignDocumentv0.2.doc
|_
DesignDocumentv1.0.doc
|_
Requirements
|_
Reviews
|_
DesignDocumentReviewChecklist.doc
CodeReviewChecklist.doc
|_
Dev
|_
Code
|_
Build
QA
|_
Code
|_
Build
Release
|_
Code
|_
Build
Project Management
|_
UseCaseTracking.doc
|_
ProjectTracking.doc
In the below sample you will find main project name and under which you have project divided into multiple phases. Your project need not have phases.
Use dev/QA/prod directory structure for managing the development, testing and release/deployment to customer for acceptance.
1. Development is active in dev branch by developers. Developers label the build for QA and then copy it to QA.
2. Testing is active in QA branch by QA. QA files bugs against the build label in bugzilla. Developers fix the same in dev branch. Qa verifies the fixed bugs in next release from developers.
3. Customer gets copy from prod branch. He can file bugs against the release and/or provide feedback. Then cycle 1-2-3 starts again.
4. Any issue that come against a build in QA/prod are marked and logged in bugzilla against a label of build.
The following hierarchy is recommended for SVN
1. Trunks - Mainline of development. Touched by developers and unit testers.
2. Branches - Created on need basis for major feature, changes, QA or for intermediate deliveries.
3. Tags - A snapshot of deliverable to customer. Untouched and unchanged. Only for reference. Created by QA just before delivery to customers.
Projectname
|_
Phase 2[if required your project can have phases]
|_
Docs
|_
Design
|_
For Review
|_
DesignDocumentv0.2.doc
|_
DesignDocumentv1.0.doc
|_
Requirements
|_
Reviews
|_
DesignDocumentReviewChecklist.doc
CodeReviewChecklist.doc
|_
Dev
|_
Code
|_
Build
QA
|_
Code
|_
Build
Release
|_
Code
|_
Build
Project Management
|_
UseCaseTracking.doc
|_
ProjectTracking.doc
bug lifecycle
The following lifecycle is expected for bug and The following are mandatory fields
1. A bug is filed.
1. Step by step description of bug.
2. Release - create one if none exists in consultations with manager.
3. Estimated time.
4. Deadline.
5. Usecase number.
2. Active bug.
1. Regular update of percent completion.
3. Fixed.
1. Actual time taken.
2. percent completion.
3. which files and functions were affected along with line number.
4. Verification
1. In local copy.
2. In remote production site.
3. Check if it affects other functionality.
5. Second level verification
1. A report for product/date/release and check for presence of above columns.
1. A bug is filed.
1. Step by step description of bug.
2. Release - create one if none exists in consultations with manager.
3. Estimated time.
4. Deadline.
5. Usecase number.
2. Active bug.
1. Regular update of percent completion.
3. Fixed.
1. Actual time taken.
2. percent completion.
3. which files and functions were affected along with line number.
4. Verification
1. In local copy.
2. In remote production site.
3. Check if it affects other functionality.
5. Second level verification
1. A report for product/date/release and check for presence of above columns.
Subscribe to:
Comments (Atom)