Промышленный лизинг Промышленный лизинг  Методички 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 [ 34 ] 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101

Understanding Light and Heavy Methodologies

The choice between using a light or heavy methodology determines the success of the project.

Light Methodologies

Ever-increasing technological complexities, project delays, and changing client requirements brought about a small revolution in the world of development methodologies. A totally new breed of methodology which is agile, adaptive, and involves the client every part of the way is starting to emerge. Many of the heavyweight methodologists were resistant to the introduction of these lightweight or agile methodologies (Fowler 2001). These methodologies use an informal communication style. Unlike heavyweight methodologies, lightweight projects have only a few rules, practices, and documents. Projects are designed and built on face-to-face discussions, meetings, and the flow of information to the clients. The immediate difference of using light methodologies is that they are much less document-oriented, usually emphasizing a smaller amount of documentation for the project. For example, they are somewhat code-oriented: The team considers the source code as the project documentation. Advantages of a lightweight methodology include:

It works well with change.

It is people-oriented rather than process-oriented. It works with people rather than against them.

The methodology is complemented by the use of dynamic checklists.

If a client constantly introduces frequent changes to the design to see what the solution will look like possibly to see immediate results or functionality of the product a light methodology may be the suitable route to follow. Although you might set some limits to prevent too many changes, in todays ever-changing technological environment, clients might prefer that the project proceed in smaller iterations. The great thing about light methodologies is that they are learning methodologies. After each build or iteration, the team learns to correct issues on the project and improvement cycles form throughout the project. Additionally, with light methodologies, the project teams are smaller and rely on working more closely, fostering knowledge sharing, and having almost instantaneous feedback. The project manager does not need to develop heavy project documentation, but should instead focus on the absolute necessary documentation (i.e., project schedule).

Heavy Methodologies

The traditional project methodologies (i.e., SDLC approach) are considered bureaucratic or predictive in nature and have resulted in many unsuccessful projects. These heavy methodologies are becoming less popular. These methodologies are so laborious that the whole pace of design, development, and deployment actually slows down



and nothing gets done. Project managers tend to predict every project milestone because they want to foresee every technical detail (i.e., software code or engineering detail). This leads managers to start demanding many types of specifications, plans, reports, checkpoints, and schedules. Heavy methodologies attempt to plan a large part of a project in great detail over a long span of time. This works well until things start changing, and project managers inherently try to resist change.

If the project manager does not obtain a complete list of user requirements from clients for the heavyweight project, its very likely that the heavy methodology will not work effectively because the project will be racked with change, slippages, and rework on the project documentation. A heavyweight methodology works on the assumption that the more rules and coordination there are, the better the project result will be. A complex project requires sufficient documentation just to jog the memory of the many team members on the project. However, excess methodology is very costly and inept there are more updates to reports, plans, and schedules. Alternatively, there are times when a heavyweight methodology may be appropriate for super projects where it is necessary to gain stricter control and coordination between phases, and to improve the lines of communication between team members.

Any project with a team larger than 10 to 20 people who work in multiple locations may be a good candidate for a heavyweight methodology. Many companies are simply rushing to try to come up with the biggest and best methodology including the most templates. Many, expecting miraculous results, become disappointed after a few months of actual project work. Because technologies are becoming more complex and integrated facing many design and development problems heavyweight methodologies can sometimes be the best choice, especially when multiple teams are working at different locations and when tighter control and formalization of key parts of the project is necessary.



Demystifying Iterative Development

Project managers or developers often confuse the meaning or use of the terms incremental, evolutionary, or iterative. Incremental, iterative, and evolutionary development are in fact the same thing. They execute all project phases (i.e., design, build) more than once. Whereas linear development (i.e., SDLC) is not. On any project, team members must understand the difference in these terms because they can define the future course of the methodology being selected or proposed on the next project. Iterative development adds agility to your project. For example, if you start a project and the executive sponsor informs you to follow an iterative approach, would you know what the sponsor meant? The following analogy best describes the differences in terminology:

Iterative. When building a house, the first iteration of the house is torn down, redesigned, and the second iteration is built from scratch. The emphasis is on re-doing the project. In the construction industry, this can be impractical and expensive; but in the information technology industry, this approach is common.

Incremental. When building a house, we start off with a basic design, and then incrementally add more rooms to the house. The emphasis is on adding to the project or expanding it. In addition, incremental models are best used to do a phased delivery to clients (e.g., release 1, release 2). This approach is more orientated to formal projects such as construction projects; information technology projects also use this approach as a dynamic way of delivering projects to clients.

The main difference between the iterative and incremental approaches is that you can still live with the incrementally built house, but the iterative house that has been torn down needs rebuilding.

Benefits of Iterative Development

The iterative development methodology provides the following benefits:

It encourages user feedback, which promotes obtaining real user requirements.

The system grows by adding new functions to each iteration.

Developers or planners start focusing on the biggest issues or risks facing the project.

Any misconceptions about design and requirements are identified upfront.



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 [ 34 ] 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101