No wonder that many companies and people say they are Agile, but when asked if they are programming in pairs, if they are test oriented or if they work 40 hours weekly, most times the answer is "not necessarily" or "more or less" or even "no, but we develop in sprints".
Being Agile is not easy.
At least we, the Agilistas, are aware that simply not being Agile is even more difficult.
Even with the adaptable agile methodologies, as Kanban for example, be Agile means a change in behavior, paradigms and to many people, a change of principles and personality (if that is possible). A major difficulty, at least in my personal experience, is having to develop together with someone who claims to be agile because it's fashionable, but not even believes in agile values and uses any argument and excuses to justify why not doing pair programming, not refactoring, not sharing the code, not developing unit tests and, especially, not focusing on delivering something executable at the end of an iteration. Even harder than being agile is explaining to a person who thinks is being agile that he or she is not.
(I want to quote here this other post that I found interesting: The emotional reaction to Agile adoption)
Even for someone who is actually Agile, it is extremely common skip some agile practices for indiscipline and laziness. I will not deny that it has happened to me countless times. When you are too absorbed and pressed with momentary and isolated problems, it is usual to lose perception of the global consequences of indiscipline. The problem increases considerably when the quality of work is not visible by others in the team or if you are not pair programming and there is nobody to inspect your work besides yourself.
In many cases, a tool that "forces" and "guarantees" the performance of the agile practices can greatly help a development team. I fully understand that human interaction is the most relevant factor to agile adoption, and that nothing can replace it. But I also believe that not all people have the agile values in nature, that even the agile pros can often be undisciplined and that simple reliance on individual effort is not always a success factor. An additional tool to aid human interactions (such as communication, sharing, respect, trust, ...) when an agile development team is being incipient can be a very efficient solution.
The advantages of the LiveSource Toolkit
Watch our DEMO video: http://www.screencast-o-matic.com/watch/cX6oVdTPZ
LiveSource is a Web tool that ensures the source code will no longer be hidden behind a complex file server access, but it will always be shared by the whole development team at a click away on your web browser. And further, this code will also be understood by non-programmers. At least, if the code is not understandable, the LiveSource Toolkit will let the problem be exposed in a way that programmers will not be able to argue with their technical jargon, so incomprehensible otherwise. It is a new technology for your software, clarifying the darkness of programming into an easy to read, step by step summary of the content.
LiveSource creates a medium that helps both stakeholders and programmers to work together on code in a high-level manner, to better improve the pair programming between programmers and even non-programmers.
Figure 1. A screen shot from the LiveSource Toolkit that displays the source code and an easy to ready filter of this source code.
Excerpted from a Tic Tac Toe game software project.
(Click on image to see enlargement)
The Figure 1 above is a screen shot from the LiveSource Toolkit. Notice that all data on the left frame was extracted from the source code displayed on the right. The left frame is just a filter of domain information relevant to a stakeholder.
Once a development team starts to apply the Ubiquitous Language within the source code, a new series of applicability for this source begin to emerge. LiveSource focuses on extracting the source code all the benefits generated by the use of ubiquitous language.
LiveSource publishes in a document’s format the true reality of a software project. What is not already implemented in the source code will be shown clearly, without having to go through parallel documentation or reporting tools like emails, bug tracking, task sheets, etc., where this reality can be easily masked by those responsible.
LiveSource publishes in a document’s format the true reality of a software project. What is not already implemented in the source code will be shown clearly, without having to go through parallel documentation or reporting tools like emails, bug tracking, task sheets, etc., where this reality can be easily masked by those responsible.
LiveSource also integrates user stories and tasking more tightly with codebase. If programmers insert domain information in the source code and also use ubiquitous language, turning this source code on a User Story or a Requirement is just a matter of extracting, filtering and formatting text from the code. Then, the team can automatically have a series of requirements listed as a scope view of the software.
Observe a Requirements list below extracted from the source code of a Tic Tac Toe sample project:
 Figure 2. Scope View through the Requirements List (Click on image to see enlargement) |  Figure 3. Source files view. (Click on image to see enlargement) |
As the requirements listed above on the left is a direct view (and filtered) from the source code files listed on the right, there's no way a programmer or a project manager, or anyone else in the development team, can manipulate this data to show greater productivity than what really has taken place.
Compare Figure 2 with Figure 3, see how easier it is to read and understand the structure and meaning of the source code after the LiveSource filters.
Unit Testing
LiveSource also shows accurately the presence or absence of unit tests for a given unit of code.
Figure 4. Link between a source file and its unit testing.
(Click on image to see enlargement)
Live Task Board
Because we are able to extract user stories straight from the source code with the use of ubiquitous language, we could create a tool that calls Live Task Board.
The Live Task Board is a dynamic and realistic view of the current status of the software. It can automatically update itself, because its content is extracted directly from the source code and not from a database of stories that have to be updated in parallel or stories written in paper on the wall that need to be physically moved by the team members daily.
If the developers stratify the software planning activities in simple as possible tasks, very minimal in its size, as minimal as a single development class, the complexity of the user stories becomes more understandable and accurately estimated.
Figure 5. The Live Task Board
(Click on image to see enlargement)
It is fully understandable the wonderful effects of a simply task board on the wall in front of the development team, especially during a Scrum Stand Up Meeting. This means an evolution compared to traditional development models, with their extremely complex and unrealistic timelines. The idea of LiveSource is not to replace the interaction moments between the team, bringing one more tool to be used by developers, but to further enhance communication, leaving the manual task of updating the artifacts to be performed by a computer. It provids much more time for the team to discuss issues related to the tasks themselves.
The team can project the Live Task Board on the wall and continue adding post-its to the projected screen. At the time a programmer is generating the source code for a specific task, the information from the post-its can be used as code documentation and thus the related task automatically returns to the Live Task Board, all electronically and much more permanent.
Viewing the source code in a filtered and clean manner, gives the programmer an immediate idea of what needs to be improved. It causes them extreme discomfort to view their work so clearly when is not done well. It is a situation that only real experience with LiveSource can demonstrate its full extent.
Now imagine the impact of a confusing code being viewed by everyone on the team. No programmer will like to be responsible for this code. And possibly will not be, since the tendency of the programmer will be to prioritize refactoring, reducing the complexity of the source code considerably.
That is why LiveSource can be considered a tool to increase software quality. Because it allows great visibility to what is actually being developed.
The idea is, with LiveSource you can not disguise when you're not being agile. Not even to yourself.
Then, don't forget to send us your comments!
No Rigths Reserved. Please copy us!
No comments:
Post a Comment