The Agile methodology has a lot of pros and cons. \u00a0In fact, it is one of the most common argument\/discussions I have with a mentor of mine. \u00a0He likes to point out (correctly in most instances) that the Agile approach skips out on important design. \u00a0It causes a lot of re-work because of that lack of up-front design. \u00a0This\u00a0re-work is only partially a problem. \u00a0The Agile method assumes that changes will come during the implementation of a project. \u00a0Instead of spending time up front in design on things that end up being thrown away, Agile takes a just-in-time approach to all phases of a project. \u00a0I have witnessed a lot of good and bad in these type of projects and found a few ways to help your Agile project improve its success rate while still delivering quickly.<\/p>\n
Although the design phase is not front loaded for Agile like it is for Waterfall it is still required. \u00a0Coding without design is like driving without a map. \u00a0You might have an exciting journey, but it will almost never be the most direct route. \u00a0Teams that have seen success using Agile also have a design portion of every sprint. \u00a0This step does not have to be highly formal, nor does it have to take long. \u00a0A day or two of design at the front of a two-week sprint will do wonders for quality and help you meet the estimates. \u00a0Do not take my word for it, give it a shot for a couple of sprints. \u00a0This period does need a quick turn around though as there will likely be clarification requested of the business side or critical stakeholders.<\/p>\n
In the same vein, testing along the way is critical to Agile success. \u00a0A primary aspect of this approach is that things will change. \u00a0A good bed of unit tests and regression testing will allow the changes to made while minimizing the impact on quality. \u00a0Yes, the tests will have to change and might even need to be rewritten. \u00a0However, they will be critical for assessing that a change has not broken other areas of code. \u00a0A team that uses Agile and regularly has to \u201crefix\u201d a bug from QA can help themselves with a good set of unit tests. \u00a0Of course, tests must be run to be useful so incorporate them into the build process.<\/p>\n
Since Agile assumes requirements will change we need to do our best to limit the impact of those changes on implementation. \u00a0When processes or objects are being designed that means we need to be careful of our assumptions. \u00a0Simplicity and performance may imply that we take a design path because of certain assumptions. \u00a0However, when those assumptions prove incorrect we can find ourselves coded into a proverbial corner. \u00a0Thus, when faced with the possibility of coding a tight solution based on assumptions it is good to ask the \u201calways or never\u201d question.<\/p>\n
This takes the form of \u201care you sure this will never happen?\u201d or \u201care you sure this will always happen?\u201d \u00a0It is worth it to emphasize the question and the assumptions to assure you that the right approach is being taken. \u00a0When in doubt, avoid coding yourself into a corner. \u00a0Functionality correct, but less than perfect performance is better than non-functionality. \u00a0That is what refactoring is designed for.<\/p>\n
There are many ways to follow these guidelines in practice. \u00a0Of course, Agile is all about limiting documentation and speeding implementation. \u00a0I have found that pseudo-code and comments at the start of implementation help enforce both design and testing. \u00a0When you insist that all functions and methods include comments about inputs, outputs, error-handling and a brief description of functionality all of these concerns will be addressed.<\/p>\n
It is not a perfect solution.\u00a0 Nevertheless, it will help with documentation while asking the developer to think about the code before they write it. \u00a0I have not seen it done, but I think you could even do a comment task on implementation items early in a sprint. \u00a0Ask the developers to write out the comments, test conditions and parameters for everything first, then the code can follow. \u00a0This is much like test-driven development.\u00a0 In a similar fashion, it pushes implementors to think about design before they get into the coding.<\/p>\n","protected":false},"excerpt":{"rendered":"
The Agile methodology has a lot of pros and cons. \u00a0In fact, it is one of the most common argument\/discussions I have with a mentor of mine. \u00a0He likes to point out (correctly in most instances) that the Agile approach skips out on important design. \u00a0It causes a lot of re-work because of that lack […]<\/p>\n","protected":false},"author":1,"featured_media":376,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"categories":[20],"tags":[14,31,28,9],"class_list":["post-373","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-building-software","tag-design","tag-developer","tag-planning","tag-projects"],"yoast_head":"\n