This post originated from an RSS feed registered with Java Buzz
by Fred Grott.
Original Post: Agile and Workstation Tools
Feed Title: ShareMe Technologies LLC-The Mobile Future
Feed URL: http://www.jroller.com/shareme/feed/entries/rss
Feed Description: A Weblog about Java programming and digital convergence on mobile devices in such areas as P2P and collaborative technology.
I have stated before the most important tool in Agile is communication and feedback loops. But, it snot something you just blindly adopt like some trend setting manager who is into hype but not substance. You have to put some thought into it and have the communication and feed back loop processes enabled by tools that apply directly to developmental life cycle context.
For example not everyone likes TDD, it i snot an Agile requirement that you use TDD. However, there has to be some process whereas some analysis and testing of code is involved during most phases of development. You may decide that using unit tests without TDD is adequate due to team skills and other processes set in place. Of course that requires some tool son the build machine/workstation.
One example of not using TDD but still using unit testing but establishing a feedback loop process would be having the individual developer doing a test driven incremental build that is separate fro the single build machine continuous integration daily build. Why separate?
Well it has to do with a specific feed back loop in complex software development. Every computer language has so many frameworks and apis that no one developer will be able to memorize or be experienced in the full set of them. Thus, the problem is how can we get information and skills spread across a developer group fast and efficiently when a new project starts.
By using incremental builds and some testing in the hourly process of developing code per individual developer that individual is enabled to see feed back from those builds and make notes about his or her assumptions, what worked and what did not work and why. Couple that with a choice of communication channels to other tam members nd you have a very powerful feedback loop.
This means that the same testing and analysis reports that are generate in the continuous build environment should have generated or have the possibility of being generated during the developer incremental builds. Also part of that testing and analysis is having an workstation environment set-up to facilitate reaching those goals.
If you are using a continuous server for the team the individual developers should also have that setup for incremental builds that might be completed hourly or every few hours. The timing of getting this set-up should be at the beginning and yes it should be part every new developers initial time setting up for the project. You would be amazed how many managers buy Agile hype but do not understand this point and unfortunately the claim the consultant title and give software developer consultants a bad name.
Personally, I choose Ubuntu and OpenSolaris to use on workstations. You may choose something else. But, the important point does your choices allow you to set up tools that enable the processes such as a incremental build mirroring the continuous integration server environment, analysis of results using mathematics, code development tools, and communication channel tools.
Remember, when some consultant company highlights that they use say Scrum and it will save any project that they may lying. Not lying in the sens that they do not use scrum but lying in the sense that its the string of choices together coming together in an integrated developmental process that determines whether you have agile or not. A way to keep it straight, say Assemmbla staff, is to remember scrum is a tool and agile is a choice of tools integrated into a process or a group of processes. A tool by itself does not equal the Agile process!
And guess where the dependencies of Mythical Man Month come into play as far as maybe decreasing efficiencies when new developers are brought into a project? Agile is a process of making choices to enable the Agile process it is not a set of tools by themselves. Now, when a consultant firm states the process they use to analyze a project and choose from the broad set of tools choice that enable an agile process than you should ask to see some result but remember statistics about this process are not always forthcoming and one project can vary in a large amount from the next project.