«Ты что, считаешь, что мы должны создавать эту сборку каждый день?» Да, каждый день. Это часть нашей модели разработки, и это критично для способа, которым мы работаем.
Спустя годы смешно оглядываться на те дни. Сейчас ежедневные сборки — часть нашей культуры, чему никто не сопротивляется. Это само собой разумеется, и когда в сборке происходит сбой, мы видим справедливый гнев всей команды.
Типичные проблемы и их решение
Далее обсуждается ряд типичных проблем и вопросов, возникающих при использовании описываемых здесь методик, а также их решения.
Отсутствие технологов по разработке ПО
Не забудьте учесть в планах и графике вашего проекта мероприятия по технологическому обеспечению. Некоторые команды не учитывают значительный объём работ в этом направлении. В результате их часто ожидают сюрпризы и необходимость корректировки графиков.
Недостаточная автоматизация
Автоматизация сборки, создания комплектов и тестирования очень важна. Выполнение этих задач вручную потребует много времени и усилий, которые могут быть потрачены на что-то другое.
Запоздалая процедура установки
Некоторые команды часто строят исполняемые файлы, но не создают программу установки до самого конца проекта. Такой подход ухудшит видение проекта, а преимущество простого доступа, вытекающее из ранней процедуры установки, теряется всеми членами команды. Столь же часто члены команды обнаруживают, что создание процедуры установки займёт гораздо больше времени и она более сложная, чем думали изначально, а её отладка потребует ещё времени. К сожалению, поздняя разработка чего-либо, в том числе процедуры установки, добавляет риск и способна нарушить график.
Дисциплина
Ежедневное создание сборок, комплектов и тестирование требует много сил. Если дисциплина в команде недостаточно высока или проблемы остаются неразрешёнными, вы не сможете воспользоваться преимуществами, о которых мы говорили ранее. У команды должна быть культура решения проблем. Каждый член команды должен быть дисциплинирован и бороться с проблемами с момента их появления.
Часть 2
Формулирование и планирование проекта.
Глава 8
Требования
В этой главе рассматривается процесс формулирования требований к программному продукту. Каждый член команды разработчиков должен чётко представлять, какую программу нужно создать, для чего она предназначена и каковы её возможности — иначе у вашего проекта не будет ни единого шанса на успех. Проще всего добиться этого понимания с помощью чётко определённого и строго контролируемого набора требований. Но не менее важна возможность улучшения программного продукта и переработки некоторых его фpaгментов. Проект должен допускать постепенное улучшение программы вплоть до добавления одних функций и удаления других. Эти две потребности — строгий контроль и свобода развития — часто выглядят взаимоисключающими, поэтому рассмотрим каждую из них.
Для первой требуется чётко сформулированный, подробный и строгий список требований, оговаривающий практически все особенности продукта. Его дополняет жёстко заданный набор процессов, управляющих внесением изменений. Проблема этого метода заключается в трудности создания такого списка требований, особенно при работе в новых, неразработанных областях. Кроме того, он с трудом обеспечивает постепенное улучшение продукта и организацию обратной связи. Даже если создать подробный список требований было бы возможно, то в письменной форме он часто терял бы свою однозначность, а поддерживать его в актуальном виде было бы довольно трудно.
Второй подход утверждает, что достаточно лишь создать простой список требований в общей формулировке. Идея в том, чтобы дать разработчикам свободу принимать решения о реализации основных функций продукта во время его разработки. Более динамичная среда позволит разработчикам оперативно воплощать новые идеи и адекватно реагировать на потребности рынка. Однако этот подход полон неопределённости и риска: трудно планировать рабочий процесс, а управлять — ещё труднее. Это также негативно сказывается на тестировании и создании документации, так как до самого выпуска, т.е. до выяснения истинной картины функциональности продукта, сведений о продукте для начала работы будет недостаточно.
У каждого подхода свои преимущества, но какой же из них выбрать? Нужно, ещё до начала написания кода, установить фундаментальные требования, но при этом иметь возможность вносить контролируемые изменения во время цикла разработки. Давайте обсудим процесс управления требованиями, который позволит их сбалансировать.
Центральная идея проекта
В начале работы над каждым выпуском нужно добиться простого и ясного видения проблемы, при котором задачи и приоритеты проекта стали бы очевидными для всех его участников; критически важно объединить их усилия и гарантировать, что группа будет работать сообща.
Атрибутом хорошего видения проблемы является центральная идея (лейтмотив проекта), которая сплотит группу и даже всю компанию воедино. Она должна не только направлять усилия при разработке, но и способствовать позиционированию, сбыту и продвижению продукта на рынке. Вокруг неё должны объединиться все группы, обеспечивающие коммерческий успех продукта.
Хотя у крупных проектов может быть несколько таких идей, распыляться всё же не стоит. Основная идея проекта должна быть сформулирована кратко и ясно, в ней должен быть призыв к превосходству в одной-двух областях. Выбрать её нелегко, обычно такая идея является результатом тщательного анализа рынка и состояния бизнеса в данной области. Убедитесь, что достижение цели, поставленной основной идеей, принесёт значительную прибыль.
Мы в NuMega всегда пытались сделать выпуск каждого продукта волнующим событием, претендуя на самый короткий срок его создания, либо на первенство в использовании новых технологий, вплоть до того, что целью ряда наших проектов было получение премий в нашей отрасли. Вот ряд идей, которые в прошлом позволили эффективно объединить наши усилия по разработке:
• закрыть путь на рынок новым конкурентам, предоставив программистам на языке C/C++ продукт с самым полным набором функций по обнаружению ошибок;
• создать продукт для анализа производительности, самый простой в эксплуатации во всей отрасли, и добиться признания этого факта;
• создать самый мощный и функционально насыщенный отладчик ядра Windows NT.
Мы руководствовались этими идеями при выборе функций продукта и в процессе их реализации. Они также играли главную роль, когда приходилось идти на компромисс. Например, если приходилось выбирать одну из двух взаимоисключающих возможностей, достаточно было одного взгляда на центральную идею проекта, чтобы стало ясно, какую из них выбрать.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73
Спустя годы смешно оглядываться на те дни. Сейчас ежедневные сборки — часть нашей культуры, чему никто не сопротивляется. Это само собой разумеется, и когда в сборке происходит сбой, мы видим справедливый гнев всей команды.
Типичные проблемы и их решение
Далее обсуждается ряд типичных проблем и вопросов, возникающих при использовании описываемых здесь методик, а также их решения.
Отсутствие технологов по разработке ПО
Не забудьте учесть в планах и графике вашего проекта мероприятия по технологическому обеспечению. Некоторые команды не учитывают значительный объём работ в этом направлении. В результате их часто ожидают сюрпризы и необходимость корректировки графиков.
Недостаточная автоматизация
Автоматизация сборки, создания комплектов и тестирования очень важна. Выполнение этих задач вручную потребует много времени и усилий, которые могут быть потрачены на что-то другое.
Запоздалая процедура установки
Некоторые команды часто строят исполняемые файлы, но не создают программу установки до самого конца проекта. Такой подход ухудшит видение проекта, а преимущество простого доступа, вытекающее из ранней процедуры установки, теряется всеми членами команды. Столь же часто члены команды обнаруживают, что создание процедуры установки займёт гораздо больше времени и она более сложная, чем думали изначально, а её отладка потребует ещё времени. К сожалению, поздняя разработка чего-либо, в том числе процедуры установки, добавляет риск и способна нарушить график.
Дисциплина
Ежедневное создание сборок, комплектов и тестирование требует много сил. Если дисциплина в команде недостаточно высока или проблемы остаются неразрешёнными, вы не сможете воспользоваться преимуществами, о которых мы говорили ранее. У команды должна быть культура решения проблем. Каждый член команды должен быть дисциплинирован и бороться с проблемами с момента их появления.
Часть 2
Формулирование и планирование проекта.
Глава 8
Требования
В этой главе рассматривается процесс формулирования требований к программному продукту. Каждый член команды разработчиков должен чётко представлять, какую программу нужно создать, для чего она предназначена и каковы её возможности — иначе у вашего проекта не будет ни единого шанса на успех. Проще всего добиться этого понимания с помощью чётко определённого и строго контролируемого набора требований. Но не менее важна возможность улучшения программного продукта и переработки некоторых его фpaгментов. Проект должен допускать постепенное улучшение программы вплоть до добавления одних функций и удаления других. Эти две потребности — строгий контроль и свобода развития — часто выглядят взаимоисключающими, поэтому рассмотрим каждую из них.
Для первой требуется чётко сформулированный, подробный и строгий список требований, оговаривающий практически все особенности продукта. Его дополняет жёстко заданный набор процессов, управляющих внесением изменений. Проблема этого метода заключается в трудности создания такого списка требований, особенно при работе в новых, неразработанных областях. Кроме того, он с трудом обеспечивает постепенное улучшение продукта и организацию обратной связи. Даже если создать подробный список требований было бы возможно, то в письменной форме он часто терял бы свою однозначность, а поддерживать его в актуальном виде было бы довольно трудно.
Второй подход утверждает, что достаточно лишь создать простой список требований в общей формулировке. Идея в том, чтобы дать разработчикам свободу принимать решения о реализации основных функций продукта во время его разработки. Более динамичная среда позволит разработчикам оперативно воплощать новые идеи и адекватно реагировать на потребности рынка. Однако этот подход полон неопределённости и риска: трудно планировать рабочий процесс, а управлять — ещё труднее. Это также негативно сказывается на тестировании и создании документации, так как до самого выпуска, т.е. до выяснения истинной картины функциональности продукта, сведений о продукте для начала работы будет недостаточно.
У каждого подхода свои преимущества, но какой же из них выбрать? Нужно, ещё до начала написания кода, установить фундаментальные требования, но при этом иметь возможность вносить контролируемые изменения во время цикла разработки. Давайте обсудим процесс управления требованиями, который позволит их сбалансировать.
Центральная идея проекта
В начале работы над каждым выпуском нужно добиться простого и ясного видения проблемы, при котором задачи и приоритеты проекта стали бы очевидными для всех его участников; критически важно объединить их усилия и гарантировать, что группа будет работать сообща.
Атрибутом хорошего видения проблемы является центральная идея (лейтмотив проекта), которая сплотит группу и даже всю компанию воедино. Она должна не только направлять усилия при разработке, но и способствовать позиционированию, сбыту и продвижению продукта на рынке. Вокруг неё должны объединиться все группы, обеспечивающие коммерческий успех продукта.
Хотя у крупных проектов может быть несколько таких идей, распыляться всё же не стоит. Основная идея проекта должна быть сформулирована кратко и ясно, в ней должен быть призыв к превосходству в одной-двух областях. Выбрать её нелегко, обычно такая идея является результатом тщательного анализа рынка и состояния бизнеса в данной области. Убедитесь, что достижение цели, поставленной основной идеей, принесёт значительную прибыль.
Мы в NuMega всегда пытались сделать выпуск каждого продукта волнующим событием, претендуя на самый короткий срок его создания, либо на первенство в использовании новых технологий, вплоть до того, что целью ряда наших проектов было получение премий в нашей отрасли. Вот ряд идей, которые в прошлом позволили эффективно объединить наши усилия по разработке:
• закрыть путь на рынок новым конкурентам, предоставив программистам на языке C/C++ продукт с самым полным набором функций по обнаружению ошибок;
• создать продукт для анализа производительности, самый простой в эксплуатации во всей отрасли, и добиться признания этого факта;
• создать самый мощный и функционально насыщенный отладчик ядра Windows NT.
Мы руководствовались этими идеями при выборе функций продукта и в процессе их реализации. Они также играли главную роль, когда приходилось идти на компромисс. Например, если приходилось выбирать одну из двух взаимоисключающих возможностей, достаточно было одного взгляда на центральную идею проекта, чтобы стало ясно, какую из них выбрать.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73