|
Written by Daniel Leiderman-Gueller
|
|
Monday, 08 February 2010 02:09 |
More than a year ago I wrote a post about waterfall discussing the ideas we had for changing the development process. In this period were some personal changes, where the management is completely new from VP R&D to group managers.
With new management, the development process is evaluated again. This evaluation led me to discuss what a good development process is and what the phases of development are. I had discussions with several team leaders for gathering the mindset and understand what the assumptions for this development process are.
To my disappointment the mindset was classic waterfall requiring defined steps, explicit products of each process. Where each step needs to be completed fully before continuing the next phase, using design reviews as decision gates.
I won’t repeat why waterfall is problematic, it has been already discussed in previous post but I was surprised that team leaders were still convinced it’s the correct method of developing software.
Why was the waterfall the method chosen by the tem leaders? I'm not sure, but it seems it’s the most straightforward, most understood and vastly used by development companies. It’s also easy to implement as it segments the responsibility between different groups with specified timeline.
My personal opinion is that waterfall is not suitable anymore for development due to several reasons:
1. Software can use short development / release cycles for gradual improvement
2. Requirements are not completely known at design phases, so when they become known, the development has already started
3. Cross involvement is low as each step is handled only by one group.
In current state of technology and solutions, using waterfall is like going back to ancient development techniques and lose a lot of possible gains due to lack of flexibility. |
|
Last Updated on Monday, 08 February 2010 02:57 |
|
|
Written by Daniel Leiderman-Gueller
|
|
Tuesday, 29 December 2009 11:12 |
According to Webster dictionary one of the definitions of paradigm is “a philosophical and theoretical framework of a scientific school or discipline within which theories, laws, and generalizations and the experiments performed in support of them are formulated; broadly: a philosophical or theoretical framework of any kind”. In our broad technical perspective, it means the underlying ideas and concepts embodied in the system as understood by the engineers. The paradigm is a grand view of the system motives.
A more detailed explanation is presented in Wikipedia with the addition of discussing paradigm shifts. Paradigm shifts are defined as a major change in the perspective and theoretical model of mainstream science. They are disruptive but create new possibilities and new areas of investigation. In our perspective that means that something fundamental has changed, in the ideas, concepts, ways of doing things or common knowledge.
© IBM Paradigm shift is an important phase for a system, it manifests itself as a major change affecting the whole perspective and providing a pivot. this pivot can be used for major architectural changes and in turn be a driver for new capabilities or features not possible before.
Since paradigm shifts are rare, it’s hard to recognize them and utilize them correctly. This is why, keeping a perspective to identify them correctly while providing an incentive to pivot on it is crucial.
At the end, it’s about keeping the eyes open for change and understanding the magnitude of change.
|
|
Last Updated on Tuesday, 29 December 2009 11:29 |
|
Written by Daniel Leiderman-Gueller
|
|
Monday, 23 November 2009 04:13 |
MS-Project it a great tool, used as intended it can be a real time saver and help identify problems in project management long time before they occur. Unfortunately, using MS-Project for software development is the right recipe for disaster. I've been following the cause quite a long time, each time in different constellation, people trying to use Microsoft project for managing software development and failing again and again.
I've seen people using project in the broadest way, trying to define some time allocation and see where features are ready, failing due to erroneous estimates and huge interrupts. Other people tried to use resource allocation for managing feature development, failing due to miscalculations and bad effort allocation.
What are the reasons for such continuous failures? Is software development so unmanageable?
Part of it is yes, software development is harder to manage using old fashion tools like GANTT charts. The contrary is also true; using other methods software development can be managed and controlled.
What is the main problem with MS-Project? There are several, but the main problem is the idea of work day, same as man month. Programmers are not machines, and the production varies wildly between good and bad programmers. In addition the programmer needs to be in the zone and any interrupt can make havoc. MS-Project also guides the mentality of waterfall, where everything is known out front and even unknowns are “allocated”.
What other methods can be used?
• Joel on Software has a detailed method for software management
• Agile methods of short iteration.
• Many others
I believe in two basic things for correct analysis of work plans:
1. Have at least an initial design before providing any work estimate.
2. Have short development iterations, where each iteration can serve as a start for next phase in such way as effort is not wasted.
At the end, MS-Project is a tool, which can help or be abused. It’s important to understand the limitation and the range of possibilities. This post form randsinrepose is a great example. |
|
Written by Daniel Leiderman-Gueller
|
|
Monday, 16 November 2009 23:01 |
|
Last month I've been to two different customers. Although both customers are in a similar situation, of having a partial system needing work, it was a very different experience, one on the border of meeting pure evilness.
The two customers received a customized system, ready to be used with work remaining until it becomes operational. Both of the customers still need to work with us for completing the system and providing a full solution.
In spite the similar situation, the behavior of each customer is completely different. The first customer is completely cooperative, trying to make an effort so information flows in both direction and try to have a positive interaction moving the project forward to a suitable solution. The other customer is completely different; he’s uncooperative, trying to shift blame and accusations instead of information, looking for a reason to make the supplier provide documents instead of solving the real problems.
Discussing the difference with Mr. G, the responsible sales manager, we came up with several reasons for this different behavior:
1. Different cultures: some countries are notorious for being more xenophobe, thus giving a cultural background of not trusting the supplier.
2. Different organizational cultures: some organizations are less trusting, believing that the supplier is an enemy, compared with other organizations believing in cooperation and mutual benefit.
3. Young project managers: some organizations use the first position as a screening process, helping new employees to become familiar with the organization by being project managers as first position. Normally such employees have less experience and are more influenced by the organizational culture.
4. Experience: related to previous reason, young project managers, less experienced, probably don’t have the know how of making a relationship with a supplier work for the benefit of both sides and prefer to take a more cautious approach to the dealing with the supplier.
5. Personal contacts: since sales of customized projects have a long term evolution, relations between sales, project management and managers reflect the long term relationship, thus brining personal relationship to the project management. in cases where the relationship is good, the project management will be easier to handle.
Each of the influences can be reflected on the project management and in turn change how each side views the other. Unfortunately, one must also take into account the long standing quote from napoleon I: “Never ascribe to malice that which is adequately explained by incompetence. “ WebCitations |
|
|
|
|
<< Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>
|
|
Page 1 of 19 |
