Сегодня немного важных цитат из одноименной книги.

О производительности:

На людей можно надавить, но они не станут от этого быстрее соображать.

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

— Мы берем на себя много, потому что мало чего боимся.

О документации:

Я считаю, что в каждом из нас, в душе или на уровне подсознания, живет тайный страх: мы боимся показать, что соображаем хуже других. Вся наша раса заражена этим страхом. Каждый готов предположить, что его мыслительные способности ниже средних, поэтому ему надо прикладывать дополнительные усилия, чтобы разобраться в том, в чем другие разбираются с ходу. А теперь возьмем нашу ужасную спецификацию. Ты читаешь ее целый день и обнаруживаешь, что ничего не понимаешь. И тут приходит начальник и спрашивает: «Ну как? Как вам спецификация?» Что сказать? И мы врем! «Все в порядке, босс. То есть я хочу сказать, что документ этот весьма непростой, но дайте нам еще немного времени, и мы во всем разберемся…» И так поступает каждый!

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

и здесь же:

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

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

В пятницу ходил на тренинг по Scrum, проводимому Flasoft в айти парке.

Выговорился. Пообщался с людьми, у которых похожие проблемы с управлением процесса разработки программного обеспечения, получил несколько очень полезных советов, сам поделился опытом с тем, как можно делать хорошо :-) Но «выговорился», оказывается, самое лучшее из того, что со мной произошло там. И не подозревал, что у меня накопилось много недовольства по тому что происходит, но за неимением альтернативного видения, считал что все нормально.

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

В сухом остатке:

1. Scrum хорошо работает в команде 7 человек (максимум)
2. Команда должна состоять из универсалов
3. Команда должна быть супермотивирована
4. Если кто-то сфакапился, ответственность несут все
5. Продукт оунер головой отвечает за проект и перед заказчиком и перед командой:
1. что он правильно понял что нужно заказчику
2. и что правильно передал это знание команде
6. Скарм мастером может быть хоть уборщица, если она:
1. знает все правила скрама и
2. может следить за тем, как эти правила исполняются
3. и мотивировать команду сворачивать горы
7. Издержки времени на поддержание процесса скрама ради скрама могут доходить до 30% и это нормально
8. Если заказчик требует что-то исправить в уже начатой итерации, нужно:
   1. Заменить что-то не критичное с и равнозначное по velocity на работу по этому измнению
   2. На каждую итерацию оставлять запас по velocity на незапланированные изменения, т.е. – запланировать их
   3. Вынести одного человека из скрама, чтобы он занимался только этим и не работал в скраме
   4. Сократить длительность итераций
9. Scrum poker – гениальное изобретение. В него стоит добавить лишь 1 правило: говорить не дольше 1 минуты.

Огромная благодарость тренеру Диляре за ответы на вопросы и мастерство!

Когда управление рисками действительно ведется и укореняется в корпоративной культуре, проекты смогут пройти все или большинство следующих проверок:

1. Имеется перечень рисков. В этот перечень включены все главные риски проектов разработки программного обеспечения, а также риски, присущие исключительно данному проекту. Риски эти по природе своей причинные (то, что вызовет ужасные результаты, а не то, что само является ужасным результатом).

Основные пять: изьяны календарного планирования, текучесть кадров, раздувание требований, нарушение спецификаций, низкая производительность.

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

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

4. Имеются цели и оценки проекта, и они никогда не совпадают. Цели могут быть на уровне «нанопроцентной даты» или рядом с ней, а оценки должны быть гораздо более консервативными. Если целью данного проекта является поставка продукта через 12 месяцев, то оценка должна планировать поставку хотя бы месяцев через восемнадцать. В любом случае, конкретный уровень доверия, который связан с любым обстоятельством, должен быть указан диаграммой неопределенности.

5. У каждого риска есть установленный индикатор наступления. Происходит постоянный мониторинг для обнаружения наступления риска.

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

7. Оценивается подверженность каждому из рисков.

8. Существуют количественные оценки выгоды по проекту. После завершения проекта обязательно измеряется реализованная выгода. Имеется упорядоченная по их выгодности (ценности) система компонентов создаваемой системы, используемая как входные данные при планировании версий.

9. В план проекта хотя бы частично встроен инкрементный метод. Некоторые или все версии действительно поставляются заказчикам или происходит псевдопоставка (представляющая собой все необходимые этапы, кроме реальной поставки). Данные о времени, усилиях и т.п. обрабатываются по каждой завершенной версии и используются в качестве показателей завершения во второй половине проекта.

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