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

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

Everyone on the project has an accurate snapshot of the project status as it progresses.

Continual testing is carried out during the project.

The project workload is spread more evenly over the life cycle.

It allows for lessons learned on prior versions to be used in future releases.

The project or development manager divides the development/ design schedule into a few iterations (e.g., iterations 1, 2, 3, 4, 5, and 6). Each iteration is one to four weeks. The iterative approach now forms the basis for everything forward. Iterative approaches need to be managed slightly different from a normal project, as each iteration is built on its specific set of user requirements at that time. As iteration 1 is completed and reviewed with the project team and client, another iteration is planned wherein additional requirements and functionality are built into subsequent iterations. Each iteration concentrates on capturing the clients most pressing tasks. Instead of creating a detailed schedule, iterative methodology project planning should be more dynamic each iteration is planned as it comes along, with smaller planning windows.

Ц±кШ=1 1иллл1М1Ы1Д



The Agile Methodologies



Project or development managers are still facing controversy between the agile and heavyweight methodologies. Currently, many companies favor the agile methodologies. Agile methodologies present new, nontraditional ways of building complex products and systems. Projects that use agile methodologies are now starting to report improved time line and cost savings, compared to those in the heavyweight family. Additionally, project teams are hailing the agile family of methodologies as remarkable because, at last, a series of methodologies contributes directly to the business. Many managers (i.e., functional, project, and development) tend to stick with the heavyweight methodology because they want to predict the entire project until the last man-hour, whereas the project teams (i.e., developers, coders, analysts) tend to stick with dynamic shorter cycles. Industries that use agile methodologies include financial, IT, telecom, utilities, and many more service industries. Furthermore, this trend is starting to emerge worldwide. The following are the most commonly used agile methodologies:

Extreme Programming (XP).

Scrum.

Crystal methodology.

Dynamic Systems Development Methodology (DSDM). Rapid Application Development (RAD). Adaptive software development. Lean development. Feature-driven development.

Agile methodologies better suit small projects where smaller project teams are involved. With larger team size and the complexity and duration of the project, the choice of a heavyweight methodology is purely from a command and control perspective. Many smaller companies do not use heavyweight methodologies and prefer the more agile approach to building solutions.



Extreme Programming (XP) Methodology

XP, one of the new promising breeds of lightweight methodologies, is the brainchild of Kent Beck. XP is one of the agile processes. It has received so much attention in recent years that some of the global project organizations are reviewing it for inclusion in their methodology portfolios. XP has few rules and a modest number of best practices, which are all relatively easy to use. It is based on iterations that embody several practices (like RUP), such as small releases, simple design, testing, and continuous integration. XP also promotes several effective techniques for the appropriate projects and circumstances; however, there are hidden assumptions, activities, and roles. XP teams use a simple form of planning and tracking to decide what should be done next and to predict when the project will be finished. XP embraces four core values that its project teams should follow: (1) communication, (2) feedback, (3) simplicity, and (4) courage.

The focus is on business value, where the team produces the software in a series of small, fully integrated releases that pass all the tests the client has defined. An XP project defines an integrated set of practices, which requires the full-time, on-site engagement, for such a project to work successfully. XP concentrates on construction of code programming to meet a business need. How that business need occurs and how it is modeled, captured, or reasoned is not XPs primary concern. The XP phases are for planning purposes but the focus is on actually building the code. There is little emphasis on project documentation XP is a clean and focused environment, which allows developers both creativity and freedom during development. The focus of XP is to reduce development costs. Although XP is worthy of consideration as a development methodology, it should not be used on large projects.

XP is a more constrained process that needs additions to make it fit a complete development project. For a small project team working in a relatively high-trust environment where the user is an integral part of the team, XP can work extremely well. Some of the most noteworthy XP practices are:

Refactoring. Restructure the system continually, without changing its behavior, to make it simpler or add flexibility. Determine if this is a good practice for the team. What is simple to one may be complex to another.

Testing. Developers continually write tests to go along with their code. The tests reflect the stories. XP urges you to write tests first, which is an excellent practice because it forces you to deeply understand the stories and then to ask more questions when necessary. Whether before or after code, you have to write them. Add them to your test suite and make sure to run them every time the code changes.

Pair programming. This technique ensures room for two developers to work effectively at a single workstation. This results in better code in less time, because developers can identify errors and possible faults in the software code (Strengthening the Case 2000).

Use CRC (class, responsibility, and collaboration) cards. This advocates that spending time to capture and maintain design documents is fundamental to a projects success. XP projects typically require a few hours to sketch the design or use CRC cards. The cards are used to teach users of XP the principles of object-orientated design.



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