Архив за Ноябрь, 2011

Материальная мотивация или стимуляция?

Среда, Ноябрь 23rd, 2011

Деньги не мотивируют делать работу  (work, job).

Но, деньги мотивируют на работу (office) ходить.

Если денег не платить, то профи работать  (work, job) хуже не станут. Просто они будут ходить на другую работу (office).

Градация тестировщиков

Среда, Ноябрь 23rd, 2011

Градация условная. Взято из загашников, затачивалось под конкретную фирму, так что вам может не подойти. Будет нужно - измените.

Начинающий инженер по качеству ПО

Обязанности: 

  • Выполнение тестов
  • Нахождение и фиксация дефектов
  • Ведение лога тестирования

Должен уметь и применять на практике:

  • Фиксировать дефект в форме пригодной для дальнейшей работы

 

Инженер по качеству ПО

Обязанности: 

  • Подготовка тестовых сценариев
  • Выполнение тестов
  • Нахождение, фиксация дефектов
  • Ведение лога тестирования

Должен уметь и применять на практике:

  • Фиксировать дефект в форме пригодной для дальнейшей работы
  • Знать теорию тестирования
  • Обеспечивать и оценивать тестовое покрытия

 

Ведущий инженер по качеству ПО

Обязанности: 

  • Верификация тестовых сценариев
  • Выполнение сложных видов тестов (нагрузочное, …)
  • Нахождение и фиксация дефектов
  • Ведение лога тестирования
  • Верификация ТЗ (SRS)
  • Подготовка ПМИ (если нет выделенного аналитика)
  • Курирование начинающих тестировщиков и инженеров на испытательном сроке
  • Выполнение контрольных процедур, отличных от тестирования (анализ архитектурных решений, оценка тестопригодности, …)

Должен уметь и применять на практике:

  • Фиксировать дефект в форме пригодной для дальнейшей работы
  • Знать теорию тестирования на глубоком уровне
  • Обеспечивать и оценивать тестовое покрытия 
  • Владеть одной или несколькими смежными специальностями (базовый уровень), такими как: программирование, системный анализ, дизайн интерфейсов, системное администрирование, … 

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

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

Должен уметь и применять на практике:

  • Фиксировать дефект в форме пригодной для дальнейшей работы
  • Владеть методологией тестирования и контроля качества ПО на глубоком уровне
  • Обеспечивать и оценивать тестовое покрытие
  • Владеть одной или несколькими смежными специальностями (базовый уровень)
  • Владеть методологией разработки ПО
  • Владеть современными методами управления

Байка для оруженосца-2. Управление работами не “пинание всех”.

Среда, Ноябрь 16th, 2011

Было время вечернего чаепития, и оруженосец (armiger) пошел на запах кофе. В кухне с удобством расположилась белая королева (queen)

A. Я хочу стать руководителем проекта (далее РП). Что мне для этого делать?
Q. А зачем оно тебе? Работа скучная и неблагодарная. Если проект успешен, то это успех команды, а если не успешен, то это провал РП.

A. ???
Q. Есть всего несколько вещей, которые РП должен делать. Одна из самых неприятных - это управление потоком работ.

A. Что же в этом неприятного и сложного? Ходи да пинай всех
Q. Управление работами вовсе не “пинание всех”, - королева вздохнула - Ладно слушай.

—————————————————————–
РП пишет план.
План пишется РП.
Если некто не пишет план, то он не РП.
По-другому иногда бывает, но сейчас этим можно пренебречь.
Не РП тоже может писать план. Это нормально.

Продолжительность программного проекта - вариативная величина.
И сильно вариативная. Коэффициент от 1 до 16, при среднем 4.
Продолжительность работы в рамках программного проекта тоже вариативная величина.
Продолжительность работы имеет больший разброс, нежели продолжительность проекта.
Выдающиеся специалисты по качеству (Шухарт, Деминг, Голдратт) имели выдающиеся знания по теорверу и статам.
Выдающиеся теории управления: TQM, TOC, 6 сигм, … - построены на теорвере и статах.
Не знающий центральной предельной теоремы и прочего теорвера со статами будет планировать плохо.

Диаграмма Ганта не подходит для планирования программного проекта.
Диаграмму Ганта можно использовать для создания календарного графика, но не плана.
Диаграмму Ганта не стоит использовать для планирования программного проекта.
Использование диаграммы Ганта для планирования программного проекта ведет к увеличению срока проекта.
Для ускорения хода проекта откажись от диаграммы Ганта. В крайнем случае используй ее после других инструментов планирования.
Как составить план без диаграммы Ганта? - не мои проблемы. Ты умный, у тебя высшее образование.

Программные проекты сложным образом зависят от величины команды.
Для проектов порядка 1000 функциональных точек (60KLOC на С) команда из 5 человек работает быстрее, чем команда из 10 человек, а команда из 10 быстрее, чем команда из 20.
“Шестой лишний” - хочешь ускорить небольшой проект - отстрани от него шестого и более участника.
Если это неправда, то в твоем проекте очень серьезные проблемы. Просто ты о них не знаешь.
А может и нет.

Время выполнения операции зависит от исполнителя.
Время выполнения операции сильно зависит от исполнителя.
Время выполнения операции очень сильно зависит от исполнителя.
Трудоемкость операции без исполнителя - это профанация.
Нужна трудоемкость без исполнителя? Измеряй в попугаях.
Считаешь что измерение в попугаях - это детский сад? Измеряй в слонах.
“Я не боюсь показаться смешным. Немногие могут себе это позволить.”

План состоит из описания результатов, а не описания действий.
Поставить готовиться мясо - это плохой пункт плана, мясо приготовилось - хороший

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

Пункт плана не может иметь исполнителя.
Пункт плана может иметь ответственного.
Пункт плана не имеет трудоемкости.
Это не совсем так, но в целом верно.

Пункт плана не имеет срока завершения.
Пункт плана может иметь временные зависимости/ограничения.
Не пытайся понять это сразу, просто вернись к этому через какое то время.

Для ускорения хода проекта планируй неполную загрузку сотрудника.
Полная загрузка всех сотрудников на проекте, как правило, приводит к параличу проекта.
Вряд ли у тебя получится рассчитать запас по мощности точно. Не сможешь рассчитать - используй эмпирические 25%.
—————————————————————–
A. Но это какая бессмыслица!
Q. Не обязательно бессмыслица то, что противоречит общепринятым практикам. Если бы Генри Форд делал автомобили так, как принято, мы до сих пор бы ездили в каретах.

A. Нельзя поверить в невозможное!
Q. Просто у тебя мало опыта. В твоем возрасте я уделяла этому полчаса каждый день! В иные дни я успевала поверить в десяток невозможностей до завтрака!
Но тут время чаепития закончилось и королева отправилась заниматься одним из самых неприятных дел руководителя проекта.

Пацан сказал - пацан сделал

Вторник, Ноябрь 1st, 2011

Настоящий Пацан сказал “когда” и сделал тогда, когда сказал “когда”.

(с) Не мое.

Памятка докладчику - 2

Вторник, Ноябрь 1st, 2011

Это заметка-предположение. Выводы противоречат предыдущему опыту. Скажу больше, выводы контринтуитивны.

Слайды и презентация - это как Маркс и Энгельс два разных человека.  Презентация это, что презентатор делает на сцене. Это его доклад. И я точно так же не могу послать презентацию по электронной почте, как “Слава КПСС совсем не человек”. К чему это? К тому, что терминологическая путаница стала одной из причин появления множества презентаций ухудшенных слайдами.

25 лет назад меня учили делать доклады. И 20 лет назад учили. и 15 лет назад. И до сих пор я учусь. Одна из вещей, о которых мнеговорили: “То что двигается - привлекает внимание”. Если вы рисуете на флипчарте - вы забираете внимае к себе, к своему докладу. Если вы показываете слайды - вы отдаете и рассеиваете внимание. Вы точно хотите не привлекать внимание к вашему докладу? Точно? Уберите слайды.

“Если в комнате кто-то кому-то показывает слайды, то людей принимающих решение в этой комнате нет.” Возможно докладчик действительно не принимает решений, но сидящих в аудитории людей зачем обижать? Возможно, кто-то из них является “человеком действительно принимающим решения“? Зачем создавать к себе и к своему докладу негативное отношение? Покажите, что вы уважаете своих слушателей - уберите слайды.

Я не отрицаю возможность сделать хорошие, классные полезные слайды. Но как отличить их от плохих? Попробуйте следующую лакмусовую бумажку: “Если слайды можно “выложить в интернет” или послать по почте, то они плохие.” (Имеется в виду именно слайды, а не слайдкаст). Тут одно из двух. Или слайды являются дополнением к докладу и тогда они хорошие. Или слайды являются самостоятельным рассказом и тогда они плохие. Если вызвать на сцену двух докладчиков и попросить их провести два доклада одновременно, то это будет хорошо или плохо? Если вы ответили “плохо”, то почему вы допускаете на сцене одновременно два доклада - один посредством слайды, другой посредством докладчика? Хотите сделать хороший доклад - уберите слайды имеющие самостоятельную ценность.

  • Не можете сделать хорошие слайды => уберите слайды.
  • Не можете прочитать доклад без слайдов => снимите доклад.

И последнее. Статистика. После того, как я отказался от слайдов - мои доклады стали лучше.

Еще момент. Этот же подход можно использовать и в обратную сторону:

  1. На каких докладах будут слайды? Если на всех, то переходим к пункту 2.
  2. На каких докладах будут слайды имеющие самостоятельную ценность? Если на всех, то может лучше на конференцию и не ходить?

ЗЫ. В качестве дополнительных материалов, кроме известной “Смерти от пауерпоинта” рекомендую: