Принцип № 6. Над проектом должны работать мотивированные профессионалы. чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им .

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

В то же время проекты могут разрушаться в среде, где не ценят ПО или где люди не вознаграждены по заслугам за разработку программного продукта. Нередко компании внедряют проверку производительности и систему компенсации, которые мешают командам двигаться по эффективному, гибкому пути создания ПО, а это может помешать проекту. Вот некоторые распространенные антистимулы, которые работают против agile-команд:

• программистам предоставляется недостаточно подробный анализ эффективности: при анализе кода регулярно повторяются ошибки и им присваивается статус «чистый» код (в результате программисты перестают искать ошибки в анализе кода);

• тестировщиков награждают за количество ошибок, которые они обнаруживают (тем самым поощряются придирки и плохая отчетность, а также нарушается сотрудничество с программистами, потому что это создает антагонистические отношения между ними);

• оценки эффективности бизнес-аналитиков базируются на количестве производимой документации (а не объеме знаний, которыми они поделились с командой).

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

Исчерпывающая документация и матрицы трассируемости – это особенно коварные источники проблем для командной среды и поддержки внутри команды. Вместо обстановки доверия они поощряют CYA-среду (cover your ass, что можно перевести как «каждый спасает свою шкуру»), когда команда двигается в сторону «переговоров по контракту», а не сотрудничества с клиентом.

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

Члены команды программного обеспечения должны бороться каждый за себя там, где негативно относятся к изменениям. Команде, которая использует исчерпывающую документацию, легко понять, что изменения – это плохо: они требуют слишком много работы, чтобы пересмотреть область охвата, обновить спецификации, изменить дизайн, произвести ремонт матрицы трассируемости и т. д. Это приводит к расколу среды, потому что менеджеры в такой компании обычно пытаются найти «виноватого», на которого можно возложить ответственность за все дополнительные работы, вызванные изменениями. Члены команды все чаще обращаются к «оборонительной документации», чтобы защитить себя от незаслуженных обвинений. Это заставляет их применять принцип «каждый за себя»: чтобы избежать критики и наказания, они ссылаются на документацию, которой придерживались.

Альтернатива CYA-среде – доверие. Компания, разрабатывающая только документацию, необходимую для проекта, создает среду, в которой команде доверено делать именно то, что надо, когда происходят изменения. В agile-команде с отношением «мы все вместе» в случае провала проекта все разделяют вину и никто не «прикрывает свой зад». Им проще внедрять изменения, потому что не нужно придерживаться всей этой ненужной документации. Вместо этого они могут работать лицом к лицу, решать реальные проблемы и записывать только необходимое. И они могут делать это, зная, что компания верит, что они сделают все правильно – даже если проект займет больше времени.

<< | >>
Источник: Эндрю Стеллман, Дженнифер Грин. Постигая Agile. Ценности, принципы, методологии. 2015

Еще по теме Принцип № 6. Над проектом должны работать мотивированные профессионалы. чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им .:

  1. Сформируйте у персонала осознание потребности в качест­венной работе и создайте возможность для улучшения качества. 2. Установите цели для постоянного совершенствования дея­тельности. 3. Создайте организацию, которая будет работать над дости­жением целей, выработав условия для определения проблем, вы­бора проектов, сформировав команды и выбрав координаторов. 4. Предоставьте возможность обучения всем сотрудникам организации. 5. Выполняйте проекты для решения проблем. 6. Информируйте сотрудников о
  2. Я понимаю, что тебе будет нелегко найти свободное время для этого проекта, но если бы ты дал своё благословение и стал бы основателем этой организации, это способствовало бы большему доверию к старейшинам в будущем.Я сам обещаю найти время и ресурсы, чтобы оказать негласную организационную поддержку и убедиться в том, что проект создан на благо всего мира и, надо надеяться, будет работать ещё долгие годы.С наилучшими пожеланиями, Ричард
  3. Работа – это нечто, над чем вы работаете, делая что-то. Бизнес – это нечто, над чем вы работаете, создавая что-то.
  4. Организация работы над проектом НИР
  5. Как создать сотрудникам оптимальные условия для работы Как создать оптимальные условия для работы ИСКАТЕЛЮ
  6. Ключевые функции и роль исследователей при работе над проектом
  7. Как создать оптимальные условия для работы ГУМАНИСТУ
  8. Как создать оптимальные условия для работы ПОСРЕДНИКУ
  9. Как создать оптимальные условия для работы ЛИРИКУ
  10. Как создать оптимальные условия для работы ПРЕДПРИНИМАТЕЛЮ
  11. Как создать оптимальные условия для работы МАСТЕРУ
  12. Как создать оптимальные условия для работы АНАЛИТИКУ