This blog focuses on Free/Open Source (FOSS) and Agile/Lean (AL) for Enterprise Information Systems (EIS). NSI has been using Free/Open Source since its creation, in 2002 (I use since 1998), however, AL is relatively new to us. I think it is interesting to tell how we "realized" AL.
Our Turning Point
In a broader sense, we started using automated testing in 2005, when we were developing a system for vibration analysis in LabView, which uses G, a visual language for Virtual Instrumentation. For us to test it, we had to simulate working gas turbines, which means to generate matrices with thousands of lines and dozens of columns, representing the vibration signals produced by dozens of sensors. In fact, we had to develop a complete simulation module that excited the analysis algorithms. Curiously, parts of this module were created before the algorithms, because we needed to understand better the behavior of a real equipment, in a kind of "proto" test-first way. Also, we filled vectors and matrices with trustful results obtained from laboratory's hardware and software, and automatically compared with our results, to check our algorithms' accuracy.
In the realm of Enterprise Information Systems, our use of automated testing was initiated only in 2007, when we started two important Enterprise Content Management (ECM) projects in parallel. We started to automate the "black box" tests - because we had no patience to simulate dozens of time the same users actions - and load tests, for obvious reasons. However, our unit tests weren't disciplined and sometimes were hampered by the platform we used. Obviously, the acceptance tests started to find wrong behavior in the software, given the lack of complete unit testing. By that time (with results published in 2007/2008), and in parallel, we developed a hybrid development process for the ERP5 system that used MDD (including a nice set of supportive tools) with automated testing.
The year of 2008 represented our turning point, because of three factors:
(i) We realized that our MDD-based process for ERP5 was sound, however, our industrial partners needed something leaner, and MDD didn't made much sense when developing on top of a highly reusable framework. Moreover, refactoring made modeling a waste in general. We realized in practice that a good design can be done on top of code, instead of models.
(ii) I managed to bring to the team an associate researcher who was (is) a very competent developer, and was (and still is) experiencing very good results by using Agile Methods. He made me remember of my Master Thesis (1997), which proposed a hybrid push-pull production planning and control method: instead of using complicated production programming algorithms, which needed very accurate (and usually inexistent) informations, Kanbans were used to smooth the production flow.
(iii) I read the book Ghost Force - The Secret History of SAS, written by Ken Connor, and realized that trying to use conventional methods for managing unconventional projects and teams was stupid. After exposing my impressions on some team coordination techniques narrated by the book, we immediately adopted two principles*: a) one man, one vote (the Chinese Parliament) and b) the one that holds more knowledge in the specific mission, leads it, doesn't matter his/her rank. Of course, we already knew that the most valuable asset of any team is its human resources.
*strangely my team didn't accept things like parashooting training, as well as other really interesting techniques presented in the book ;-)
So, I can say that we woke up for agile techniques as a whole in 2007/2008. In 2008 we started to use a Scrumban process, a mixture of Scrum for planning with kanbans for programming the production. Things weren't enforced, we realized that disciplined automated testing and Scrumban was superior for our environment, and that's it. When I say we, I am referring to everyone, from vocational to master students and researchers (one man, one vote, doesn't matter the rank...). In 2009 we started to use BDD, actually, we developed a tool stack for BDD in Python to serve to our projects.
In other words, although we are a small organization (circa 30 developers in different projects, divided into development cells, plus some 10 aggregated people), we came from a traditional way of thinking (but we never were bureaucrats) that in fact never worked well for us. In other words, we use AL because we realized in practice that it is better for us, not because it is fashionable. An interesting point is that our last paper on MDD + Automated Testing was cited by a very well known Software Engineering researcher as one of the references for modeling EIS.
We studied and tested the techniques by ourselves, using the Chinese Parliament and The Best in the Mission is The Leader principles to put them in practice. We did right and wrong things, adapted methods, mixed techniques, created tools for BDD, for improving programming productivity, for automated testing, for kanban control, and many others, only to cite a few, and we also used other people's tools. Basically, we discussed a lot. In other words, instead of following some manual, or standard, or course, or pursuing some certification, we created project management knowledge! A good result of this is that all five students that left our research group this year are working for innovative organizations, with salaries higher than the average. Moreover, they got their positions in highly competitive markets, including Europe. They were all hired in the same way: staying some days in the organizations, programming with the teams and taking part of meetings.
An intimate commentary: now I feel totally comfortable to teach project management and tell my daily experiences. Before that I had to teach techniques that didn't work for us, but I had to insist on teaching them because the books said that they worked - while feeling as an incompetent project manager. Now I can see that it doesn't work because this type of process cannot deal well with uncertainty in general (maybe really I am not a good project manager, however, now thing work well for us anyway).
A last commentary: although we are part of a teaching & research organization, we've been developing serious projects with companies and government agencies for years. When I say serious, I mean projects with deadlines, fixed budgets, lots of users, need of continuous support and evolution, and that are expected to aggregate value to the users' organizations. Every single software we developed since 2002 is/was either used internally - in our development process - or by our industrial and government partners. Moreover, since we develop free software, our products are also used by other people and organizations besides our formal partners.
No comments:
Post a Comment