255 ступеней

Байка для оруженосца - 3 

————————————-
Действующие лица:

Q - Белая королева (Queen). По некоторым версиям красная (червонная).

A - оруженосец (Armiger)
CC - Чеширский Кот (Cheshire Cat)

MH - Мартовский заяц, (March Hare)

H - Шляпник (Hatter)

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

CC. Ваше Величество, вы светитесь, как будто вы Ваша Светлость. Нет, даже как Ваше Сиятельство.

Q. О, да, мой вечно исчезающий друг. На этой неделе мне удалось прибить две дюжины вампиров!

CC. Отличный результат! На прикладе вашего плюсомета скоро не останется места для новых отметок.

A. Какие вампиры?

CC. Вампиры, молодой человек это такие создания, которые пьют кровь или жизненные силы.

A. Спасибо, кэп. Но все таки?

Q. Не все проекты, которые делаются в фирме, одинаково полезны. Рано или поздно в фирме заводятся проекты-вампиры. Они бесполезны или относительно малополезны. Они пьют жизненные силы организации. Когда их заводится слишком много, организация хиреет и даже может  умереть. Но к счастью, еще много миллионов проваленных проектов назад, шаманы, из трибы бизнес аналитиков разработали амулет отпугивающий проекты-вампиры. Использовать силу этого амулета легко. Достаточно твердо придерживаться двух правил: “Не запускать проект, если нет напечатанной карточки проекта”, - и королева направилась наливать  чай, всем своим видам показывая, что разговор окончен.

A. А второе?

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

A. Почему “Сумера?!

H. Потому что коза -  Зойка. В этом деле мелочей не бывает -  раздалось с углового стола.

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

A. Вы сказали бесполезные? А что бывают вредные?

Q. Сколько угодно.

A. Против них этот амулет действует?

Q. Нет. Против вредных проектов нужно более сильное колдунство. Кроме того есть еще проекты-зомби. Их также сложно отпугнуть этим амулетом.

A. Мадам, а не могли бы вы показать пример карточки?

Q. Нет. - Отрезала королева. - Все запасы амулетов были израсходованы в ходе похода против нежити.- подумав, королева добавила - И нечисти. - На самом деле королеве отчаянно хотелось чаю, а этот несносный мальчишка никак от нее не отставал.

CC. К счастью у меня завалялась парочка. - Чеширский кот с видом фокусника достал шляпу, отданную ему шляпников в обмен на услугу. - Вуаля! - и он вручил оруженосцу листок формата A4.

Мартовский Заяц и Шляпник вскочили и в панике забегали по кухне.

H&MH. Карточка! Карточка! Караул, карточка!

Q. Фигляры, - неодобрительно бросила королева. Впрочем, строгость была напускная. Королева прекрасно знала силу этого тандема. Эта парочка аналитик-программист давала фору команде из двух десятков человек. Хотя получать лулзы от их закидонов умели далеко не все. Королева умела. За что ее особенно ценило руководство. Ходили слухи, что руководитель департамента разработки бросил пить после того, как королева забрала этот тандем к себе.  И отменил еженедельные отчеты. Чем поверг всю организацию в ступор. Ну, отчеты ладно, с кем не бывает.  Но бросить пить!

Армигер начал внимательно рассматривать листок, а Чеширский кот в это время комментировал.

CC. Оформление делается шрифтами Verdana  или Tahoma, 12-ым кеглем. В исключительных случаях для проектов с высоким коэффициентом полезности допускается 11-й кегль.

A. Но здесь же катастрофически мало места! Почему бы не расширить на две-три страницы?

CC. Если карточка проекта будет оформлена на двух страницах, то она немедленно отправится в корзину.

A. А почему здесь нет больших проектов?

CC. Большому проекту - большую торпеду. A3.

MH.  Убил. - немедленно откликнулся Безумный Мартовский Заяц.

A. А если полезность будет на границе, то значит можно считать не целое число, а 0.1, 1.5

CC. Не стоит.

A. Почему?

Q. Ты соврал в резюме, что учился в институте? - спросила королева ледяным тоном.

A. Э-э-э…

CC.  Королева намекает, что еще на первом курсе вашего института студенты изучают правила расчета погрешностей. Не использовать эти знания на практике довольно глупо. Не находишь?

Армигер смутился.

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

Q.  Я уже сказала “Головы с плеч”? - глядя в пространство спросила королева.

H&MH. Нет, моя госпожа - синхронно ответили Шляпник и Заяц и также синхронно втянули головы в плечи изображая крайний испуг.

CC. Ну же, мон шер - Чеширский Кот был сама любезность, - вы же учили математику.

A.  Да - смущенно признался армигер - Матан, Теорвер, ТФКП, …

CC.  Вздор - прервал его Кот, - здесь вполне хватит школьной программы.

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

MH. Чу! Cлышу! У него скрипят шестеренки!

H. Их необходимо срочно смазать.

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

MH. Королева сегодня сурова.

H. Что ты, королева - добрая душа. Я помню, три дня назад тут поймали японского шпиона…

Дружный хохот наполнил кухню. Новый года в компании начинался нормально.

Видео: http://www.youtube.com/watch?feature=player_embedded&v=HQHt01e3Lns

Виртуальная машина с предустановленным софтом: http://www.oracle.com/technetwork/middleware/soasuite/learnmore/vmsoa-172279.html

Поиграл 10 минут. Штука очень любопытная. Однозначно “обязательна для изучения”. Не выясненные моменты:
* Есть ли возможность установить связь между временем выполнения заказа и его стоимостью?
* Есть ли расчет потерь, связанных со связанным капиталом?
* Есть ли вообще расчет прибыли/убытка?
* Можно ли сделать несколько точек старта и финиша (для имитации потоков V,A,T типа)
И т.д и т.п.

Коллеги, кто нибудь изучал этот симулятор?

Идеальная техническая система -это когда системы нет, а ее функция выполняется.

(с) ТРИЗ

Ряд авторов называют наличие бактрекера в качестве одного из признаков зрелости команды разработчиков ПО.

Действительно, множество растущих команд (компаний) в какой-то момент сталкиваются примерно с одной и той же проблемой. Список дефектов растет и в какой-то момент требуется специализированное средство для управлением порядком исправления. С пятком багов можно легко справиться при помощи почтового клиента. Полсотни багов можно вести в Excel. Но когда их пара тысяч – это уже многовато. И каждый «настоящий» инженер по качеству ПО (в просторечии тестировщик) знает, что по настоящему бороться за качество без бактрекера нельзя. Это догмат. Доктрина веры. Нет бактрекера – нет настоящих инженеров по качеству ПО. Чистая кристальная истина, в которой нельзя усомниться ни на секунду, как нельзя не услышать звук хлопка одной ладонью. А если 20 лет назад выпускались великолепные программы, без использования багтрекинга, то это просто ошибка наблюдения.

Но иногда встречаются «не настоящие».

Из книги Мэри и Тома Поппендик «Бережливое производство программного обеспечения»:

…возможны две разновидности контроля: контроль с целью обнаружения дефекта (когда он уже имеется) и контроль с целью его предотвращения…

Системы …[багтрекеры] – это очереди незавершенных работ; если угодно, очереди работ, … [на] исправление. Очень часто мы полагаем, что если дефект помещен в очередь, все в порядке, он уже никуда не денется. Однако с точки зрения концепции бережливой разработки программного обеспечения, очереди – это коллекторы непроизводительных затрат. Целью является не иметь в очереди ни одного дефекта, а еще более «целесообразная цель» - не иметь такой очереди совсем. Если вы считаете, что это невозможно представить, познакомьтесь с трехгодичным опытом работы Нэнси Ван Шундерворт над проектом по разработке сложного и часто изменяющегося встроенного программного обеспечения. За три года был в целом обнаружен 51 дефект после блочного (или модульного) тестирования, причем каждый раз выявлялось не более двух дефектов сразу. Кому нужна система отслеживания для всего двух дефектов?

Примечание. Перевод я немного поправил. Совсем чуть-чуть. Только явные ляпы.

Действительно, зачем фиксировать дефект в трекере?! Его не фиксировать надо, а исправлять. Нашли и сразу дустом его, дустом. Чтобы не размножался. На первый взгляд остается непонятным, что делать с тестировщиками. Основной артефакт, который выдают тестировщики – это список расхождений между ожиданиями и реальностью. Но пусть вас не смущает этот вопрос. Там где по настоящему пекутся о качестве, там работают не тестировщики, а инженеры по качеству ПО, которые преимущественно занимаются верификацией не скомписированного кода, но других артефактов, таких как: «требования», «диаграммы архитектуры», «исходный код».

Искать ошибки после написания кода – это как делать бэкапы уже после потери операционной базы сбербанка. В принципе полезно, но несколько поздновато. Дефекты имеет смысл искать или до написания кода, или во время оного. Но не после.

Благодарности.

Спасибо Мери и Тому Попендик, Элияху Голдратту, Тайичи Оно и Капитану Очевидность.

Таити Оно изобретатель производственной системы Toyota и технологии Канбан: ‘Моя система вообще не имеет смысла, но слава Богу, она работает’.

Если вы по какой-то причине хотите завалить проект и остаться чистеньким - выполняйте все требования заказчика.

Если ревью не выявило дефектов требований, скорее всего вы зря писали требования. Это просто выброшенное время.

Хорошо, когда с прошлой работы тебя ищут только для того, чтобы премию отдать.

В первый раз публиковалось на 1 апреля, так что …
С другой стороны, можно использовать как шаблон (рыбу) для написания регламентов, подобно “СМК от питерских”
———————————————–
Каждый работник имеет право на проступок.

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

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

Соответственно:
Каждый сотрудник должен каждый месяц совершить несколько проступков. Например:

• Использовать внутрикорпоративную почту для рекламы гербалайфа
• Предлагать клиентам фирмы прикупить журнал плейбой или комиксы про человека-паука
• Обедать в течение всех 9 часов
• И, даже, иногда, высказывать в приватных беседах неверие в судьбу фирмы

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

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

Свободу Анжеле Девис!
От Анжелы Девис руки!
Дайте свободу Анжеле,
Дайте свободу буки!!!

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

Получение и чтение подобных писем является нарушением трудового распорядка. Так что вы только что совершили два должностных проступка.
;-)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Было время вечернего чаепития, и оруженосец (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Презентация