Lessons learned from one agile project
I've manage one small project (3 developers - 6 monthes planned). Project was canceled due to some reasons (project progress was great, so the reasons are not in development :-). I briefly describe here what we've tried and what was useful for us. I think this information will be interesting. This is real example after all. The project was on Perl.
XP-style Planning. Small 2 weeks iterations. Small iteration helps to track project progress and create better estimates. Planning is quite easy and can be done in Excel without sophisticated tools like MS Project. We are going to use XP-style planning in future for high-risk projects (with new technologies, new team, or whatever make project risk high). Sure, web based tool for XP-planning can help.
Customer Feedback. Manage a project without client representative is a hell on the earth. You are working like in a vacuum. No response, no feedback and no attention. You can’t establish rapport with client, and there is a chance that system will not satisfy client expectations. And sure it won’t. Project Manager must make every effort to get a person from the client side for feedback.
Info for Top Managers. All information for top managers should be in a short and clear form. Do not send 20 pages requirements docs or lengthy emails. Top managers do not have enough time to read such docs. It is better to extract most important features and ideas at a single page and attach full document to be on the safe side.
Phone Calls. Phone calls are much better than emails or IMs. Sure, phone is impolite and it is hard to clear express your thoughts, but, anyway, phone is better. Many issues can be resolved faster and easier.
Test-Driven Development. We wrote unit tests for all business objects in BigEye before code, and it worked great. However, we did not have tests for controllers. Controllers are very close to GUI and they changed often (during first month). Maybe we should write unit tests for controllers as well, maybe not. This is unclear. But we should consider such a possibility in future. Anyway, TDD is good and we will use it as a mandatory practice.
Acceptance Tests. About 50 tests were created based on SAMIE. We modified tests quite often and spent near 0.5 hour per day to keep ‘em working. These tests helped a lot when we performed major refactoring at controllers and GUI layers. But it seems that SAMIE is not the best tool for acceptance testing. It is easy to use, but sometimes unstable and Win32 restricted. But I did not found a better one.
Refactoring. It helps reduce code duplication and keeps system architecture clear. We had doing refactoring constantly, and sometimes we spent on major refactoring whole day. As a result, new functionality implementation appears easier than expected. We will use refactoring as a mandatory practice in future.
Walking Skeleton. This is a first, fast and small release, which contains single system feature ‘in depth’. For example, show projects list, add project into the database, check user permissions on project. Walking Skeleton for the system took near 2 weeks. We manage to investigate many architectural decisions and choose the best. Small and fast release is a great thing.
Pair Programming. We create most important system modules in pair. The code quality and overall system architecture appears significantly better when pair programming used. Constant code review, communication and experience sharing are really great things. It is not easy to program 7 or more hours in a row, and you feel exhausted in the end of the day. But work satisfaction is great. We will use pair programming for teaching, experience sharing and critical modules implementation in future.
Code Metrics. LOCs dynamic, Unit Tests # dynamic, Acceptance Tests dynamic. Code metrics help to track project progress and predict team velocity and project size.
Project Site. Helps to organize important project related information (news, documents, actual project state, links) in a single place. However, Project site update should be more simpler. For example, we can use basic CMS for project site maintenance in future. Anyway, Project site is a good thing.
O/R Mapping. Tangram was used as an O/R mapping tool. It took about 2-3 days to resolve some tricky issues, but in general O/R mapping speeds up development and supports database abstraction. Maybe OODBMS is a better solution, but if you stick to RDBMS, O/R mapping will help. However, for small systems or web sites O/R mapping is not required.
System Prototypes. Helps to resolve many issues on the early stage. In general, the prototype should be created if project budget allows to. But I do not recommend create comprehensive prototype, since it just waste time. Prototype should contain major system modules and maybe some secondary.
Honesty. Just be honest with your teammates. They will trust you, and trust is one of the major factors for jelled teams.
Documentation in Source Code. Almost all system architecture related documentation was in source code. We used a tool to build linked html pages from POD documentation. As a result, documentation maintenance is easier. The week point is that source code less browsable (it is slightly harder to find a method while scrolling, for example).
XP-style Planning. Small 2 weeks iterations. Small iteration helps to track project progress and create better estimates. Planning is quite easy and can be done in Excel without sophisticated tools like MS Project. We are going to use XP-style planning in future for high-risk projects (with new technologies, new team, or whatever make project risk high). Sure, web based tool for XP-planning can help.
Customer Feedback. Manage a project without client representative is a hell on the earth. You are working like in a vacuum. No response, no feedback and no attention. You can’t establish rapport with client, and there is a chance that system will not satisfy client expectations. And sure it won’t. Project Manager must make every effort to get a person from the client side for feedback.
Info for Top Managers. All information for top managers should be in a short and clear form. Do not send 20 pages requirements docs or lengthy emails. Top managers do not have enough time to read such docs. It is better to extract most important features and ideas at a single page and attach full document to be on the safe side.
Phone Calls. Phone calls are much better than emails or IMs. Sure, phone is impolite and it is hard to clear express your thoughts, but, anyway, phone is better. Many issues can be resolved faster and easier.
Test-Driven Development. We wrote unit tests for all business objects in BigEye before code, and it worked great. However, we did not have tests for controllers. Controllers are very close to GUI and they changed often (during first month). Maybe we should write unit tests for controllers as well, maybe not. This is unclear. But we should consider such a possibility in future. Anyway, TDD is good and we will use it as a mandatory practice.
Acceptance Tests. About 50 tests were created based on SAMIE. We modified tests quite often and spent near 0.5 hour per day to keep ‘em working. These tests helped a lot when we performed major refactoring at controllers and GUI layers. But it seems that SAMIE is not the best tool for acceptance testing. It is easy to use, but sometimes unstable and Win32 restricted. But I did not found a better one.
Refactoring. It helps reduce code duplication and keeps system architecture clear. We had doing refactoring constantly, and sometimes we spent on major refactoring whole day. As a result, new functionality implementation appears easier than expected. We will use refactoring as a mandatory practice in future.
Walking Skeleton. This is a first, fast and small release, which contains single system feature ‘in depth’. For example, show projects list, add project into the database, check user permissions on project. Walking Skeleton for the system took near 2 weeks. We manage to investigate many architectural decisions and choose the best. Small and fast release is a great thing.
Pair Programming. We create most important system modules in pair. The code quality and overall system architecture appears significantly better when pair programming used. Constant code review, communication and experience sharing are really great things. It is not easy to program 7 or more hours in a row, and you feel exhausted in the end of the day. But work satisfaction is great. We will use pair programming for teaching, experience sharing and critical modules implementation in future.
Code Metrics. LOCs dynamic, Unit Tests # dynamic, Acceptance Tests dynamic. Code metrics help to track project progress and predict team velocity and project size.
Project Site. Helps to organize important project related information (news, documents, actual project state, links) in a single place. However, Project site update should be more simpler. For example, we can use basic CMS for project site maintenance in future. Anyway, Project site is a good thing.
O/R Mapping. Tangram was used as an O/R mapping tool. It took about 2-3 days to resolve some tricky issues, but in general O/R mapping speeds up development and supports database abstraction. Maybe OODBMS is a better solution, but if you stick to RDBMS, O/R mapping will help. However, for small systems or web sites O/R mapping is not required.
System Prototypes. Helps to resolve many issues on the early stage. In general, the prototype should be created if project budget allows to. But I do not recommend create comprehensive prototype, since it just waste time. Prototype should contain major system modules and maybe some secondary.
Honesty. Just be honest with your teammates. They will trust you, and trust is one of the major factors for jelled teams.
Documentation in Source Code. Almost all system architecture related documentation was in source code. We used a tool to build linked html pages from POD documentation. As a result, documentation maintenance is easier. The week point is that source code less browsable (it is slightly harder to find a method while scrolling, for example).
