Пиццикато Алексея Лота

Полезные высказывания из книги "Правила разработки программного обеспечения" Маккарти

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

Запаздывание - обычное явление в разработке ПО.

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

Интеллект проявляется в качествах:
творчество;
ум;
рассудительность;
эффективность;
четкость.

Самое трудное в процессе разработки ПО - добиться действительного участия создателей.

Основные аспекты деятельности в разработке:
как заставить человека думать;
о чём люди должны думать;
как сделать человеческие мысли эффективными.

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

Программист - ювелир.

Поощрять умственную деятельность.

Устранять причины, а не людей.

Большинство ресурсов должно уходить на интеллектуальную деятельность, а не в механические усилия.

Первостепенная обязанность руководителя - вовлечь каждого работника в процесс и держать его в этом процессе на протяжении всего проекта.

Программный проект - это процесс, проходящий 4 основные стадии:
начальные шаги - создание разумной маркетинговой стратегии, проектирование продукта, создание клана разработки и первые шаги по разработке (собрать работоспособную команду из хаоса, который царит в фирме);
середина игры - длительный промежуток времени, начинающийся с первого нарушения графика разработки и оканчивающийся наступлением ражима выпуска;
режим выпуска - время выпуска продукта;
запуск - время, когда продукт считается выпущенным.

Области действий хорошей разработки:
организация;
конкуренция;
клиент;
проектирование;
разработка.

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

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

Состояние продукта=тестирование и анализ.

Фирма не должна перемешивать желаемое с действительным.

Не должно быть борьбы за официально установленные полномочия.

Цель проектирования продукта в том, чтобы в его основу легли лучшие идеи.

Все споры о том, что лучше, должны быть решены до начала разработки.

Ссоры - выражение проблем, которые возникли в команде.

Распределять роли до начала разработки.

Для поддержания работоспособной, слаженной команды необходимо общее видение.

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

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

Все возникшие противоречия должны быть разрешены.

Хорошие лидеры любого уровня должны передавать свое видение приверженцам.

Установить в команде режим сопереживания.

Что делали бы эти люди на моем месте?

Как преобразовать их сложные чувства в ясный приказ о действиях?

Привлекать каждую голову в дело.

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

Выслушивать все идеи.

Чем больше идей, тем лучше.

Идеи людей должны применяться.

Создать технологический план выпуска версий.

Технологический план - обновляемый 1-2 раза в год контракт, выражающий намерения команды.

Не реализовывать все задумки именно в этой версии.

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

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

Обеспечить адекватное восприятие критики.

Правильно балансировать нагрузки в проекте.

Исключить перегорание разработчиков.

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

Использовать последние версии инструментов.

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

Необходимо соблюдать пропорции в численности команды по ролям.

У каждого одна своя роль.

Группа автора:
6 разработчиков;
2-3 контролера качества;
1 руководитель проекта;
2 технических писателя.

Контролер качества должен проектировать продукт и знать потребителей.

Можно добавить в команду маркетологов.

Управление областями по отдельным дисциплинам поручать ведущим специалистам в области.

Команда должна нести совместную ответственность за все аспекты.

Жест обратной связи гасит агрессию.

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

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

Не должно быть поддакивания, фальшивого консенсуса.

Члены команды должны осознать, что им никто не мешает.

Каждого человека надо вдохновлять и подпитывать.

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

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

Кураторы обеспечивают включение максимального количества идей в коробку с программным продуктом.

Кураторы и создатели ответственны за качество и состояние группы.

Единственная власть идет от знания и понимания, а не от занимаемой позиции.

Руководители проекта выполняют функции:
возглавляют определение успешного продукта;
возглавляют распространение видения продукта;
возглавляют движение команды к гарантированной поставке продукта.

Руководитель проекта не имеет прямой власти.

Роль руководителя проекта - лидерство.

Управление проектом - техническая задача.

2 аспекта технического мастерства: технология, используемая при создании ПО, продукта и технические аспекты лидерства при создании ПО.

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

Руководитель проекта - сердце разработки ПО.

ПО выражает команду, его создавшую.

Следить не за словами и поведением команды, а оценивать ее по ПО.

Анализ проблем в команде - способ привести ПО в порядок.

Постоянно поддерживать контакт с духом команды.

Сложные чувства и идеи должны свободно передаваться внутри команды.

Сделать максимально полной властью каждого члена команды.

В команде не должно быть авторитетов и кумиров.

Вводить команду в курс дела, чтобы сформировать адекватные ожидания.

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

В среде с правильным наделением полномочиями, ситуация не анархическая и конфронтационная, а основанная на способностях людей.

Сфокусировать внимание команды на выпуске продукта.

Игнорировать иерархические и функциональные границы.

Задача создания ПО не имеет отношения к тому, кто и какие принимает решения, кто и за что вознаграждает, кто и за что наказывает.

Четыре основные ситуации на рынке:
Вы один на рынке;
Вы идёте бок о бок с конкурентом;
Вы отстаёте от конкурента;
Вы опережаете конкурента.

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

Человек генетически предрасположен к командной работе.

Люди в вашей группе были отобраны эволюционно.

Как только поставлен диагноз ситуации, сразу обудить классические ходы.

Рынка без конкуренции не бывает.

Комплекс задач: создание отличительных преимуществ, разработка технологического плана.

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

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

При неудаче сохранить расходы на пиар.

Выпустить раньше, чем это сделают конкуренты.

При лидерстве самодовольство - враг.

Лидерство не будет вечно.

Надо конкурировать с самим собой.

Работать над увеличением скорости перемен.

Пресекать все попытки возврата к худшему.

Не позволять людям успокаиваться и замедлять движение.

Цикл ПО связан с выпусками ОС.

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

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

Нормальная успешная фирма в версии за версией отвечает на самые жесткие требования клиентов.

Рынок хочет делать на компьютерах то, что раньше на них не делалось.

Спрашивать клиентов об их нуждах всегда и везде.

Проводить статистические исследования.

Всегда думать о власти, безопасности и управлении.

Не будьте непостоянны с вашими клиентами.

Сокращать время цикла разработки.

Наличные деньги никогда не лгут.

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

Клиенты предпочитают новое ПО обещаниям.

Проанализируйте значение вашей работы в исторических терминах.

В ПО каждый элемент существенен для целого, и все существенные элементы присутствуют.

Пользователю ничего, кроме продукта, не нужно.

Тема (theme) ПО - преобладающая идея, создающая основу для проектирования.
Определив тему, нужно жертвовать другими качествами.

Элементы продукта получают внимание пропорционально их важности.

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

Минимизировать зависимости.

Исключить самую вероятную опасность.

Тщательно выбирать платформу.

Утанавливать сроки на стадии проектирования.

Разработка=планирование, составление графиков, создание и развертывание ПО.

Создавать контрольные точки.

Не слушать некомпетентных приказов.

В сумасшедшем доме здоровый человек считается сумасшедшим.

Не позволять абсурду и неразумности укреплять позиции.

В середине игры цели- стойкость и упорство.

Некоторый риск существует даже в простых процедурах.

Не поддаваться страхам команды.

Треугольник: отличительные особенности, ресурсы, время.

Запросивший помощь должен максимизировать эффективность количества и типа помощи. В таких случаях ничего нельзя сказать наверняка.

Явно озвучитвать ваше незнание, чтобы все понимали истинное положение вещей.

Вести списки относящихся к делу аспектов, которые на данный момент неизвестны.

Предпосылками успеха являются лишения и разочарования.

Не замалчивать неопределенности.

Равновесие, созгласованность, целостность.

Мысли=слова=дела.

Сдаваемые объекты должны появляться через небольшие промежутки времени.

В разработке запаздывали все.

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

Не оставлять разработчиков наедине с собой.

Продукт следует собирать с незначительными интервалами.

Не уходить в темноту.

Функциональность системы не должна теряться.

Текущая сборка - это текущее состояние команды.

Достигнуть состояния ясности и оставаться в нем.

Иметь выпускаемый продукт каждый день.

Нужен человек, занимающийся формулированием состояния дел.

Использовать метрики каждый день.

Намечать контрольные точки для каждой, даже самой маленькой задачи.

Для контрольных точек назначать уровень качества.

Команде необходимо осознавать свое состояние.

Цели контрольной точки выражаются в терминах объектов сдачи.

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

В команде производить балансировку нагрузки.

Каждую контрольную точку обсуждать без поиска виновных.

Выдвинуть на первый план моменты, которые были сделаны хорошо.

Не наказывать за опоздание в контрольной точке.

Контрольная точка: что будет передано, кому, в какой форме?

В команде - свобода высказываний.

К каждой контрольной точке выработать норматив.

Пренебречь элементами, представляющими избыточную сложность.

Контрольные точки от 6 недель до 3 месяцев друг от друга.

В проекте не более 7 контрольных точек.

К каждой контрольной точке формулируется 1-2 предложения, описывающих путь достижения.

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

Каждый новый проект начинается на нулевом уровне реальности.

Опоздания и ошибки не имеют отношения к проигрышу или вине.

Делать допуски в определении дат.

Не кричать о пугающем состоянии дел часто.

Что говорит о себе команда своим поведением?

Не искать козла отпущения.

Не переносить даты.

После опоздания следующая контрольная точка должна быть достигнута.

Делать опоздание положительным переживанием.

Наблюдать за всем.

Не все изменения следует принимать и реализовывать.

Анализировать причины и цели проблем.

Изменяться вместе с миром.

Не принуждать людей работать по вечерам и выходным.

Нарушать правила - разработчики любят вставать против власти и структуры.

Применять символическое общение.

Бета-версии должны обеспечить проверку работы продукта на как можно большем числе машинных конфигураций.

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

У маркетологов должна быть эмоциональная модель клиентов.

Критерии сортировки дефектов: серьезность дефекта, важность, размер, возможность дестабилизации ПО при исправлении дефекта, динамика командыыыыы, степень полноты тестирования продукта после исправления дефекта.

Качество включает в себя новизну проекта и его исключительность.

Фанфары - важная часть отношений с клиентом.

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

История продукта должна быть оригинальной житейской мудростью.

У людей нет ни времени, ни желания овладевать сложными вопросами.

Хороший рассказ - настроение, замысел, хорошие и плохие парни, накал страстей и сцены погони.
1-2 ключевых фактов достаточно.

Сделать так, чтобы слушатель выводил сам главную вещь, но не сообщать ее.

Мода - мощный мотивирующий фактор.

Пользователи индентифицируют себя с ПО.

Член команды должен быть прежде всего сообразительным.

Неповторимость - наиболее видимое проявление интеллекта.

Ставить кандидатам реальные задачи.

Дать людям команды перспективу.

Здоровые люди от голода не умирают.

Все новое встречает противодействие.

Почти всегда легче использовать сильные стороны человека, чем исправлять его недостатки.

Не бойтесь показать свою уязвимость.

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

Босс - клиент, разработчик - поставщик услуг.

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

Оказание наилучших услуг не граничит с самоунижением.

Когда в группе отсутствует функциональный порядок или иерархия, в группе всегда присутствует борьба (скрытая или явная) за позиции и связанная альфа-энергия.

Применять атаку с поклоном.

Вы не насладитесь удобствами и особенностями здания до тех пор, пока не поселитесь в нем.

Удаленность - центральная проблема в коллективе.

Свободное выражение эмоций в группе.

Каждый должен знать, чего он хочет, и чего от него хотят.