Examination questions on discipline planning and management in the development of information systems

EXAMINATION QUESTIONS ON DISCIPLINE "PLANNING AND MANAGEMENT In the development of information systems "

1 MSF-модель команды. MSF-группы представителей и их миссии.

1 MSF-team model. MSF-group representatives and their mission

MSF-модель команды – команда представителей

MSF-модель команды описывает подход к структурированию организаций, команд, отдельных сотрудников и видов деятельности в направлении максимальных показателей качества, производительности и вероятности успеха проекта. Она определяет взаимозависимые разноплановые роли и их обязанности, цели и виды деятельности в контексте основных принципов и установок (таких как команда равных).

MSF-модель команды основывается на утверждении о равенстве ролей в команде. В то же время для успеха проекта заказчики и другие заинтересованные стороны должны иметь единственный официальный источник информации о состоянии проекта, осуществляемых мероприятиях и текущих ошибках. Для разрешения этой дилеммы MSF-модель команды сочетает строгую отчетность перед различными заинтересованными сторонами с общей ответственностью команды за успех проекта в целом.

MSF-модель команды вероятно является самой главной отличительной чертой MSF. В основе этой модели лежит идея о том что проекты должны объединять противоречащие друг другу и часто не связанные между собой взгляды различных заинтересованных сторон, в том числе исполнителей, бизнеса и пользователей. MSF-модель команды стимулирует интеграцию разнообразных идей таким образом, чтобы проекты и структуры команд оставались достаточно гибкими. С одной стороны это поддерживает многообразие идей, а с другой – дает возможность командам самостоятельно организовывать себя, стимулирую инновации, идущие от этих идей.

КОМАНДА ПРЕДСТАВИТЕЛЕЙ

В соответствии с установкой о равенстве членов команды MSF-модель команды формируется на представлении интересов. Проектная команда и ее представители разбиваются на семь групп называемых группами представителей. Каждая группа представителей как показано в таблице 4.1 и на рисунке 4.1 j, обеспечивает достижение нескольких дополняющих друг друга (а иногда и противоречащих друг другу) аспектов совместной работы по поставке решения. Эти группы представляют в команде интересы соответствующих внешних групп (то есть группа представителей осуществляет двустороннее представительство). Суть этой модели заключается в том, что каждый член группы является представителем самого себя, отстаивая свои взгляды на качественные показатели, представителем соответствующих заинтересованных сторон (его электората) и представителем сферы своей деятельности внутри организации (например подразделения маркетинга).

Управление продуктом	Определение решения. Описание решения должно максимально точно соответствовать требованиям и ожиданиям заинтересованных сторон.
Управление программой	Поставка решения. Руководство проектом должно максимально точно соответствовать всем требованиям и ожиданиям спонсоров.
Архитектура	Проектирование решения. Дизайн решения должен максимально точно соответствовать всем требованиям и ожиданиям.
Разработка	Разработка решения. Решение должно максимально точно соответствовать дизайну Верификация решения. Решение должно работать согласно спецификации.
Тестирование	Аттестация решения. Решение должно работать согласно спецификации.
Удовлетворение пользователя	Практичность решения. Решение должно быть удобным для пользователей и обеспечивать эффективное продуктивное и квалифицированное его удовлетворение. Готовность пользователей. Пользователи должны быть достаточно подготовлены для эксплуатации решения.
Выпуск/эксплуатация	Развёртывание решения. Решение должно развертываться без проблем и наилучшим образом интегрироваться в целевую среду (целевые среды).

Хотя рисунок 4. 1 иллюстрирует модель команды лишь логическим и вовсе не является уставом организации, актуальной остается трудноразрешимая задача. – создать команду с адаптирующейся, масштабируемой и гибкой структурой, которая позволила бы членам команды отстаивать интересы того, кого они представляют, а они представляют

Качественные показатели

Заинтересованные стороны

Сферы деятельности

В следующих разделах описаны эти аспекты, а также то, как с группами представителей соотносятся роли. Затем каждая группа представителей рассмотрена подробно.

MSF-team model - a team of representatives

MSF-team model describes an approach to structuring organizations, teams, individual staff and activities in the direction of maximum performance quality, performance and likelihood of success of the project. It defines the interdependent diverse roles and responsibilities, objectives and activities in the context of basic principles and guidelines (such as equal team).

MSF-team model is based on the assertion of the equality of roles within the team. At the same time, the success of the project, customers and other stakeholders should be the only official source of information on the status of the project is underway and the current error. To resolve this dilemma, MSF-team model combines rigorous reporting to various stakeholders with overall responsibility for the success of the project team as a whole.

MSF-team model is probably the most important distinguishing feature of MSF. This model is based on the idea that the projects should combine conflicting and often unrelated views of different stakeholders, including artists, businesses and users. MSF-team model promotes the integration of a variety of ideas so that projects and command structure remained fairly flexible. On the one hand it supports the diversity of ideas, and on the other - makes it possible for teams to independently organize themselves, stimulate innovation coming from these ideas.

TEAM OF REPRESENTATIVES

In accordance with the installation of the equality of the team members MSF-team model is formed on the representation of interests. The project team and its representatives are divided into seven groups called groups representatives. Each group representatives as shown in Table 4.1 and Figure 4.1 j, achieves several complementary (and sometimes contradictory) aspects of working together to deliver solutions. These groups represent the interests of the team outside groups (ie, a group of representatives has bilateral representation). The essence of this model is that each team member is a representative of himself, defending his views on quality indicators, representatives of relevant stakeholders (his constituency) and a representative of the scope of its activities within the organization (eg the marketing department).

Definition of product management solutions. Description of the solution should be as accurate as possible comply with the requirements and expectations of stakeholders.

Supply Program Management solutions. Project management should be as accurate as possible to meet all the requirements and expectations of sponsors.

Architecture design solutions. Design solutions must be as accurate as possible to meet all requirements and expectations.

Elaboration solutions. Solution should correspond as closely as possible the design

Verification solutions. Solution should work according to specification.

Certification testing solutions. Solution should work according to specification.

User satisfaction with practical solutions. The decision should be user-friendly and to ensure effective and productive qualified his satisfaction. The willingness of users. Users should be well prepared for the operation of the decision.

Issue / operation Deploying solutions. The decision should be deployed without any problems and the best way to integrate into the target environment (target environment).

Although Figure 4. Figure 1 illustrates a logical model of command and is not a charter of the organization, the actual remains intractable. - To create a team with adaptable, scalable and flexible structure that would allow the team members to defend the interests of the people they represent, and they are

qualitative indicators

parties concerned

Fields of activity

The following sections describe these aspects, as well as how groups relate to the role of representatives. Then each group representatives discussed in detail.

2 MSF-процесс управления рисками. Этап «Планирование и составления графика обработки рисков».

2 MSF-risk management process. Step "Planning and scheduling processing risks."

MSF- процесс управления рисками

Как уже обсуждалось ранее в данной главе управление рисками в MSF предполагает наличие двух вещей: процесса управления рисками и дисциплины позволяющей использовать этот процесс эффективно действенно систематически и воспроизводимо. В данном разделе рассказывается о том как все это объединить вместе в одном процессе обеспечивающем превентивное управление рисками, непрерывную оценку имеющихся рисков и учет этих рисков при выборе вариантов действий на протяжении всего жизненного цикла проекта или функционального процесса. С рисками ведется непрерывная и активная работа до тех пор пока они либо сойдут на нет либо реализуются превратившись в ошибки с которыми придется столкнуться команде.

Хотя в основе MSF- процесса управления рисками лежит хорошо известная модель процесса постоянного управления рисками, разработанная институтом организации программирования для рисков в технических проектах, MSF предлагает при использовании данной модели учитывать опыт экстенсивных разработок продукции Microsoft, а также опыт разработки и представления проектов программного обеспечения консультационных служб Microsoft и партнеров Microsoft.

MSF- процесс управления рисками состоит из шести этапов.

1 Выявление рисков. Этап выявления рисков позволяет специалистам вывести риски на нет и таким образом сообщить команде о наличии потенциальных проблем. В качестве начальной фазы процесса управления рисками выявление рисков должно быть выполнено как можно раньше и постоянно повторяться на протяжении всего жизненного цикла проекта.

2 Анализ рисков и их расстановка по приоритетам. В ходе анализа рисков оценка или данные полученные в ходе выявления рисков преобразуются в форму позволяющую команде расставить риски по приоритетам. Расстановка рисков по приоритетам дает команде возможность выделить ресурсы, необходимые для управления наиболее важными из рисков.

3 План и график обработки рисков. В ходе планирования обработки рисков информация, полученная на этапе их анализа, используется для выработки стратегии, планов и мероприятий. Путем составления графика обработки рисков гарантируется, что эти планы будут приняты и станут частью повседневного процесса управления проектом и его инфраструктуры, что обеспечит включения процесса управления рисками в повседневную деятельность команды. Благодаря графику обработки рисков планы обработки рисков напрямую увязываются с планом проекта.

4 Мониторинг рисков и информирование о состоянии рисков. При мониторинге рисков выполняется отслеживание конкретных рисков и их развития в соответствии с планами мероприятий. К мониторингу рисков относится также отслеживание вероятности влияния и опасности рисков, а также прочих факторов способных сказаться на приоритетах рисков и планах их обработки, а также на технических характеристиках, ресурсах и графике всего проекта. Мониторинг рисков позволяет видеть процесс управления проектными рисками с позиции рисков в противоположность позиции стандартного процесса функционального управления проектом, в котором учитывается только завершенность заданий. Информирование о рисках гарантирует, что команда спонсоры и другие заинтересованные стороны получат информацию о состоянии проектных рисков и планах по управлению этими рисками.

5 Контроль рисков. Контроль рисков. Подразумевает деятельность по предупреждению рисков в ходе которой происходит исполнение принятых в отношении рисков планов мероприятий и предоставление соответствующей информации. К процессу контроля рисков относится также инициирование проектных изменений, если изменение состояния или планов обработки рисков может стать причиной соответствующего изменения технических характеристик, ресурсов или графика всего проекта.

6 Изучение рисков. При изучении рисков полученные за время работы над проектом уроки и встреченные артефакты формализуются в знания для последующего многократного использования как внутри команды так и на уровне организации.

MSF- risk management process

As discussed earlier in this chapter in MSF risk management requires two things: the risk management process and discipline makes this process efficiently and effectively systematically reproducible. This section describes how to combine it all together in one process provides for preventive risk management, continuous assessment of the risks involved and take these risks when choosing options throughout the life cycle of a project or functional process. With risk being continuous and active work until they either come to naught or implemented turned into errors that will face the team.

Although based MSF- risk management process is a well-known model of continuous risk management, developed by Institute for programming risks in technical projects, MSF offers the use of this model to take into account the experience of extensive product development Microsoft, and experience in the development and presentation software projects consulting Microsoft Services and partners Microsoft.

MSF- risk management process consists of six steps.

1 Identification of risks. Stage risk identification allows experts to bring to naught the risks and thus to inform the team about potential problems. As the initial phase of the risk management process risk identification should be done as early as possible and constantly repeated throughout the project life cycle.

2 Analysis of risks and their placement on the priorities. The analysis of risk assessment or data obtained in the course of identifying risks converted into a form which allows the team to place risks on priorities. The alignment of risks prioritized gives the team the opportunity to commit the resources necessary to manage the most important risks.

3 Plan and schedule risk treatment. During the planning risk treatment information obtained at the stage of analysis is used to develop the strategy, plans and activities. By plotting the treatment of risks to ensure that such plans will be adopted and become part of the routine management of the project and its infrastructure, which will ensure the inclusion of risk management in the daily work of the team. Due to the schedule risk treatment plans for risk treatment directly linked to the project plan.

4 Risk monitoring and reporting on the status of risks. When monitoring is carried out monitoring of risks specific risks and their development in accordance with the Action Plan. By monitoring the risk is also monitoring the impact and probability of hazard risks and other factors can affect the risk priorities and plans for their treatment, as well as technical characteristics, resources and schedule of the project. Risk monitoring allows you to see the process of project risk management from the perspective of risk as opposed to the standard position of the functional project management process, which takes into account only the job is complete. Risk communication ensures that the team sponsors and other interested parties will receive information about the status of project risks and plans to manage these risks.

5 Risk control. Risk control. Involves activities to prevent risks in the course of which the execution taken against the risks of action plans and the provision of relevant information. By the process of risk control is also initiating design changes if the change in status or risk treatment plan may result in a corresponding change in the technical characteristics, resources and schedule of the project.

6 The study of risks. In the study of the risk of while working on the project and lessons encountered artifacts formalized in knowledge for subsequent reuse within the team and at the level of the organization.

3 Основные направления в MSF-модели руководства. Жизненный цикл поставки решений согласно Microsoft.

3 Trends in MSF-management model. Delivery lifecycle solutions, according to Microsoft.

4 Треугольник и матрица компромиссов MSF-проекта.

4 Triangle matrix compromises MSF-project

5 Главные и промежуточные контрольные точки.

5 Main and intermediate control points.

6 Графическое представление методологии Scrum

6 Graphical representation of Scrum

Резерв проекта: documentacion del proyecto/ requisites de la operacion

Резерв спринта:sprint (iteraciones) backlog (tareas)

7 Определение Скрама. Цель Скрама.

7 Determination of Scrum. The purpose of Scrum.

Скрам – это подход, структурированный для поддержки разработки сложных продуктов. Скрам состоит из Скрам Команд, внутри которых распределены соответствующие роли, а также мероприятий, артефактов и правил. Каждый компонент Скрама имеет свое предназначение и является неотъемлемым для успеха и использования Скрама.

Правила Скрама связывают мероприятия, роли и артефакты, регулируя отношения и взаимодействие между ними. Правила Скрама прописываются в данном документе.

Цель Руководства по Скраму

Скрам (Scrum) – это подход для разработки и поддержки функционально сложных продуктов. Данное руководство содержит определение Скрама. Определение включает в себя описание ролей, мероприятий и артефактов Скрама, а также правил, обеспечивающих связь между ними. Кен Швабер и Джефф Сазерленд разработали Скрам; руководство по Скраму написано и представлено ими. Они являются основателями данного руководства по Скраму.

Scrum - this approach is structured to support the development of complex products. Scrum Team consists of Scrum within which distributed the respective roles and activities, artifacts and regulations. Each component Scrum has its purpose and is integral to the success and use of Scrum.

Scrum rules associated activities, roles and artifacts, regulating the relationship and interaction between them. Scrum rules prescribed herein.

The purpose of the Guide to Scrum

Scrum (Scrum) - an approach for the development and support of complex functional foods. This guide contains the definition of Scrum. The definition includes a description of the roles, activities and artifacts Scrum, as well as rules to ensure the connection between them. Ken Schwaber and Jeff Sutherland developed Scrum; Scrum Guide is written and presented by them. They are the founders of this manual for Scrum.

8 Артефакты Скрама: Журнал спринта, Журнал продукта, Инкремент

8 Scrum Artifacts: Journal sprint Magazine product increment

Артефакты Скрама

Артефакты Скрама предоставляются в качестве работы или ценности того, насколько они полезны в обеспечении прозрачности и возможностей для инспекции и адаптации. Определенные Скрамом Артефакты специально спроектированы таким образом, чтобы обеспечить максимальную ясность ключевой информации, необходимой для того, чтобы Скрам Команда достигла успеха в поставке “готового” Инкремента.

Журнал Продукта – это упорядоченный список всего, что может быть нужным в продукте, он является единственным источником требований для любых изменений, которые может потребоваться внести в продукт. Ответственность за Журнал Продукта несет Владелец Продукта, включая его содержание, доступность и упорядочение.

Журнал Продукта никогда не является полным. Начальная версия этого документа содержит только первоначально известные и наиболее понятные требования. Журнал Продукта постоянно обновляется по мере обновления самого продукта и среды, в которой он разрабатывается. То есть Журнал Продукта является динамическим, постоянно изменяющимся для соответствия требованиям продукта, его конкурентоспособности и пригодности. Журнал Продукта существует ровно столько, сколько существует и сам продукт.

Журнал Продукта содержит все свойства, функции, требования, усовершенствования и информацию по исправлению дефектов, то есть те данные, которые и определяют изменения и которые нужно сделать в следующих выпуска продукта. Элементам Журнала Продукта должно присваиваться короткое описание, порядковый номер и оценка объемов работы.

В Журнале Продукта требования часто упорядочены по ценности, риску, приоритетности и необходимости. Наиболее важные требования обрабатываются в первую очередь. Чем выше приоритет требования и чем сильнее потребность в его разработке, тем больше согласованности должно быть по поводу этого требования и его значимости.

Элементы Журнала Продукта с высоким уровнем приоритетности должны быть более понятными и содержать больше деталей, чем менее приоритетные. Более точно можно рассчитать время работы над теми требованиями, которые являются более понятными и содержат больше дополнительной информации. Чем ниже приоритетность, тем меньше деталей. Те требования Журнала Продукта, над которыми Команда Разработчиков будет работать во время текущего Спринта, являются детализированными и разбитыми на части таким образом, что любое из этих требований может быть выполнено и “готово” в рамках одного Спринта. Требования Журнала Продукта, которые можно выполнить и “завершить” в течение одного Спринта считаются “готовыми” и “выполняемыми” для того, чтобы их внесли в план во время следующего Планирования Спринта.

Как только продукт начинает использоваться, его значение возрастает и вызывает ответную реакцию рынка, его Журнал становится более полным и всеобъемлющим. Требования к продукту постоянно изменяются, и поэтому Журнал Продукта – это живой артефакт. Изменения в сфере требований, рыночных условий, технологий и ресурсов приводят также и к изменению Журнала Продукта.

Довольно часто случается так, что над одним продуктом работают несколько Команд. Но всё равно используется только один Журнал Продукта, чтобы определить работу на ближайший период. При этом к элементам Журнала Продукта вводится дополнительный атрибут, позволяющий сгруппировать запросы по Скрам Командам.

Поддержание Журнала Продукта – это деятельность по добавлению деталей, оценок предполагаемых затрат времени, и упорядочивания элементов. Это непрерывный процесс, во время которого Владелец Продукта и Команда Разработчиков детализируют требования Журнала Продукта. Во время обработки требования проверяются и пересматриваются. Однако Владелец Продукта в любое время может изменить статус этих требований.

Поддержание Журнала Продукта – это часть деятельности во время Спринта, исполняемой Владельцем Продукта и Командой Разработчиков. Часто Команды Разработчиков владеют знаниями в нужной области и сами могут осуществить обработку требований. Как и когда сделать обработку требований решает только Скрам Команда. Обработка требований обычно занимает не более 10% времени Скрам Команды.

Команда Разработчиков несет всю ответственность за оценку объемов работы. Владелец Продукта может помочь Команде осмыслить требования и выбрать альтернативы, но конечная оценка зависит только от Команды.

Отслеживание прогресса на пути к Цели

В любое время можно подытожить количество работы, которую осталось проделать для достижения Цели. Владелец Продукта отслеживает оставшееся количество работы, как минимум, для каждого Обзора Спринта. Владелец Продукта сравнивает текущее количество работы с тем, которое оставалось во время предыдущего Обзора Спринта, чтобы оценить прогресс в работе и то, успевает ли Команда достичь Цели в рамках запланированного времени. Эта информация является доступной и открытой для всех заинтересованных лиц.

Скрам не принимает во внимание время, потраченное на работу над требованиями Журнала Продукта. Единственными ценными показателями являются оставшееся количество работы и конечный срок завершения работы.

Различные графики типа “сколько осталось ”(burndown) и “сколько сделано ”(burnup), отображающие реальное продвижение, отклонение, и ожидаемое движение, а также другие наглядные практики используются для предсказания прогресса. Эффективность этих практик проверена. Однако их использование не заменяет важности использования принципов эмпиризма. В сложной среде очень трудно предсказать, как будут развиваться события. Единственное на что можно положиться при принятии решений о будущей работе, это опыт прошлого.

Журнал Спринта – это набор элементов из Журнала Продукта, выбранных для выполнения в текущем Спринте, а также план разработки Инкремента продукта и достижения Цели Спринта. Журнал Спринта – это прогноз Команды Разработчиков о функциональности, которая будет частью следующего Инкремента, а также работы, которую необходимо для этого выполнить.

Журнал Спринта определяет объем работы, которую Команда Разработчиков должна выполнить, чтобы превратить Журнал Продукта в “готовый” Инкремент. Журнал Спринта визуализирует ту работу, которую Команда Разработчиков считает необходимой для достижения Цели Спринта.

Журнал Спринта это достаточно детализированный план, чтобы прогресс в его воплощении можно было увидеть на каждом Ежедневном Скраме. Команда Разработчиков вносит изменения в Журнал Спринта на протяжении всего Спринта, и, соответственно, Журнал Спринта постоянно изменяется. Такие изменения происходят потому, что в процессе работы Команда Разработчиков узнает все новые и новые детали о работе, которую нужно выполнить для достижения Цели Спринта.

Если возникает необходимость в дополнительном объеме работы, Команда Разработчиков добавляет ее в Журнал Спринта. Когда же работы выполнены, оценки оставшегося объема работы обновляются. Если некоторые пункты плана считаются уже неактуальными, то их попросту удаляют. Только Команда Разработчиков может изменять свой Журнал Спринта во время Спринта. Журнал Спринта является наиболее наглядным документом, показывающим реальную картину работы, которую Команда Разработчиков планирует завершить до окончания Спринта, и он принадлежит исключительно Команде Разработчиков.

Отслеживание прогресса Спринта

В любое время во время Спринта можно подытожить количество работы, оставшейся в Журнале Спринта. Команда Разработчиков отслеживает оставшееся количество работы, как минимум, во время каждого Ежедневного Скрама. Команда Разработчиков ежедневно отслеживает количество оставшейся работы и вероятность достижения Цели Спринта. Благодаря отслеживанию количества оставшейся работы во время Спринта Команда Разработчиков может управлять прогрессом.

Скрам не принимает во внимание время, потраченное на работу над элементами Журнала Спринта. Единственными ценными показателями являются оставшееся количество работы и конечный срок завершения работы.

Инкремент – это сумма всех выполненных требований Журнала Продукта реализованных во время текущего Спринта и всех предыдущих Спринтов. По окончанию Спринта новый Инкремент должен быть «Готовым», то есть он должен быть пригодным к эксплуатации и отвечать определению Скрам Команды понятия “Готовности”. Несмотря на решение Владельца Продукта выпускать

Scrum artifacts

Scrum artifacts are provided as work or the value of how they are useful in ensuring transparency and opportunities for inspection and adaptation. Certain Scrum Artifacts specially designed so as to maximize the clarity of the key information needed to Scrum team has succeeded in delivering a "ready" Increment.

Journal of Product - an ordered list of all that can be desired in the product, it is the sole source requirements for any changes that may be required to make a product. Responsibility for the Journal of Product Owner is the Product, including its contents, availability and ordering.

Magazine Product is never complete. The initial version of this document contains only the initially known and most understandable requirements. Magazine Product is continually updated as updates of the product itself and the environment in which it is developed. Ie Magazine Product is dynamic, constantly changing to meet the requirements of the product, its competitiveness and fitness. Journal of the product exists only as long as there is the product itself.

Journal of Product contains all the features, functions, requirements, improvements and information on the correction of defects, ie the data that determine the changes and you need to do in the next release of the product. Product log items must be assigned a short description, serial number and estimate the amount of work.

In the Journal of Product requirements are often ordered by the values at risk, priority and need. The most important requirements are processed first. The higher the priority requirements and the stronger demand for its development, the more consistency should be relating to this requirement and its significance.

Elements of the Journal of products with a high level of priority should be more clear and contain more detail than the lower priority. More precisely, we can calculate the work on the requirements that are more understandable and contain much additional information. The lower priority, the fewer parts. The demands of the Journal of the Product on which Development Team will work during the current Sprint, are detailed and broken into pieces in such a way that any of these requirements can be met and "ready" within one Sprint. Requirements of the Journal of products that can be done and "complete" within one Sprint are considered "ready" and "performed" in order to be made to the plan during the next sprint planning.

Once the product is first used, its value increases and causes a reaction of the market, its magazine becomes more complete and comprehensive. Product requirements are constantly changing and therefore Magazine Product - a living artifact. Changes in requirements, market conditions, technology and resources also lead to a change in the Journal of Product.

Quite often it happens that one product has several Team. But still only one magazine products to determine the work for the next period. In this case, the elements of the Journal of Product introduce additional attribute allows you to group requests for Scrum teams.

Maintaining Product Magazine - an activity to add details, estimates of the expected expenditures of time and organize your items. It is a continuous process, during which the owner of the Product Development Team and detail the requirements of the Journal of Product. During processing requirements are reviewed and revised. However, the Product Owner may at any time change the status of these requirements.

Journal of maintaining product - it's part of the activities during the sprint, executable product owner and development team. Often, the development team have knowledge in the desired area and may themselves carry out the processing of claims. How and when do the treatment requirements solves the Scrum Team. Processing requirements typically takes no more than 10% of the time Scrum Teams.

Development team has overall responsibility for assessing the amount of work. The product owner can help the team understand the requirements and choose alternatives, but the final score depends on the command.

Tracking progress towards the Goals

At any time you can summarize the amount of work that remains to be done to achieve the goal. Product Owner tracks the remaining quantity of work, at least for every Sprint Review. Product Owner compares the current amount of work with that was during the previous review Sprint to assess the progress of the work and what time to achieve the objectives of the team as part of the scheduled time. This information is accessible and open to all interested persons.

Scrum does not take into account the time spent working on the requirements of the Journal of Product. The only valuable indicators are the remaining amount of work and the deadline for completion of the work.

Different types of graphics "how much is left" (burndown) and "how much is done" (burnup), showing real progress, deviation and expected movement, and other visual practices used to predict progress. The effectiveness of these practices verified. However, their use does not replace the importance of using the principles of empiricism. In a complex environment is very difficult to predict how events will unfold. The only thing that can be relied on when making decisions about future work, it is the experience of the past.

Journal Sprint - a collection of items from the Journal of products selected to perform in the current sprint, and a plan to develop the product and Increment Goal Sprint. Sprint magazine - it is a forecast of the development team of the functionality that will be part of the next increment, as well as the work that is needed to perform this.

Journal Sprint determines the amount of work that the development team must perform to turn Product Magazine in the "ready" increment. Journal Sprint visualizes the work that Development Team deems necessary to achieve the objectives of the Sprint.

Journal Sprint is quite detailed plan to progress in his incarnation can be seen on each daily Scrum. Development team makes changes to the Journal throughout the Sprint Sprint, and accordingly Journal Sprint is constantly changing. These changes occur because during operation Development Team finds more and more details about the work to be performed to achieve the objectives of the Sprint.

If there is a need for additional work, the team adds it to the Sprint Magazine. When the work has been completed, estimating the remaining workload updated. If some points of the plan are considered to be already outdated, they are simply removed. Only the team can change its Sprint Journal during the Sprint. Journal Sprint is the most visible document showing the real picture of the work that Development Team plans to complete before the end of the Sprint, and it belongs exclusively to the development team.

Tracking progress Sprint

At any time during the sprint can be summarized as the amount of work remaining in the Journal of the Sprint. Development Team monitors the remaining amount of work, at least during each daily Scrum. Development team daily tracks the number of remaining work and the probability of achieving the objectives of the Sprint. By tracking the number of outstanding work during the sprint team can monitor progress.

Scrum does not take into account the time spent working on the elements of the Journal of Sprint. The only valuable indicators are the remaining amount of work and the deadline for completion of the work.

Increment - the sum of all demands made of the Journal of Product sold during the current Sprint and all previous Sprints. At the end of the new Sprint increment must be "ready", ie it must be fit for use and meet the definition of Scrum Teams concept of "readiness". Despite the decision to release the product owner

9 Мероприятия Скрама: Спринт, Ежедневные скрамы, Планирование спринта, Обзор и Ретроспектива спринта

9 Events Scrum: Sprint, Daily Scrum, Sprint Planning, Sprint Review and Retrospective

Ежедневные Скрамы – это 15-минутные совещания для Команды Разработчиков с целью синхронизации действий и создания плана работы на ближайшие 24 часа. Это делается для того, чтобы проверить, что нового было сделано со времени проведения прошлого Ежедневного Скрама и спланировать работу, которую можно успеть сделать за следующие 24 часа.

Эти совещания происходят в обусловленном месте в одно и то же время во избежание путаницы. Во время таких совещаний каждый участник Команды Разработчиков рассказывает коллегам о следующем:

 Что было сделано со времени прошлой встречи?

 Что планируется сделать до следующей встречи?

 Что ему мешает в выполнении запланированных заданий?

Члены Команды Разработчиков используют Ежедневные Скрамы для оценки прогресса продвижения к Цели Спринта, а для оценки отклонения от планируемого завершения работ из Журнала Спринта. Ежедневные Скрамы усиливают вероятность того, что Команда Разработчиков достигнет Цели Спринта. Часто Команда Разработчиков встречается сразу же после Ежедневного Скрама для перепланирования оставшейся работы по Спринту. Ежедневно Команда Разработчиков должна быть в состоянии объяснить Владельцу Продукта и Скрам Мастеру как она намеревается работать в качестве самоуправляемой Команды для достижения цели и создания ожидаемого инкремента продукта за время, оставшееся до окончания Спринта.

Скрам Мастер ответственен за то, чтобы Команда Разработчиков не пропускала такие совещания, однако ответственность за проведение Ежедневного Скрама лежит на Команде Разработчиков. Скрам Мастер обучает Команду Разработчиков удерживать время проведения Ежедневного Скрама в границах не более 15 минут.

Скрам Мастер обеспечивает соблюдение того, чтобы участвовали в Ежедневных Скрамах только члены Команды Разработчиков. Ежедневный Скрам не является статус-совещанием, а скорее совещанием для членов Команды, работающей над превращением требований из Журнала Продукта в Инкремент готового продукта.

Ежедневные Скрамы улучшают процесс общения внутри Команды, сводя к минимуму другие совещания, помогают определять и устранять препятствия на пути к успешной работе, способствуют быстрому принятию решений, а также повышают знания по проекту Команды Разработчиков. Эти совещания являются ключевыми для проверки и адаптации.

Обзор Спринта

Встреча по Обзору Спринта проводится в конце Спринта для проверки Инкремента и, при необходимости, адаптации Журнала Продукта. Во время Обзора Спринта Скрам Команда и заинтересованные лица обсуждают уже выполненную во время Спринта работу. Принимая во внимание качество проделанной работы, а также изменения, которые могли возникнуть в Журнале Продукта за время Спринта, присутствующие обсуждают последующие задания. Это не официальная встреча, а скорее презентация Инкремента, предназначенная для получения отзыва и оптимизации сотрудничества.

Для Спринта длиной в месяц это четырехчасовое совещание. Для более коротких Спринтов на Обзор Спринта тратят меньше времени, что пропорционально общей длине Спринта. К примеру, для двухнедельных Спринтов длительность Обзора Спринта составляет два часа.

Обзор Спринта включает в себя следующие элементы:

 Владелец Продукта определяет, что является “готовым”, а что нет;

 Команда Разработчиков вспоминает, что прошло гладко во время Спринта и с чем возникли трудности, а также то, как она с ними справилась;

 Команда Разработчиков проводит демонстрацию того, что было сделано, и отвечает на вопросы по Инкременту;

 Владелец Продукта обсуждает состояние Журнала Продукта. Он делает предположения касательно возможной даты окончания проекта, принимая во внимание скорость продвижения работы над ним;

 Вся Команда принимается за обсуждение того, что делать в дальнейшем, для того чтобы данный Обзор Спринта предоставлял важную входную информацию для последующей встречи по планирования Спринта.

Результатом Обзора Спринта является пересмотренный и исправленный Журнал Продукта, определяющий вероятные элементы Журнала Продукта для следующего Спринта. Журнал Продукта может также быть пересмотрен для того, чтобы соответствовать новым обстоятельствам.

Ретроспектива Спринта

Ретроспектива Спринта дает Скрам Команде возможность проверить себя и создать план улучшений, которые можно было бы внести во время следующего Спринта.

Ретроспектива Спринта происходит после Обзора Спринта, перед последующим Планированием Спринта. Это ограниченное тремя часами собрание для одномесячного Спринта. Для более коротких Спринтов необходимо выделить меньше времени, пропорционально длине Спринта.

Целью Ретроспективы Спринта является:

 Проверка того, насколько успешно прошел Спринт, учитывая слаженность Команды, процессы и использованные инструменты;

 Определение и упорядочение тех элементов работы, которые прошли успешно, и тех, которые могли бы быть сделаны лучше;

 Разработка плана по внедрению улучшений в процесс работы Скрам Команды.

Скрам Мастер поощряет Скрам Команду пересмотреть свои процессы разработки в рамках процессов и практик Скрама, чтобы сделать её более эффективной в следующем Спринте. Во время каждой Ретроспективы Спринта Скрам Команда ищет пути улучшения качества разрабатываемого продукта, при необходимости уточняя определение “Готовности”.

До окончания Ретроспективы Скрам Команда должна определить практичные и действенные факторы улучшения процесса работы, которые она реализует в следующем Спринте. Внедрение этих изменений в следующем Спринте как раз и является адаптацией к проверке самой Скрам Команды. Хотя изменения могут быть внесены в любое время, Ретроспектива Спринта является специализированным совещанием, посвященным исключительно проверке и адаптации.

Daily Scrum - a 15-minute meeting, the development team in order to synchronize and to provide a work plan for the next 24 hours. This is done in order to verify that the new has been done since the last Daily Scrum and planning work that can get done in the next 24 hours.

Meeting these occur at the place in the same time to avoid confusion. During these meetings, each member of the development team tells colleagues the following:

 What has been done since the last meeting?

 What do you plan to do before the next meeting?

 What prevents him in a scheduled task?

Team members used daily Scrum to assess progress towards the goal of Sprint, and to assess the deviation from the planned completion of the Journal of Sprint. Daily Scrum increase the likelihood that the team reach the goal of Sprint. Often the Development Team meets immediately after the Daily Scrum to reschedule remaining work for the sprint. Every day, the development team must be able to explain the product owner and Scrum Master how it intends to operate as a self-managing teams to achieve goals and create the expected growth rate of the product for the time remaining until the end of the Sprint.

Scrum Master is responsible for ensuring that the developers have not missed a team such meetings, but the responsibility for conducting the Daily Scrum is on the team. Scrum Master teaches teams of developers to keep the time of the Daily Scrum within the limits of no more than 15 minutes.

Scrum Master enforces order to participate in the daily Scrum, only members of the development team. The Daily Scrum is not a status meeting, but rather a meeting for members of the team working on the transformation of the requirements of the Journal of Product in the increment of the final product.

Daily Scrum improve the process of communication within the team, minimizing other meetings, helping to identify and remove barriers to successful work, promote rapid decision-making, as well as increase the knowledge of the project team. These meetings are crucial for testing and adaptation.

Review of Sprint

Meeting on the Review of Sprint Sprint is held at the end to check the increment and, if necessary, adaptation of the Journal of Product. During the Sprint Review Scrum Team and stakeholders have already been performed during the sprint work. Taking into account the quality of the work done, as well as changes that may have occurred in the Journal of the Product during the Sprint present to discuss follow-up assignments. This is not an official meeting, but rather a presentation of Increment designed for feedback and optimize cooperation.

Sprint for a month-long four-hour meeting it. For shorter sprint Sprint Review spend less time that is proportional to the total length of the Sprint. For example, for a two-week duration of the Sprint Review Sprint is two hours.

Review of Sprint includes the following elements:

 The owner of the product is determined to be a "ready" and what is not;

 Development Team recalls that went smoothly during the Sprint and what difficulties arose and how it coped with them;

 Development Team conducts a demonstration of what has been done and answers questions on the increment;

 Product Owner discusses the state of the Journal of Product. He makes assumptions about the likely date of completion of the project, taking into account the speed of progress of work on it;

 The whole team is taken for a discussion of what to do in the future to this review Sprint provides important input for subsequent planning meeting Sprint.

Sprint Results of the review is a revised and corrected Magazine Product determine the probability of the elements of the Journal of Product for the next Sprint. Product magazine may also be revised to meet the new circumstances.

Sprint Retrospective

Retrospective Scrum Sprint gives teams the opportunity to test yourself and create a plan of improvements that could be made during the next Sprint.

Sprint Retrospective occurs after the Sprint Review, before the next sprint planning. This limited collection of three hours for a one-month sprint. For shorter Sprints necessary to allocate less time proportional to the length of Sprint.

The purpose of the Sprint Retrospective is:

 Check how successfully Sprint, given the well-organized team, processes and tools used;

 Definition and ordering of the elements of work that were successful and those that could be made better;

 Develop a plan for the implementation of improvements in the work process Scrum Teams.

Scrum Master encourages the Scrum Team to revise their development processes within the processes and practices of Scrum, to make it more effective in the next sprint. During each Sprint Retrospectives Scrum team is looking for ways to improve the quality of the developed product, if necessary, to clarify the definition of "readiness."

Before the end of Retrospectives Scrum team should determine practical and effective factors to improve the work process, which it implements in the next Sprint. The introduction of these changes in the next sprint is just an adaptation to the verification of the Scrum Team. Although changes may be made at any time, Sprint Retrospective is a specialized meeting devoted exclusively to inspection and adaptation.

10 Скрам команда: Владелец Продукта, Скрам мастер.

10 Scrum team: Product Owner, Scrum Master.

Владелец Продукта ответственен за достижение максимальной ценности продукта и работы, исполняемой Командой Разработчиков. Способы, которыми он этого достигает, могут отличаться и зависят от организаций, Скрам Команд и индивидуумов.

Владелец Продукта является единственным человеком в Команде, отвечающим за Журнал Требований к Продукту (Product Backlog). Управление Журналом Продукта включает в себя:

 Четкое определение элементов Журнала Продукта;

 Упорядочение элементов Журнала Продукта для оптимизации достижения целей и поставленных задач;

 Ответственность за ценность работы, исполняемой Командой Разработчиков;

 Обеспечение доступности, прозрачности и понятности Журнала Продукта, а также отображения тех требований, над которыми Скрам Команде предстоит работать в ближайшее время.

 Ответственность за понимание Командой Разработчиков требований Журнала Продукта на надлежащем уровне.

Владелец Продукта может либо сам выполнять вышеперечисленные функции, либо предоставить их выполнение членам Команды Разработчиков. Однако подотчетным считается именно Владелец Продукта.

Владелец Продукта это только один человек, а не группа. Владелец Продукта может представлять интересы группы в Журнале Продукта, но желающие изменить приоритетность требований в Журнале Продукта должны в первую очередь убедить в этом Владельца Продукта.

Для успешного выполнения Владельцем Продукта своих обязанностей все члены организации должны уважать его решение. Все решения Владельца Продукта видны через содержимое и упорядочение Журнала Продукта. Никто другой не может заставить Команду Разработчиков работать согласно иным требованиям, да и самой Команде Разработчиков запрещается слушать кого-либо с иным мнением.

The product owner is responsible for maximizing the value of the product and the work executed by the development team. The ways in which it obtains, may vary and depend on the organizations and individuals Scrum Team.

The product owner is the only person in the team responsible for the Journal of Product Requirements (Product Backlog). Log management products include:

 Clear definition of elements of the Journal of the Product;

 Arrange Items Journal optimization products achieve the goals and objectives;

 Responsibility for the value of the work executed by the development team;

 Ensuring accessibility, transparency and comprehensibility of the Journal of Product and display those requirements on which the Scrum team will work in the near future.

 Responsibility for the understanding of the requirements of the development team of the Journal of Product at the appropriate level.

The product owner can either itself perform the above functions, or to provide their implementation team members. However, it is considered to be accountable to the product owner.

The product owner is only one person, not a group. The product owner can represent the interests of the group in the Journal of the product, but who want to change the priority of claims in the Journal of Product must first convince the product owner.

For the successful implementation of the product owner their duties, all members of the organization must respect his decision. All decisions of the owners of the product can be seen through the contents and ordering of the Journal of Product. No one else can make the development team worked according to different requirements, and the team itself is forbidden to listen to someone with a different opinion.

11 Перечислить ценности XP. Ценности «Коммуникация», «Храбрость».

11 lists the value of XP. Value "Communication", "Courage."

Четыре ценности для ХР – это:

• коммуникация (communication);

• простота (simplicity);

• обратная связь (feedback);

• храбрость (courage).

Коммуникация

Первая ценность ХР – это коммуникация. Проблемы, которые возникают в процессе работы

над проектом, почти всегда связаны с тем, что кто-то не сказал кому-то о чем-то важном.

Иногда программист не сообщает кому-то о важном изменении в дизайне. Иногда программист

не задает заказчику важного вопроса, и в результате важное принятое им решение оказывается

неправильным. Иногда менеджер не задает программисту важного вопроса, в результате у него

складывается неполное, а иногда и неправильное представление о состоянии проекта.

Плохая коммуникация – это не случайность. Существует огромное количество предпосылок,

которые ведут к нарушению коммуникации. Например, программист сообщает менеджеру

плохие новости и менеджер наказывает программиста. Заказчик сообщает программисту нечто

важное, а программист делает вид, что не понял или просто проигнорирует эту информацию.

Дисциплина ХР нацелена на обеспечение непрерывной, постоянно осуществляемой

коммуникации между участниками проекта. В рамках ХР используются многие методики,

которые невозможно реализовать без коммуникации. Эти методики направлены на достижение

краткосрочных целей, например, тестирование модулей, программирование парами, а также

оценка сложности задачи. В процессе тестирования, программирования парами и формирования

предварительных оценок программисты, заказчики и менеджеры вынуждены тесно

взаимодействовать.

Это не означает, что излишние разговоры мешают работе. Люди часто попадают в ситуацию,

когда они сомневаются, делают ошибки, отвлекаются. В рамках ХР существует специальное

ответственное лицо – инструктор (coach), в чьи обязанности входит следить за тем, чтобы люди

общались тогда, когда это надо. Если инструктор замечает, что люди перестают общаться, он

стимулирует коммуникацию.

communication

The first value of XP - is communication. Problems that arise in the course of work

the project is almost always due to the fact that someone has not told someone about something important.

Sometimes the programmer does not tell someone about an important change in the design. sometimes a programmer

the customer does not ask the important question, and as a result the importance of his decision is

wrong. Sometimes the manager does not ask the programmer important issue, as a result of his

develops an incomplete and sometimes a misconception about the status of the project.

Poor communication - it is not an accident. There are plenty of preconditions,

which lead to the disruption of communication. For example, the programmer tells the manager

the bad news and the manager punishes programmer. Customer informs the programmer to something

important, but the programmer pretends not to understand or simply ignore this information.

Discipline XP aimed at ensuring a continuous, constantly carried out

communication between the project participants. As part of XP uses many techniques,

which can not be realized without communication. These methods are intended to achieve

short-term goals, such as testing the modules, programming pairs, and

bound for the complexity of the problem. During testing, programming and the formation of pairs

preliminary estimates of programmers, customers and managers are forced to close

interact.

This does not mean that excessive interfere with conversations. People often find themselves in a situation

when they are in doubt, make mistakes, get distracted. As part of XP there is a special

person in charge - instructor (coach), whose job is to ensure that people

communicated when it is necessary. If the instructor observes that people stop to talk, he

stimulates communication.

Храбрость

В контексте первых трех рассмотренных ранее ценностей – коммуникации, простоты и обратной связи – необходимо действовать с максимально возможной скоростью. Если вы работаете со скоростью, которая не является абсолютно максимальной, это будет делать вместо вас кто-то другой, в результате этот кто-то прибежит к финишу первым и съест ваш обед вместо

вас.

Я расскажу вам о том, как храбрость срабатывает в реальной жизни. В середине восьмой итерации включающего в себя 10 итераций рабочего графика (25 из 30 недель) первой версии первого крупного ХР-проекта команда обнаружила фундаментальную ошибку в архитектуре системы. Поначалу функциональные тесты указывали на хорошее качество разрабатываемой системы, однако позже количество набранных нами очков резко снизилось. В результате исправления одного дефекта обнаруживался другой дефект. Количество дефектов

увеличивалось. Проблема была в архитектурном изъяне.

Для любопытных скажу, что мы работали над системой начисления выплат. Для хранения долгов компании перед сотрудниками использовались поля данных с названием Энтитлемент (жалованье), а для хранения долгов сотрудников перед другими людьми использовались поля с названием Deduction (вычет). Для некоторых людей использовалось отрицательное жалованье, в то время как вместо этого надо было использовать положительный вычет.

Команда поступила так, как должна была поступить. Когда все поняли, что путь вперед закрыт, они исправили архитектурный изъян. При этом половина всех используемых в отношении системы тестов перестала срабатывать. Однако в течение нескольких дней напряженных усилий по исправлению ситуации тесты снова начали срабатывать и качество системы, оцениваемое при помощи функциональных тестов, повысилось. Однако для того,

чтобы поступить описанным образом, потребовалась отвага.

Еще один смелый ход – отказ от ранее разработанного кода. Представьте, что в течение всего рабочего дня вы работаете над реализацией некоторой функциональности. Работа идет неплохо, но когда вы близки к ее завершению, компьютер зависает. На следующее утро вы приходите на работу и в течение получаса восстанавливаете то, над чем работали весь предыдущий день, однако на этот раз код получается более чистым и более простым.

Используйте это. Если приближается конец рабочего дня и код все еще не поддается контролю, выбросьте его. Может быть, следует сохранить тестовые случаи, если вам понравился разработанный вами интерфейс. Однако это не обязательно. Возможно, следующим утром будет легче начать с нуля.

Возможно, перед вами три варианта дизайна. Вы можете потратить по одному дню на реализацию каждой из альтернатив для того, чтобы почувствовать, как они будут вести себя на практике. Затем выбросьте код и начните с нуля развивать тот вариант дизайна, который показался вам наиболее многообещающим.

Стратегия проектирования в ХР напоминает алгоритм взбирания на холм (hill climbing). Вы делаете простой дизайн, затем вы делаете его более сложным, далее вы его упрощаете, потом опять усложняете. Проблема подобных алгоритмов состоит в том, что вы ищете локальный оптимум, – при этом никакое незначительное изменение не может улучшить ситуацию, однако улучшения можно достичь, используя значительное изменение.

Достигнув локального оптимума вы, возможно, упускаете более эффективный вариант дизайна. Что поможет вам избежать этого? Как только у кого-нибудь из вашей команды возникает сумасшедшая идея, в результате реализации которой сложность всей системы существенно уменьшится, он обязательно попробует реализовать свою идею, если конечно, у него хватит храбрости. Иногда это срабатывает. Если у вас хватит храбрости, вы приступите к эксплуатации новой версии системы в промышленных условиях. Считайте, что теперь вы забираетесь на совершенно новый холм.

Если у вас нет остальных трех ценностей, храбрость сама по себе является обычным взломом (в самом уничижительном смысле этого слова). Однако в сочетании с коммуникацией, простотой и надежной обратной связью храбрость становится чрезвычайно полезной.

Коммуникация идет на пользу храбрости, так как благодаря коммуникации вы обретаете возможность для осуществления более рискованных и более заманчивых экспериментов. Тебе это не нравится? Я просто ненавижу этот код! Давай вместе посмотрим, в какой мере мы сможем переделать его сегодня днем. Простота идет на пользу храбрости, так как, обладая более простой системой, вы сможете позволить себе более смелые действия в ее отношении.

Маловероятно, что вы нарушите ее функционирование по неизвестным причинам. Храбрость

способствует простоте, ведь как только вы видите способ упростить систему, вы немедленно пробуете его реализовать. Надежная обратная связь идет на пользу храбрости, так как в процессе

серьезной модернизации кода вы чувствуете себя значительно увереннее, если вы можете щелкнуть на кнопке и увидеть, что в результате тестирования все тесты показывают зеленый

цвет. Если зеленым цветом окрашиваются не все тесты, вы переделываете или просто выкидываете свой код.

bravery

In the context of the first three discussed earlier values - communication, simplicity, and feedback - need to act as fast as possible. If you work at a rate that is not absolutely the maximum, this will do for you by someone else, as a result of that someone will come running to the finish line first, and shall eat your lunch instead

you.

I'll tell you about how courage is triggered in real life. In the middle of the eighth iteration includes 10 iterations of working hours (25 out of 30 weeks), the first version of the first major HR project team discovered a fundamental error in the system architecture. At first functional tests indicate good quality of the developed system, but later the number dialed points we have dropped dramatically. As a result, correction of the defect was detected another defect. defects

increased. The problem was in the architectural flaws.

For the curious, I would say that we were working on the charging system of payments. To store the debts of the company to its employees used the data field with the name of Entitlement (salary), and storage employees debts to other people to use a field with the name of Deduction (deduction). For some people use a negative salary, while instead it was necessary to use a positive residue.

The team did what had to do. When everyone realized that the way forward is closed, they fixed architectural flaw. Half of those used for system test fire ceased. However, within a few days of strenuous efforts to remedy the situation again began to fire tests and quality system was assessed using functional tests improved. However, in order

to act in this manner, it took courage.

Another bold move - the rejection of the previously developed code. Imagine that during the working day you are working on implementing some functionality. Work is going well, but when you are close to completion, the computer freezes. The next morning, you go to work for half an hour and restoring something that worked all the previous day, but this time the code is more pure and simple.

Use it. When approaching the end of the working day and the code still can not be controlled, discard it. Maybe to save test cases, if you like interface designed by you. However, this is not necessary. Perhaps, the next morning it will be easier to start from scratch.

Perhaps, before you three design options. You can spend one day on the implementation of each of the alternatives in order to feel how they will behave in practice. Then discard the code and start from scratch to develop the design option, which show you the most promising.

Design strategy in XP reminds algorithm Climbing the hill (hill climbing). You make a simple design, then you make it more complicated, then you simplify it, then again more complicated. The problem of these algorithms is that you are looking for a local optimum, - thus no minor change can not improve the situation, but improvements can be achieved by using a significant change.

Reaching local optimum, you may miss a more efficient version of the design. That will help you avoid this? As soon as someone from your team there is a crazy idea, as a result of which the complexity of the overall system significantly reduced, he must try to realize the idea, unless of course, he had the courage. Sometimes it works. If you have enough courage, you start to operate the new version of the system in an industrial environment. Consider now that you take on a whole new hill.

Дата добавления: 2015-09-29