255 ступеней

Было время вечернего чаепития, и оруженосец (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. Просто у тебя мало опыта. В твоем возрасте я уделяла этому полчаса каждый день! В иные дни я успевала поверить в десяток невозможностей до завтрака!
Но тут время чаепития закончилось и королева отправилась заниматься одним из самых неприятных дел руководителя проекта.

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

(с) Не мое.

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

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

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

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

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

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

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

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

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

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

• Бессмысленная презентация   - статья о разнице в культурах и влиянии культуры на способ подачи материала
• iПрезентация

В ходе бесед с коллегами выяснилось, что еще минимум пара уважаемых человек (Денис Бесков и Макс Дорофеев) считают, что ценность внедрения тестирования по привычному сценарию “несколько преувеличена”.

Тема интересная и одного круглого стола для ее полного разбора будет недостаточно. Хороший круглый стол получился в Минске в августе. Частично эта проблема озвучивалась мной в январе на совместном семинаре московского отделения PMI и гильдии программных менеджеров. В планах поход в гости к Максу на “побухтеть” и обсуждение этой же темы на SQADays-10. Каждый раз обсуждение с вариациями.

На ближайшую встречу предложена следующие “базовые варианты”:
————————————————————————-
A. Тестировщики тормозят процесс разработки по Agile?
Q. Вопрос сформулирован неверно. Agile, не Agile - это перпендикулярное измерение. В малых проектах выделенный тестировщик тормозит процесс.

A. А в больших?
Q. Слишком часто тоже тормозит. Но по другой причине. В малых проектах имеет место эффект “чем больше команда, тем дольше делаем проект”. В больших же имеем эффект “ограничение системы перенесено на самый дешевый участок”.

A. Тестировщики необходимы.
Q. Не то чтобы необходимы, но иногда полезны. Иногда и только после того, как внедрены другие процессы.

A. Тестировщики нужны всегда!
Q. Меня берет сомнение, что уровень процесса тестирования может быть выше уровня процесса версионного контроля. Если версионный контроль на нуле, то надобность в выделенных тестировщиках вызывает сомнение.

A. Но ведь появление тестировщиков в индустрии принесло огромную пользу.
Q. В том виде, в котором происходило это внедрение - это скорее огромный вред. Модель разделения ролей “РУТ” (разработка, управление, тестирование) порочна.

A. Но без тестировщиков нельзя сделать сложный проект.
Q. Странно. Но делали же. Видимо, пацаны “не знали”.

A. Тестирование позволяет лучше удовлетворить заказчика.
Q. Учитывая, что большая часть дефектов вносится в систему до кодирования, мне кажется, в высшей мере странным ставить ОТК только после кодирования. Контроль до кодирования принес бы куда больше пользы.
————————————————————————-
PS. Этюды для тестировщиков. В этом тексте есть интересная фича не относящаяся к теме обсуждения, которая кажется серьезной багой. Багу найти легко. Описать фичу - сильно сложнее. Welcome.

эта заметка местами похожа на триллер, местами на детектив, а местами на комедию

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

Но почему бы не сделать пересмотр дела?
Отряхнем пыль с книги Андрея Георгиевича Орлова  “Записки автоматизатора. Профессиональная исповедь” и откроем главу про типичнейшие ошибки, допускаемые программистам. Надеюсь, автор не сильно обидится на меня за рекламу его замечательной книги.

Грабли классические

Суббота, десять вечера. Из продовольственного магазина, в котором внедряется пилотный проект складской системы, звонит кладовщик. Едва не плача, он сообщает, что принял товар на склад, а секции его выдать не может, поскольку товар пропал. А если его срочно не продать, то он протухнет.
Приезжаю. Пытаюсь найти товар на складских карточках. Действительно, найти не получается. А приходная накладная есть. В ней все правильно. Смотрю отчет по товародвижению - в нем все на месте. Проверяю суммарные остатки по складу - накладная учтена. То есть товар на складе есть, а вот найти его нельзя. Правда, на этом складе уже восемь тысяч карточек, так что визуально товар не обнаружить, если даже он есть. Уточняю, что делал кладовщик.
- Это новый товар. Я его сначала завел по бумажной накладной в справочник номенклатуры, потом ввел саму накладную. А потом посмотрел на сам товар и понял, что это тефтели, а не котлеты, как написано в накладной.
- И как ты поступил?
- Исправил запись в справочнике номенклатуры. А в накладной все изменилось само.
- Кажется, я понял, - отвечаю я, подумав. - Смотри, - и набираю в строке поиска “котле”. Экран прокручивается, и на нем подсвечивается строчка “Тефтели”. За спиной раздается восхищенное “Ой”, но я в это время уже представляю, что я сделаю с разработчиками в понедельник.
Но воскресенье, предшествующее встрече, их спасает. Я не только никому ничего не пытаюсь оторвать, я даже могу разговаривать, используя только слова литературного русского языка:
- Вы что, название товара записываете на складской карточке?
- Мы только первые пять символов записываем, чтобы поиск шел быстрее.
Тут я становлюсь даже ласковым:
- А что вы делаете, если складские карточки уже созданы, а я наименование в номенклатурном справочнике поменяю?
- Кажется, ничего не делаем.
- То есть если я завел на склад “котлеты”, а потом исправил в справочнике номенклатуры название на “тефтели”, то что я увижу на карточке?
- “Тефтели”.
- А искать мне что нужно?
- “Котлеты”… Наверное, это не совсем правильно…
- Не совсем правильно?
- Согласен, это совсем неправильно. Мы к следующему обновлению переделаем…

Я начал именно с примера, чтобы не пугать читателя высоконаучными словами. Но в приведенном случае были нарушены принципы проектирования баз данных, описанные в классических работах 1970-х годов. Таблица базы “Складские карточки” не находится в третьей нормальной форме. Про это уже столько понаписано, что мне и добавить нечего. Появление новых СУБД и новых способов поддержания зависимостей в базе данных совершенно ничего не меняет: грабли продолжают работать даже при использовании триггеров и джобов (заданий, запускаемых автоматически в определенные моменты суток или через определенные временные интервалы).
Все попытки поддерживать целостность и непротиворечивость данных не на уровне схемы базы, а с помощью программных примочек натыкаются на одно практически непреодолимое препятствие: в достаточно сложных системах вы просто забываете это сделать для некоторых вариантов работы.
Кстати, неумелое использование перечисленных инструментов, на мой взгляд, приводит к последствиям более страшным, чем их полное неиспользование.

Финит а ля комедия. Я готов поставить 10 к 1, что программисты  Invision Power Board денормализовали БД. Иногда это можно делать. Но в этом случае Гигиена Разработки ПО просто таки требует прописать риски соответствующие этой денормализации и аккуратно их обработать. В конкретно этом случае я бы рекомендовал привести БД к нормальной форме и выкинуть часть кода по изменению значения поля. Код локализуется  легко, исправляется тоже тривиально. А возможные проблемы производительности можно при желании полечить кешированием. Это если бы я участвовал в проектировании.

У тестировщика, нашедший ошибку последовательность действий другая. При обнаружении ошибки такого класса нет смысла искать последовательность действий для воспроизведения дефекта. Вероятность того, что проблема именно в денормализации достаточно велика. Зачем тратить время? Его и так не хватает. Соответственно, в зависимости от политики доступа к коду (разрешен ли white box), тестировщик или сам проверяет БД или пишет предположение о денормализации с просьбой проверки БД. Далее ведущий тестировщик, имеющий смежную специализацию (а ведущий тестировщик не может не иметь хоть какой-то смежной специальности) в проектировании может предложить архитектору варианты решений:

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

Тестировщик не должен настаивать на архитектурном решении, но может их предложить. Если его квалификация это позволяет.

И напоследок процитирую отрывок из другой, не менее замечательной книги Б.С. Ванштейна “Ловушки Ферзьбери”:

 - Зачем все эти красоты, когда после 8. Фd5 черные сразу должны сдаться?

***

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

- Вот и мне тогда это казалось интересным, но сейчас - немного даже стыдно. Читаю в переводах: “una bonita combination”, “een prachtige kombinatie” … А чего тут “бонита”, чего “прахтиге”? Пошел ферзем на d5 - и дело с концом!

 Я веду небольшую коллекцию багов. Иногда даю их на собеседовании, иногда разбираю на тренингах. Сохраню и этот красивый баг

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

Написание контрольных примеров до написания требований это хороший способ разработки требований. Такая вот: “Разработка требований ведомая тестированием требований”.

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

Когда  молодые,  амбициозные закончатся, и надо будет работать. Тогда звоните. Вот моя визитка

(с) Неизвестный хороший специалист в годах.

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

С семинара Макса дорофеева

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

Из разговора с Александром Александровым.

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

(c) Капитан Очевидность. http://lurkmore.ru/Капитан_Очевидность

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

В какой-то момент при анализе предметной области выяснилось, что в спецификации требований пропущено описание очень важного функционала. Функционал был весьма нетривиальным, и без подробного анализа и описания пытаться реализовать его было бы э-э-э… нерационально. Если кому интересно, то это был функционал перевода объекта в состояние дубликат с передачей дочерних элементов дублируемому объекту. Ведущий аналитик, который отвечал за этот модуль, написать этот юзкейс оказался не в состоянии. справедливости ради, надо отметить, что с ходу написать этот юзкейс не смогла и группа аналитиков, собравшихся на ЛАФ-2010 (посмотреть можно в материалах с конференции ЛАФ-2010). Да, юзкейск хитрый и требует времени на обдумывание. Вполне себе юзкейс на полдня-день. Не на пятнадцать минут. Ну, или надо быть ведущим аналитиком.
Впрочем, мы отвлеклись. Ведущий аналитик передал эту задачу техническому писателю. Технический писатель не смог решить ее самостоятельно и обратился за помощью к тестировщику. Тестировщик объяснил, синтаксис юзкейсов и как писать именно этот юзкейс. Технический писатель сделал описание. Задача выполнена. Но кто же здесь аналитик, невзирая на то, что написано в трудовой книжке?

• Если инженер знает, как писать спецификации требований и пишет их на проекте, то будьте уверенны, что он аналитик и есть. Невзирая на то, что написано в трудовой.

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

• Если в трудовой у инженера написано аналитик, но он не умеет писать требования и не пишет их на проекте, то будьте уверены - он не аналитик.

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

- Теперь я понимаю! - радостно сказал он.

Мы вперили в него взоры, полные ожидания.

- Я понимаю… Ясно, что эта калоша резиновая!

Изумленные, мы вскочили с кресел..