Слово Канеру
Воспользуйтесь другими источниками информации
Вы не беспомощны, если вам не предоставили спецификации. Много других источников информации помогут управлять решениями.
Например, спросите о юзкейсах у маркетологов или разработчиков. Они могут быть использованы для сессий тестирования и выявить систематические ошибки быстрее, чем прогон функциональности фич.
Вот другие источники полезной информации, которую можно использовать для мест, не охваченных спецификациями:
- Пользовательская документация (и ее предыдущие версии)
- Литература по маркетингу продукта
- Маркетинговые презентации, концепции продаж и управления продуктом
- Пояснения к изменениям продукта, поставляемые с каждой новой версией
- Внутренние записи (например пояснения менеджера инженерам, описывающее фичи)
- Опубликованные стандарты по стилю и пользовательскому интерфейсу (например руководства от Apple или Microsoft)
- Опубликованные стандарты (например, языка С)
- Наборы тест-кейсов сторонних компонент
- Опубликованные регламенты
- Багрепорты и ответы на них
- Результаты реинженеринга программ
- Интервью с такими людьми, как руководитель разработки, техписатель, техсаппорт, эксперт в предметной области, менеджер проекта.
- Заголовки файлов, исходный код, описания таблиц баз данных
- Спецификации и списки багов для сторонних инструментов, которые вы используете.
- Прототипы и лабораторные записки о них
- Интервью с разработчиками последней версии
- Записи звонков клиентов предыдущей версии (Какие дефекты они нашли в боевых условиях)
- Результаты тестирования юзабилити
- Результаты бета-теста
- Ziff-Davis SOS CD или другие CD техсаппорта, для баг вашего продукта или баг в нише вашего продукта.
- BugNet или другие сайты, описывающие общие ошибки. http://www.bugnet.com , http://www.cnet.com, и ссылки с http://www.winfiles.com, рассылки, дискуссионные сайты и другие ресурсы, где обсуждаются дефекты в вашем продукте.
- Совместимые продукты (поймите их архитектуру, особенности, баги и сравните с вашим продуктом). См. рассылки, BugNet и так далее.
- Прямое сравнение с продуктом конкурентов
- Содержание релевантных справочных материалов (например атлас, если вы делаете программу онлайн-географии)
воскресенье, 30 сентября 2012 г.
четверг, 27 сентября 2012 г.
Lesson 178
Слово Канеру
Не просите о вещах, которые вы не будете использовать.
Тестировщики любят говорить: «Спецификации нет. Как я могу проверять без спецификации?» Если вы требуете спецификацию — используйте ее. Убедитесь в том, что менеджер и создатель спецификации знают, что вы используете ее и знают как вы ее используете. В противном случае, в будущем они откажутся предоставить вам что-либо, что неудобно для них. Они скажут: «Почему я должен вам дать это? Вы заставили меня тратить время на написание спецификации, а сами ее не использовали.»
Не просите о вещах, которые вы не будете использовать.
Тестировщики любят говорить: «Спецификации нет. Как я могу проверять без спецификации?» Если вы требуете спецификацию — используйте ее. Убедитесь в том, что менеджер и создатель спецификации знают, что вы используете ее и знают как вы ее используете. В противном случае, в будущем они откажутся предоставить вам что-либо, что неудобно для них. Они скажут: «Почему я должен вам дать это? Вы заставили меня тратить время на написание спецификации, а сами ее не использовали.»
вторник, 25 сентября 2012 г.
Lesson 177
Лейтмотив дня задал Влади:
А вдруг есть еще много таких ребят:
Один лучше другого и все лучше тебя.
Ну что, что ты будешь делать,
Когда к тебе припрутся хорошие пацаны?
Слово Канеру
»Проектная документация — интересная фикция: Полезна, но ее недостаточно.»
— Brian Marick
Даже в проекте, в котором пытаются полностью описать продукт, разработанная документация (спецификаций, требований) оставляет место для фантазий. Не боритесь с этой истиной, она фундаментальна.
Рассмотрим обработку ошибок. Мы подсчитали, что больше 80% кода современного программного обеспечения связано с обработкой исключений и менее 20% с основной задачей. Но даже тщательная спецификация посвящает исключениям не больше 20%. Это значит, что обработку остальных 80% исключений проектируют программисты когда пишут код.
Просите конкретную дополнительную информацию, чтоб заполнить пробелы, когда работаете со спецификацией. Не проектируйте тесты, не планируйте проект, предполагая, что на бумаге у нас есть полное, точное описание.
А вдруг есть еще много таких ребят:
Один лучше другого и все лучше тебя.
Ну что, что ты будешь делать,
Когда к тебе припрутся хорошие пацаны?
Слово Канеру
»Проектная документация — интересная фикция: Полезна, но ее недостаточно.»
— Brian Marick
Даже в проекте, в котором пытаются полностью описать продукт, разработанная документация (спецификаций, требований) оставляет место для фантазий. Не боритесь с этой истиной, она фундаментальна.
Рассмотрим обработку ошибок. Мы подсчитали, что больше 80% кода современного программного обеспечения связано с обработкой исключений и менее 20% с основной задачей. Но даже тщательная спецификация посвящает исключениям не больше 20%. Это значит, что обработку остальных 80% исключений проектируют программисты когда пишут код.
Просите конкретную дополнительную информацию, чтоб заполнить пробелы, когда работаете со спецификацией. Не проектируйте тесты, не планируйте проект, предполагая, что на бумаге у нас есть полное, точное описание.
Стих
Вот тут
http://lllytnik.livejournal.com/60948.html
Шутник очень хорошо написала.
Помнишь ту осень, друг?
Как роса к утру
выпадала стеклом, было зябко
дрова по траве нести.
Руки грелись у костерка,
а вино -- от рук.
Вино скрепляло союзы
и клятвы в верности.
Помнишь, друг, ты просил:
"Если я решу, что пришёл
к свету, к миру с собой,
к мудрости, к равновесию;
если стану публично блеять, как хорошо
гнев свой
собрать и скомкать,
отринуть весь его;
если я буду лить этот елей,
в здравом уме, от своего имени
не жалей меня, пожалуйста, не жалей.
Пристрели меня".
Ты просил.
Я пришёл.
И не нужно мне тут соплей
про условность, про что ты имел,
а что не имел в виду.
Не сбивайся с ритма,
шагай веселей, смелей.
Я ведь тоже боюсь,
видишь -- бледный как мел иду.
Глубже рой,
становись, дыши. Изучай момент.
Твой биограф мне скажет спасибо,
ты только вдумайся.
Вероятно, я всю свою жизнь
проведу в тюрьме,
но как истинный друг
ради дружбы иду на всё
Там у Дануты Шутника еще много..
http://lllytnik.livejournal.com/60948.html
Шутник очень хорошо написала.
Помнишь ту осень, друг?
Как роса к утру
выпадала стеклом, было зябко
дрова по траве нести.
Руки грелись у костерка,
а вино -- от рук.
Вино скрепляло союзы
и клятвы в верности.
Помнишь, друг, ты просил:
"Если я решу, что пришёл
к свету, к миру с собой,
к мудрости, к равновесию;
если стану публично блеять, как хорошо
гнев свой
собрать и скомкать,
отринуть весь его;
если я буду лить этот елей,
в здравом уме, от своего имени
не жалей меня, пожалуйста, не жалей.
Пристрели меня".
Ты просил.
Я пришёл.
И не нужно мне тут соплей
про условность, про что ты имел,
а что не имел в виду.
Не сбивайся с ритма,
шагай веселей, смелей.
Я ведь тоже боюсь,
видишь -- бледный как мел иду.
Глубже рой,
становись, дыши. Изучай момент.
Твой биограф мне скажет спасибо,
ты только вдумайся.
Вероятно, я всю свою жизнь
проведу в тюрьме,
но как истинный друг
ради дружбы иду на всё
Там у Дануты Шутника еще много..
Lesson 176
А я добыл для тестеров вот такой вот артефакт:
Теперь мы этим звоночком всех на митинги собираем, звонкости он неимоверной. Все остальные команды и компании нам завидуют, а один екатеринбуржский кабак немного негодует...
Где б рынду добыть, чтоб на обед звать, хм...
С переводом какая-то беда сегодня.
Слово Канеру
Адаптируйте ваши процессы к практикам разработки, которые реально используются.
Консультант, выступая на недавней конференции по тестированию, сообщила аудитории, что тестировщики должны отказаться от тестирования продукта, пока программисты не предоставят исчерпывающую документацию. Это ужасный совет.
Советы, подобные этому, звучат и звучали удручающе часто последние лет 20. Мы считаем, что в такое случае более вероятно будет подорвано доверие к тест-менеджеру или он будет уволен, чем улучшатся процессы в компании.
Let's note and then set aside the religious question: Are documentation- heavy approaches that resist late changes (like the waterfall) really the only ones that qualify as "good engineering?" That's the assumption (often stated explicitly) behind this type of advice.
На наш взгляд, ключевыми вопросами при отказе от какой-либо практике будут:
- Будет ли ваша группа согласно этой практике требовать от программистов делать то, что они не делают, не будут делать и в настоящее время это делать не нужно?
- Это реально?
- С каких это пор вы стали менеджером или вице-президентом по развитию? Если вы ходите вести проект, станьте человеком, которого наймут, чтоб вести поект.
We suggest that you work with programmers as they are. Salespeople and drive-by consultants, who have no stake in your success and face no consequences from your failures, are poor authorities on the proper responsibilities of programmers in your company.
bret pettichord, cem kaner, chapter 8, james bach, lessons learned in software testing, лекции
 |
| Альбом: office |
Теперь мы этим звоночком всех на митинги собираем, звонкости он неимоверной. Все остальные команды и компании нам завидуют, а один екатеринбуржский кабак немного негодует...
Где б рынду добыть, чтоб на обед звать, хм...
С переводом какая-то беда сегодня.
Слово Канеру
Адаптируйте ваши процессы к практикам разработки, которые реально используются.
Консультант, выступая на недавней конференции по тестированию, сообщила аудитории, что тестировщики должны отказаться от тестирования продукта, пока программисты не предоставят исчерпывающую документацию. Это ужасный совет.
Советы, подобные этому, звучат и звучали удручающе часто последние лет 20. Мы считаем, что в такое случае более вероятно будет подорвано доверие к тест-менеджеру или он будет уволен, чем улучшатся процессы в компании.
Let's note and then set aside the religious question: Are documentation- heavy approaches that resist late changes (like the waterfall) really the only ones that qualify as "good engineering?" That's the assumption (often stated explicitly) behind this type of advice.
На наш взгляд, ключевыми вопросами при отказе от какой-либо практике будут:
- Будет ли ваша группа согласно этой практике требовать от программистов делать то, что они не делают, не будут делать и в настоящее время это делать не нужно?
- Это реально?
- С каких это пор вы стали менеджером или вице-президентом по развитию? Если вы ходите вести проект, станьте человеком, которого наймут, чтоб вести поект.
We suggest that you work with programmers as they are. Salespeople and drive-by consultants, who have no stake in your success and face no consequences from your failures, are poor authorities on the proper responsibilities of programmers in your company.
bret pettichord, cem kaner, chapter 8, james bach, lessons learned in software testing, лекции
понедельник, 24 сентября 2012 г.
Lesson 175
Пишу в рассылку репорт с пометкой "Некритично для АТ". (АТ - группа автоматизации)
Я то знаю, что это значит данный дефект не блокирует дальнейшее кодирование тестов,
но почему-то в голове это звучит как проблемы негров шерифа не волнуют.
I must gain worth. Thank you for your kindness.
I must gain worth. Thank you for your kindness.
I must gain worth...
Слово Канеру
Иногда правильным решением является остановка цикла тестирования-отладки и перепроектирование ПО.
Если вы продолжаете находить баги в одной и той же области и вне зависимости от того, сколько уже было исправлено ошибок, они все равно продолжают появляться даже из за небольших изменений — возможно пришло время остановить тестирование и отладку этой области. Она, вероятно, нуждается в рефакторинге.
Как тест-менеджер, вы могли бы предложить это менеджеру продукта. Вы находитесь в выгодной позиции, имея возможность использовать статистику баг-трекинговой системы (много репортов, много исправлений, много сбоев).
Мы предлагаем дать эту рекомендацию руководителю проекта лично, понимая, что вы можете и не убедить его в необходимости провести рефакторинг. Менеджер управляет проектом. Вы предоставляете ему услуги, в том числе хорошие советы, но он имеет право совершать свои ошибки. Его правильные решения тоже могут сперва показаться вам чем-то вроде ошибки.
Как и везде, корпоративная культура играет здесь свою роль. Некоторые компании ждут, что вы публично огласите свои рекомендации. То, что мы предлагаем относится скорее к тону этого предложения: вы обнаружили проблему и делаете предложение, которое менеджер может принять или отклонить.
среда, 19 сентября 2012 г.
Lesson 174
Друзья, а какие вы используете андроид приложения?
Для друзей, использующих приложения с иных платформ, хотелось бы процитировать хабр:
Dv0rsky: Месяц назад перешел на НТС после нескольких лет использования айфонов
qde5n1k: и как впечатление?
Tematika: … стал меньше заглядываться на мужские задницы
Слово Канеру
Используйте smoke тесты для оценки билда.
Smoke-тесты (или проверка корректности или приемочный тест) представляют собой набор тестов, целью которых является проверка базовой функциональности билда. Если билд проваливает тест, то он объявляется нестабильным, не подлежащим тестированию.
Обычно, когда новый билд попадает в тестирование, один из тестировщиков запускает smoke-тест (который может быть автоматизированным, проводиться вручную или комбинацией этих способов). Другие тестировщики игнорируют билд, пока он не пройдет smoke-тестирование. Он включает набор стандартных, базовых тестов и несколько временных (тесты, которые будут существовать несколько сборок), сосредоточенных на какой-то ошибке или фиче, представляющей интерес в этой сборке.
Процесс smoke-тестирования публичен. В приличных компаниях программисты получают копии всех документов, описывающих тесты и код, запускающий smoke-тесты. В других компаниях, программисты запускают smoke-тесты автоматически, как часть процесса сборки. Все понимают, что если ПО не проходит тест, оно не попадает в тестирование. Этот процесс без сюрпризов. В этих условиях smoke-тест рассматривается как техническая, а не политическая задача, и большинство людей в проекте (включая большинство или всех менеджеров) считают ее разумной.
 |
| Альбом: home |
Для друзей, использующих приложения с иных платформ, хотелось бы процитировать хабр:
Dv0rsky: Месяц назад перешел на НТС после нескольких лет использования айфонов
qde5n1k: и как впечатление?
Tematika: … стал меньше заглядываться на мужские задницы
Слово Канеру
Используйте smoke тесты для оценки билда.
Smoke-тесты (или проверка корректности или приемочный тест) представляют собой набор тестов, целью которых является проверка базовой функциональности билда. Если билд проваливает тест, то он объявляется нестабильным, не подлежащим тестированию.
Обычно, когда новый билд попадает в тестирование, один из тестировщиков запускает smoke-тест (который может быть автоматизированным, проводиться вручную или комбинацией этих способов). Другие тестировщики игнорируют билд, пока он не пройдет smoke-тестирование. Он включает набор стандартных, базовых тестов и несколько временных (тесты, которые будут существовать несколько сборок), сосредоточенных на какой-то ошибке или фиче, представляющей интерес в этой сборке.
Процесс smoke-тестирования публичен. В приличных компаниях программисты получают копии всех документов, описывающих тесты и код, запускающий smoke-тесты. В других компаниях, программисты запускают smoke-тесты автоматически, как часть процесса сборки. Все понимают, что если ПО не проходит тест, оно не попадает в тестирование. Этот процесс без сюрпризов. В этих условиях smoke-тест рассматривается как техническая, а не политическая задача, и большинство людей в проекте (включая большинство или всех менеджеров) считают ее разумной.
Lesson 173
Падаван Mazd в конце года рванет в Минск на пресловутую. С чем я его и поздравляю, пусть проникается атмосферой и вообще.
По славной традиции, отправляясь на sqa days, тестировщики из моей группы берут с собой Наташку из ручного тестирования.
И в этот раз все ок, Mazd везет на sqa уже третью Наташку. Этого добра у нас хватит еще на несколько конференций. И еще на семинары останется.
Слово Канеру
Иногда вы должны отказаться от тестирования сборки.
Иногда следует отклонять сборку и не тестировать ее. Могут быть технические причины для этого:
- Если смысл этой сборки в появлении важной новой фичи, а вы обнаружили, что ее нет в сборке, то дальнейшее тестирование — пустая трата времени.
- Если ключевые фичи продукта, используемые для работы, сломаны. Билд собирался, скорее всего с некорректными файлами. Ошибки, найденные в этой сборке будут игнорироваться («Да, эта ошибка связана с некорректным бла-бла-бла файлом. Можно ли воспроизвести эту ошибку снова?»). Ваш smoke тест должен ловить такие дефекты. Отказ от тестирования сборки тоже происходит автоматически, когда не проходит smoke тест.
- Если вы получили сборку, но знаете, что новая появится через несколько часовwhich won't be affected in any way by what you find in this build, depending on the cost to qualify and install a build, you might be better off ignoring this build and continuing to test on the old one while waiting for the next one.
Общий принцип состоит в том, что вы должны отказаться от тестирования сборки, если это сделает вашу работу значительно менее эффективной без заметных выгод, или в случае, если результаты тестирования этой сборки будут проигнорированы.
По славной традиции, отправляясь на sqa days, тестировщики из моей группы берут с собой Наташку из ручного тестирования.
 |
| Альбом: office |
И в этот раз все ок, Mazd везет на sqa уже третью Наташку. Этого добра у нас хватит еще на несколько конференций. И еще на семинары останется.
Слово Канеру
Иногда вы должны отказаться от тестирования сборки.
Иногда следует отклонять сборку и не тестировать ее. Могут быть технические причины для этого:
- Если смысл этой сборки в появлении важной новой фичи, а вы обнаружили, что ее нет в сборке, то дальнейшее тестирование — пустая трата времени.
- Если ключевые фичи продукта, используемые для работы, сломаны. Билд собирался, скорее всего с некорректными файлами. Ошибки, найденные в этой сборке будут игнорироваться («Да, эта ошибка связана с некорректным бла-бла-бла файлом. Можно ли воспроизвести эту ошибку снова?»). Ваш smoke тест должен ловить такие дефекты. Отказ от тестирования сборки тоже происходит автоматически, когда не проходит smoke тест.
- Если вы получили сборку, но знаете, что новая появится через несколько часовwhich won't be affected in any way by what you find in this build, depending on the cost to qualify and install a build, you might be better off ignoring this build and continuing to test on the old one while waiting for the next one.
Общий принцип состоит в том, что вы должны отказаться от тестирования сборки, если это сделает вашу работу значительно менее эффективной без заметных выгод, или в случае, если результаты тестирования этой сборки будут проигнорированы.
понедельник, 17 сентября 2012 г.
Lesson 172
Слово Канеру
Будьте готовы к билду.
Важно иметь готовое тестовое окружение к моменту появления сборки. Это особенно актуально для веб. В быстро меняющемся проекте группа тестирования без управляемой тестовой среды бесполезна.
Будьте готовы к билду.
Важно иметь готовое тестовое окружение к моменту появления сборки. Это особенно актуально для веб. В быстро меняющемся проекте группа тестирования без управляемой тестовой среды бесполезна.
Lesson 171
Слово Канеру
Пойми, что делают (и чего не делают) программисты перед созданием билда.
Некоторые группы программиистов проводят обширное юнит-тестирование перед выпуском сборки для тестировщиков. Другие нет.
Некоторые программисты проводят smoke-тестирование как часть процесса сборки. Другие нет.
Группа программистов с которой вы работаете, делает то, что она делает. Не надо считать, что они проводят или не проводят определенные виды тестов, определенные подготовительные действия для создания билда. Узнайте их техпроцесс и стройте свой на основании этого знания.
Пойми, что делают (и чего не делают) программисты перед созданием билда.
Некоторые группы программиистов проводят обширное юнит-тестирование перед выпуском сборки для тестировщиков. Другие нет.
Некоторые программисты проводят smoke-тестирование как часть процесса сборки. Другие нет.
Группа программистов с которой вы работаете, делает то, что она делает. Не надо считать, что они проводят или не проводят определенные виды тестов, определенные подготовительные действия для создания билда. Узнайте их техпроцесс и стройте свой на основании этого знания.
Lesson 170
Слово Канеру
Согласуйте график сборок
Ваш процесс должен быть совместим с темпом выпуска версий ПО. Создает ли компания версии раз в месяц? Раз в неделю? Раз в день? Три раза в день?
Вы не в состоянии управлять билдами, которые появляются слишком быстро. Нужно время, чтоб классифицировать билд (убедиться, что проходят основные тесты) и обновить все компьютеры. Если билды появляются каждый день, вы могли бы тестировать один билд за несколько дней перед обновлением.
Некоторые программисты требуют, чтоб вы сообщали об ошибках только сегодняшнего билда. Все сообщения об ошибках вчерашнего билда не имеют значения, так как дефекты, возможно, уже найдены и исправлены. Это, безусловно, удобно для программистов, но может стать кошмаром для вас, так как вам придется останавливаться и обновлять ПО каждый раз, как появляется новый билд и повторять на нем то, что вы уже делали на предыдущем, перед тем как идти дальше. Задача, которая могла бы занять целый день, может длиться два-три дня с учетом административных проблем и переключений.
Единственное решение, которое мы знаем, это договориться о графике сборок. Это включает в себя соглашение о том, как часто вы будете принимать обновленное ПО в тестирование, какая сборка будет считаться пригодной для тестирования, как ошибки, найденные в предыдущих сборках, будут определяться в новой.
Согласуйте график сборок
Ваш процесс должен быть совместим с темпом выпуска версий ПО. Создает ли компания версии раз в месяц? Раз в неделю? Раз в день? Три раза в день?
Вы не в состоянии управлять билдами, которые появляются слишком быстро. Нужно время, чтоб классифицировать билд (убедиться, что проходят основные тесты) и обновить все компьютеры. Если билды появляются каждый день, вы могли бы тестировать один билд за несколько дней перед обновлением.
Некоторые программисты требуют, чтоб вы сообщали об ошибках только сегодняшнего билда. Все сообщения об ошибках вчерашнего билда не имеют значения, так как дефекты, возможно, уже найдены и исправлены. Это, безусловно, удобно для программистов, но может стать кошмаром для вас, так как вам придется останавливаться и обновлять ПО каждый раз, как появляется новый билд и повторять на нем то, что вы уже делали на предыдущем, перед тем как идти дальше. Задача, которая могла бы занять целый день, может длиться два-три дня с учетом административных проблем и переключений.
Единственное решение, которое мы знаем, это договориться о графике сборок. Это включает в себя соглашение о том, как часто вы будете принимать обновленное ПО в тестирование, какая сборка будет считаться пригодной для тестирования, как ошибки, найденные в предыдущих сборках, будут определяться в новой.
среда, 12 сентября 2012 г.
Lesson 169
Слово Канеру
Просите фичи для повышения тестируемости
Если вы возглавляете тестирование продукта, то вы, вероятно, первый тестировщик, включившийся в проект. Чем раньше вы попросите фичи, помогающие в тестировании, тем больше вероятность того, что программисты и менеджеры согласятся включить их в бюджет и в план. Если они не запланированы и не включены в бюджет, то вы, скорее всего, не получите их.
Главное для вас — обучить команду проекта требовать от вас ту информацию, которая сделает более эффективной процесс разработки продукта и вашу команду. Фичи для повышения тестируемости детально мы обсудили в лекции 137 «Тестируемость это прозрачность и контроль»
Просите фичи для повышения тестируемости
Если вы возглавляете тестирование продукта, то вы, вероятно, первый тестировщик, включившийся в проект. Чем раньше вы попросите фичи, помогающие в тестировании, тем больше вероятность того, что программисты и менеджеры согласятся включить их в бюджет и в план. Если они не запланированы и не включены в бюджет, то вы, скорее всего, не получите их.
Главное для вас — обучить команду проекта требовать от вас ту информацию, которая сделает более эффективной процесс разработки продукта и вашу команду. Фичи для повышения тестируемости детально мы обсудили в лекции 137 «Тестируемость это прозрачность и контроль»
Lesson 168
L — лид, я.
K — камрад, занимается нагрузочным фултайм
S — стажер на полставки
S: Я доделал задачу, что дальше?
L: Бери 386ю, писать еще скрипты. Кстати, K, может отдадим S создание инструмента генерации нагрузки?
K: Можно, я все равно не успеваю.
S : А можно все таки скрипты?
L: Почему? Мы стараемся тебе давать новые разные задачи, чтоб ты не сбежал.
S : Лучше давайте мне обычные рутинные задачи.
Слово Канеру
Контрактная разработка отличается от разработки, регулируемой рынком.
Если компания предоставляет ПО по контракту, договор определяет обязанности сторон. Контракт может указать набор функций, которые должны быть закодированы, протестированы, документированы и поддерживаемы. Ответственность компании находится в рамках выполнения обязательств по договору. Если вы создали то, что было оговорено, клиент должен оплатить это (под клиентом мы подразумеваем человека или компанию). По мере развития продукта клиент может поменять мнение о некоторых аспектах продукта (Кроме того процесс контроля изменений можно использовать, чтоб ослабить позиции заказчика).
Большая часть советов в книгах по разработке ПО применима к большим заказным разработкам по контракту.
Разработка, регулируемая рынком сильно отличается от предыдущей. Клиенты не купят продукт, пока ваша компания его не создаст. На протяжении всего процесса разработки ключевой вопрос — будут ли покупать продукт. Если конкурент быстрее выпустит более привлекательный продукт или проведет лучший маркетинг, тот факт, что ваш продукт соответствует спецификациям будет неважен.
Маркетологи и продавцы будут просить изменения архитектуры на протяжении всего процесса разработки, основанные на актуальной информации, которую они получают от клиентов, конкурентов, прессы.
В контрактной разработке основная ваша активность — проверка на соответствие спецификациям. На продукте, выпускаемом на рынок, ваша работа будет связана с исследованием и тестированием продукта согласно ожиданиям клиента.
K — камрад, занимается нагрузочным фултайм
S — стажер на полставки
S: Я доделал задачу, что дальше?
L: Бери 386ю, писать еще скрипты. Кстати, K, может отдадим S создание инструмента генерации нагрузки?
K: Можно, я все равно не успеваю.
S : А можно все таки скрипты?
L: Почему? Мы стараемся тебе давать новые разные задачи, чтоб ты не сбежал.
S : Лучше давайте мне обычные рутинные задачи.
Слово Канеру
Контрактная разработка отличается от разработки, регулируемой рынком.
Если компания предоставляет ПО по контракту, договор определяет обязанности сторон. Контракт может указать набор функций, которые должны быть закодированы, протестированы, документированы и поддерживаемы. Ответственность компании находится в рамках выполнения обязательств по договору. Если вы создали то, что было оговорено, клиент должен оплатить это (под клиентом мы подразумеваем человека или компанию). По мере развития продукта клиент может поменять мнение о некоторых аспектах продукта (Кроме того процесс контроля изменений можно использовать, чтоб ослабить позиции заказчика).
Большая часть советов в книгах по разработке ПО применима к большим заказным разработкам по контракту.
Разработка, регулируемая рынком сильно отличается от предыдущей. Клиенты не купят продукт, пока ваша компания его не создаст. На протяжении всего процесса разработки ключевой вопрос — будут ли покупать продукт. Если конкурент быстрее выпустит более привлекательный продукт или проведет лучший маркетинг, тот факт, что ваш продукт соответствует спецификациям будет неважен.
Маркетологи и продавцы будут просить изменения архитектуры на протяжении всего процесса разработки, основанные на актуальной информации, которую они получают от клиентов, конкурентов, прессы.
В контрактной разработке основная ваша активность — проверка на соответствие спецификациям. На продукте, выпускаемом на рынок, ваша работа будет связана с исследованием и тестированием продукта согласно ожиданиям клиента.
вторник, 11 сентября 2012 г.
Есть вопросы
Не всегда задаваемые вопросы на собеседовании, хех.
1. Почему вы пригласили на собеседование именно меня?
2. Чем работа в вашей компании выгодно отличается от работы на ваших конкурентов?
3. Какую прибыль приносит вашей компании каждый сотрудник?
4. Почему предыдущий сотрудник, занимавший предлагаемую должность, покинул ее?
5. Каковы планы компании на ближайшие 10 лет?
6. Расскажите о успешных запущенных проектах компании.
7. Расскажите о руководителе.
8. Расскажите о конкурентных преимуществах компании?
9. А о проблемах компании? Как компания пережила кризис, были ли сокращения?
1. Почему вы пригласили на собеседование именно меня?
2. Чем работа в вашей компании выгодно отличается от работы на ваших конкурентов?
3. Какую прибыль приносит вашей компании каждый сотрудник?
4. Почему предыдущий сотрудник, занимавший предлагаемую должность, покинул ее?
5. Каковы планы компании на ближайшие 10 лет?
6. Расскажите о успешных запущенных проектах компании.
7. Расскажите о руководителе.
8. Расскажите о конкурентных преимуществах компании?
9. А о проблемах компании? Как компания пережила кризис, были ли сокращения?
Lesson 167
"Ата обман, Лисса безумие, Дика правда, а богини совести на Олимпе нет." - Герой должен быть один, Олди.
Слово Канеру
Будьте готовы выделять ресурсы на ранней стадии проекта.
Становится общепринятой мудростью тот факт, что тестировщики должны участвовать в ранних стадиях проекта разработки. Тем не менее, группы тестирования, как правило, недоукомплектованы и перегружены. What is so compelling about the results that can be achieved early in development that it is worth pulling a tester off of the crisis du jour?
- Если все, что вы делаете, это отправляете тестировщика на совещания группы разработки
- Если тестировщик не владеет языком программирования, отправка его на ревью кода часто является пустой тратой времени и ненужной демонстрацией его невежества программистам.
Возможна и полезная деятельность тестировщиков на ранних стадиях разработки:
- Огни могут просматривать требования на предмет понятности, тестируемости, недвусмысленности.
- Пока другие артефакты проекта (документация, код и т.п.) создаются — тестируйте их. Не ждите. Начинайте работу с артефактом, когда автор говорит (и вы ему верите) что он еще не готов к просмотру.
- Содействуйте ревью кода. Они принесут большую пользу качеству в дальнейшем. Ваши сотрудники могут сделать проведение ревью проще, взяв на себя логистику (найти комнату, принести печеньки) и управление (составление списков и т. п.). Your staff member learns a lot during the meeting but isn't expected to (and should not) comment on the document under review. To facilitate code reviews well, your staff will require training.
- Подготовьте список аппаратных конфигураций, начните организацию покупки ала аренды оборудования.
- Запросити фичи для увеличения тестируемости. Они займут время на проектирование и разработку. Если вы не включите их в бюджет и график, они не попадут в код.
- Обсудите возможность измерения покрытия кода и использования других инструментов поддержки разработки (таких как Purify или Bounds Checker). Для качественного использования этих инструментов вам будет нужна помощь (время и внимание по крайней мере одного разработчика). Если в бюджет не заложено время разработчиков (по крайней мере половина от времени на тестирование) вы его не получите.
- Подготовьтесь к автоматизации. Подготовка включает в себя договоренности по объему автоматизации и уровне поддержки.
- Изучите инструменты тестирования. Закажите ПО и оборудование для автоматизации тестирования. Узнайте, как все это использовать.
- Закажите внешнюю разработку наборов тестов, если это можно сделать для вашего ПО. Посмотрите на ПО, которое может служить оракулом для вашего, чтоб увеличить объем тестов.
- Изучите рынок продукта, его конкурентов. Станьте опытным пользователем по крайней мере двух приложений с рынка.
Слово Канеру
Будьте готовы выделять ресурсы на ранней стадии проекта.
Становится общепринятой мудростью тот факт, что тестировщики должны участвовать в ранних стадиях проекта разработки. Тем не менее, группы тестирования, как правило, недоукомплектованы и перегружены. What is so compelling about the results that can be achieved early in development that it is worth pulling a tester off of the crisis du jour?
- Если все, что вы делаете, это отправляете тестировщика на совещания группы разработки
- Если тестировщик не владеет языком программирования, отправка его на ревью кода часто является пустой тратой времени и ненужной демонстрацией его невежества программистам.
Возможна и полезная деятельность тестировщиков на ранних стадиях разработки:
- Огни могут просматривать требования на предмет понятности, тестируемости, недвусмысленности.
- Пока другие артефакты проекта (документация, код и т.п.) создаются — тестируйте их. Не ждите. Начинайте работу с артефактом, когда автор говорит (и вы ему верите) что он еще не готов к просмотру.
- Содействуйте ревью кода. Они принесут большую пользу качеству в дальнейшем. Ваши сотрудники могут сделать проведение ревью проще, взяв на себя логистику (найти комнату, принести печеньки) и управление (составление списков и т. п.). Your staff member learns a lot during the meeting but isn't expected to (and should not) comment on the document under review. To facilitate code reviews well, your staff will require training.
- Подготовьте список аппаратных конфигураций, начните организацию покупки ала аренды оборудования.
- Запросити фичи для увеличения тестируемости. Они займут время на проектирование и разработку. Если вы не включите их в бюджет и график, они не попадут в код.
- Обсудите возможность измерения покрытия кода и использования других инструментов поддержки разработки (таких как Purify или Bounds Checker). Для качественного использования этих инструментов вам будет нужна помощь (время и внимание по крайней мере одного разработчика). Если в бюджет не заложено время разработчиков (по крайней мере половина от времени на тестирование) вы его не получите.
- Подготовьтесь к автоматизации. Подготовка включает в себя договоренности по объему автоматизации и уровне поддержки.
- Изучите инструменты тестирования. Закажите ПО и оборудование для автоматизации тестирования. Узнайте, как все это использовать.
- Закажите внешнюю разработку наборов тестов, если это можно сделать для вашего ПО. Посмотрите на ПО, которое может служить оракулом для вашего, чтоб увеличить объем тестов.
- Изучите рынок продукта, его конкурентов. Станьте опытным пользователем по крайней мере двух приложений с рынка.
пятница, 7 сентября 2012 г.
Мысли
Дип флегматик пишет о классификации автоматизации: http://blog.shumoos.com/archives/272
Цитирую:
Можно предложить разные классификационные признаки. Ограничимся следующими: “кто пишет”, “когда пишет”, “кто выполняет”, “какой интерфейс использует тест”.
Наиболее значимые различия:
“кто пишет.[программист | тестировщик]”;
“когда.[до кода(test first) | плюс-минус пара минут от кода (TDD) | после кода (регрессионное тестирование)]”;
“кто выполняет.[ программист | тестировщик ]”;
“интерфейс[ GUI | API ]”.
Далее он рассматривает варианты.
1. {пишет.тестировщик; когда.после кода; выполняет.тестировщик; интерфейс.GUI} - ругает.
2. {пишет.тестировщик; когда.до кода; выполняет.программист; интерфейс.GUI} - хвалит, более менее.
В целом по делу, только непонятно, почему он до сих пор определяет ценность автоматизации тестирования количеством найденных ошибок, в этом он сам себе противоречит. Ну да ладно.
Мы, кстати, используем этот вариант из его классификации:
{пишет.тестировщик; когда.после кода; выполняет.программист; интерфейс.GUI}
Вроде ок.
Ну и непонятно, почему не рассмотрены остальные варианты. Рассмотрю я.
1. -{пишет.тестировщик; когда.после кода; выполняет.тестировщик; интерфейс.GUI}- - этот вариант флегматик уже признал убогим.
2. -{пишет.тестировщик; когда.после кода; выполняет.тестировщик; интерфейс.API}- - эта хрень не нужна.
3. -{пишет.тестировщик; когда.после кода; выполняет.программист; интерфейс.GUI}- - юзаем мы. И нормально. между прочим. По принципу - "программист отцепился от зеленых тестов, программист коммитит зеленые тесты".
4. -{пишет.тестировщик; когда.после кода; выполняет.программист; интерфейс.API}- - как дополнение к предыдущему.
5. -{пишет.тестировщик; когда.до кода; выполняет.тестировщик; интерфейс.GUI}- - это предлагает нам флегматик. Нафик-нафик, выполнять тесты должен тот, кто меняет код.
6. -{пишет.тестировщик; когда.до кода; выполняет.тестировщик; интерфейс.API} -- ни смысла ни радости.
7. -{пишет.тестировщик; когда.до кода; выполняет.программист; интерфейс.GUI}- - к этому мы стремимся. Но пока не получается.
8. -{пишет.тестировщик; когда.до кода; выполняет.программист; интерфейс.API}- - смысл есть, радости нет.
9. -{пишет.программист; когда.после кода; выполняет.тестировщик; интерфейс.GUI}-
10. -{пишет.программист; когда.после кода; выполняет.тестировщик; интерфейс.API}-
11. -{пишет.программист; когда.после кода; выполняет.программист; интерфейс.GUI}-
12. -{пишет.программист; когда.после кода; выполняет.программист; интерфейс.API}-
- хотел бы я посмотреть, как вы заставите программистов делать это.
13. {пишет.программист; когда.до кода; выполняет.тестировщик; интерфейс.GUI}-
14. {пишет.программист; когда.до кода; выполняет.тестировщик; интерфейс.API}-
15. {пишет.программист; когда.до кода; выполняет.программист; интерфейс.GUI}-
16. {пишет.программист; когда.до кода; выполняет.программист; интерфейс.API}-
- а нафига нужны в таком случае тестировщики?
Да, я не ответил флегматику в его блоге ибо у него нет openId, а регаццо влом.
Цитирую:
Можно предложить разные классификационные признаки. Ограничимся следующими: “кто пишет”, “когда пишет”, “кто выполняет”, “какой интерфейс использует тест”.
Наиболее значимые различия:
“кто пишет.[программист | тестировщик]”;
“когда.[до кода(test first) | плюс-минус пара минут от кода (TDD) | после кода (регрессионное тестирование)]”;
“кто выполняет.[ программист | тестировщик ]”;
“интерфейс[ GUI | API ]”.
Далее он рассматривает варианты.
1. {пишет.тестировщик; когда.после кода; выполняет.тестировщик; интерфейс.GUI} - ругает.
2. {пишет.тестировщик; когда.до кода; выполняет.программист; интерфейс.GUI} - хвалит, более менее.
В целом по делу, только непонятно, почему он до сих пор определяет ценность автоматизации тестирования количеством найденных ошибок, в этом он сам себе противоречит. Ну да ладно.
Мы, кстати, используем этот вариант из его классификации:
{пишет.тестировщик; когда.после кода; выполняет.программист; интерфейс.GUI}
Вроде ок.
Ну и непонятно, почему не рассмотрены остальные варианты. Рассмотрю я.
1. -{пишет.тестировщик; когда.после кода; выполняет.тестировщик; интерфейс.GUI}- - этот вариант флегматик уже признал убогим.
2. -{пишет.тестировщик; когда.после кода; выполняет.тестировщик; интерфейс.API}- - эта хрень не нужна.
3. -{пишет.тестировщик; когда.после кода; выполняет.программист; интерфейс.GUI}- - юзаем мы. И нормально. между прочим. По принципу - "программист отцепился от зеленых тестов, программист коммитит зеленые тесты".
4. -{пишет.тестировщик; когда.после кода; выполняет.программист; интерфейс.API}- - как дополнение к предыдущему.
5. -{пишет.тестировщик; когда.до кода; выполняет.тестировщик; интерфейс.GUI}- - это предлагает нам флегматик. Нафик-нафик, выполнять тесты должен тот, кто меняет код.
6. -{пишет.тестировщик; когда.до кода; выполняет.тестировщик; интерфейс.API} -- ни смысла ни радости.
7. -{пишет.тестировщик; когда.до кода; выполняет.программист; интерфейс.GUI}- - к этому мы стремимся. Но пока не получается.
8. -{пишет.тестировщик; когда.до кода; выполняет.программист; интерфейс.API}- - смысл есть, радости нет.
9. -{пишет.программист; когда.после кода; выполняет.тестировщик; интерфейс.GUI}-
10. -{пишет.программист; когда.после кода; выполняет.тестировщик; интерфейс.API}-
11. -{пишет.программист; когда.после кода; выполняет.программист; интерфейс.GUI}-
12. -{пишет.программист; когда.после кода; выполняет.программист; интерфейс.API}-
- хотел бы я посмотреть, как вы заставите программистов делать это.
13. {пишет.программист; когда.до кода; выполняет.тестировщик; интерфейс.GUI}-
14. {пишет.программист; когда.до кода; выполняет.тестировщик; интерфейс.API}-
15. {пишет.программист; когда.до кода; выполняет.программист; интерфейс.GUI}-
16. {пишет.программист; когда.до кода; выполняет.программист; интерфейс.API}-
- а нафига нужны в таком случае тестировщики?
Да, я не ответил флегматику в его блоге ибо у него нет openId, а регаццо влом.
Lesson 166
Слово Канеру
Эволюционные жизненные циклы приносят фичи в жертву времени
В эволюционных подходах к разработке ПО команда разработки реализует по одной фиче за раз. Они проектируют фичу, кодируют, тестируют и правят ее. Когда фича интегрирована продукт, соответствует стандарту качества группы, берется следующая фича (Gilb 1997 и Beck 1999).
Команда разработки может выпустить продукт в любой момент (последнюю версию, прошедшую тестирование). Разница между сегодняшней версией и версией, которая появится через месяц - в следующей версии будет больше фич. И они работают. Нет компромисса между временем и качеством.
У этого подхода есть свои проблемы. Представьте, что вы менеджер по маркетингу или технический писатель. Подойдите к руководителю проекта и спросите: «Какие фичи есть в продукте?». Ответ, естественно, будет: «Это зависит от того, когда мы его хотим поставить». Любой, кто должен знать, что будет в продукте во время релиза, найдет эволюционный подход сложным. Некоторые считают, что проблема неопределенного набора фич и рисков легче управляется в водопаде, нежели при использовании эволюционного подхода.
Эволюционные жизненные циклы приносят фичи в жертву времени
В эволюционных подходах к разработке ПО команда разработки реализует по одной фиче за раз. Они проектируют фичу, кодируют, тестируют и правят ее. Когда фича интегрирована продукт, соответствует стандарту качества группы, берется следующая фича (Gilb 1997 и Beck 1999).
Команда разработки может выпустить продукт в любой момент (последнюю версию, прошедшую тестирование). Разница между сегодняшней версией и версией, которая появится через месяц - в следующей версии будет больше фич. И они работают. Нет компромисса между временем и качеством.
У этого подхода есть свои проблемы. Представьте, что вы менеджер по маркетингу или технический писатель. Подойдите к руководителю проекта и спросите: «Какие фичи есть в продукте?». Ответ, естественно, будет: «Это зависит от того, когда мы его хотим поставить». Любой, кто должен знать, что будет в продукте во время релиза, найдет эволюционный подход сложным. Некоторые считают, что проблема неопределенного набора фич и рисков легче управляется в водопаде, нежели при использовании эволюционного подхода.
Lesson 165
Слово Канеру
Водопад приносит качество в жертву времени
Модель водопада описывает жизненный цикл для управления проектами, проходящий через следующие фазы:
- Определение проблемы (что мы пытаемся создать и почему)
- Определение требований
- Внутренний и внешний дизайн
- Кодирование
- Тестирование
- Установка
- Поддержка
- Судебные иски от разочарованных клиентов
- Определение проблемы (для следующей версии продукта)
Модель получила свое название от диаграммы фаз, которая для некоторых людей выглядит как водопад. Термин водопад описывает линейный характер подхода. Вы переходите от одного этапа к другому, при этом сложно вернуться
На практике, определенное количество возвратов к предыдущему этапу случается (если мы обнаружили ошибки или невозможность реализации требований, пытаясь создать продукт им удовлетворяющий), но так делать не рекомендуется.
Вариация водопада описывает более широкую роль тестирования. Это так называемая V-модель. В конце каждого этапа тесты формально оценивают продукт. Например, обзор (и аппрув) тестировщиками требований в конце фазы определения требований. Также они пишут серию тестов, которые должны выполниться на поздних этапах перед вводом соответствующих частей продукта в эксплуатацию.
Водопад (с V или без) выглядит как аккуратный процесс, но что происходит в проектах, не успевающих предоставить все, что нужно для определенной фазы? Что делать, если проект отстает от графика?
Большинство программных продуктов значительно отстает от первоначального графика. Мы слышали советы опытных людей, которые сводятся к «хорошо управляемые проекты не имеют таких проблем». Но программные продукты несут в себе большое количество рисков. Изменения всегда опаздывают. Сказать «этого не произойдет» - выдать желаемое за действительное.
Итак, что же произойдет, если проект значительно отстанет от графика?
Используя водопад в определенный момент времени вы получите продукт, все функции которого спроектированы и большинство из них закодированы. Большая часть денег на проект уже потрачена. Ключевой компромисс — между временем и качеством. Исправить ошибка и опоздать с поставкой или поставить продукт с ошибками.
Это классическая борьба между руководителями проекта и тестировщиками: предоставить забагованный или предоставить поздно. В ответ многие тестировщики требуют строгого соблюдения модели водопада. Это не решение проблемы. Водопаду присущ компромисс между временем и надежностью на поздней стадии разработки. Вам не вырваться из этой ловушки.
Подумайте, прежде чем выступать за модель разработки водопад (V-модель).
Есть несколько других проблем с V-моделью. Процесс написания подробных тестов перед созданием кода рискован. С изменениями архитектуры продукта тесты устаревают. К тому времени, когда код написан, у вас есть описание аспектов продукта, которые никогда не будут написаны или которые были написаны совсем по другому, чем первоначально планировалось. На многих проектах все эти документы — а еще хуже, если еще и код тестов, данные экспериментов — не принесли совершенно ничего. Они устарели до того как появилась необходимость в них. Сторонники V-процесса сказали бы, что продукты группы тестирования могут быть использованы программистами, чтоб помочь обнаружить неясности или проблемы в разрабатываемой ими функции. Мы согласны, что ревью архитектуры могут ее улучшить и предотвратить проблемы. Но если это является целью, то мы полагаем что инспекции кода гораздо больше способствуют качеству и занимают меньше времени, чем написание тестов, которые никогда не будут работать. Поэтому мы предлагаем проводит ревью архитектуры и кода не дожидаясь окончания этапа, а тогда, когда это можно начинать делать.
Водопад приносит качество в жертву времени
Модель водопада описывает жизненный цикл для управления проектами, проходящий через следующие фазы:
- Определение проблемы (что мы пытаемся создать и почему)
- Определение требований
- Внутренний и внешний дизайн
- Кодирование
- Тестирование
- Установка
- Поддержка
- Судебные иски от разочарованных клиентов
- Определение проблемы (для следующей версии продукта)
Модель получила свое название от диаграммы фаз, которая для некоторых людей выглядит как водопад. Термин водопад описывает линейный характер подхода. Вы переходите от одного этапа к другому, при этом сложно вернуться
На практике, определенное количество возвратов к предыдущему этапу случается (если мы обнаружили ошибки или невозможность реализации требований, пытаясь создать продукт им удовлетворяющий), но так делать не рекомендуется.
Вариация водопада описывает более широкую роль тестирования. Это так называемая V-модель. В конце каждого этапа тесты формально оценивают продукт. Например, обзор (и аппрув) тестировщиками требований в конце фазы определения требований. Также они пишут серию тестов, которые должны выполниться на поздних этапах перед вводом соответствующих частей продукта в эксплуатацию.
Водопад (с V или без) выглядит как аккуратный процесс, но что происходит в проектах, не успевающих предоставить все, что нужно для определенной фазы? Что делать, если проект отстает от графика?
Большинство программных продуктов значительно отстает от первоначального графика. Мы слышали советы опытных людей, которые сводятся к «хорошо управляемые проекты не имеют таких проблем». Но программные продукты несут в себе большое количество рисков. Изменения всегда опаздывают. Сказать «этого не произойдет» - выдать желаемое за действительное.
Итак, что же произойдет, если проект значительно отстанет от графика?
Используя водопад в определенный момент времени вы получите продукт, все функции которого спроектированы и большинство из них закодированы. Большая часть денег на проект уже потрачена. Ключевой компромисс — между временем и качеством. Исправить ошибка и опоздать с поставкой или поставить продукт с ошибками.
Это классическая борьба между руководителями проекта и тестировщиками: предоставить забагованный или предоставить поздно. В ответ многие тестировщики требуют строгого соблюдения модели водопада. Это не решение проблемы. Водопаду присущ компромисс между временем и надежностью на поздней стадии разработки. Вам не вырваться из этой ловушки.
Подумайте, прежде чем выступать за модель разработки водопад (V-модель).
Есть несколько других проблем с V-моделью. Процесс написания подробных тестов перед созданием кода рискован. С изменениями архитектуры продукта тесты устаревают. К тому времени, когда код написан, у вас есть описание аспектов продукта, которые никогда не будут написаны или которые были написаны совсем по другому, чем первоначально планировалось. На многих проектах все эти документы — а еще хуже, если еще и код тестов, данные экспериментов — не принесли совершенно ничего. Они устарели до того как появилась необходимость в них. Сторонники V-процесса сказали бы, что продукты группы тестирования могут быть использованы программистами, чтоб помочь обнаружить неясности или проблемы в разрабатываемой ими функции. Мы согласны, что ревью архитектуры могут ее улучшить и предотвратить проблемы. Но если это является целью, то мы полагаем что инспекции кода гораздо больше способствуют качеству и занимают меньше времени, чем написание тестов, которые никогда не будут работать. Поэтому мы предлагаем проводит ревью архитектуры и кода не дожидаясь окончания этапа, а тогда, когда это можно начинать делать.
вторник, 4 сентября 2012 г.
Lesson 164
Слово Канеру
Позволь менеджеру проекта выбрать жизненный цикл продукта.
Модель жизненного цикла продукта это описание архитектуры продукта и процессов его разработки от первой мысли о нем до того, как он будет представлен публике и начнет использоваться.
Мы отвергаем идею единственного лучшего жизненного цикла разработки ПО. Каждая модель фиксирует определенные аспекты разработки и оставляет другие открытыми для пересмотра. Модели жизненных циклов отличаются в тех аспектах, которые они оставляют открытыми.
Некоторые компании следуют стандартным моделям, но, по нашему опыту, всегда остается место для ручной настройки руководителем проекта. Каждый руководитель выбирает тот подход, который регламентирует то, чем трудно плавно управлять и оставляет открытыми вопросы, в которых он силен. Каждый выбор несет в себе риски и последствия. Выбор не всегда удобен группе тестирования и не всегда удается выбрать именно вам. В той мере, в которой можно что-то изменять, право выбора принадлежит руководителю проекта.
В следующих двух уроках мы рассмотрим водопад и эволюционные жизненные циклы. Водопад, часто защищаемый тестировщиками-консультантами, не всегда в наших интересах. Эволюционная модель лучше для тестировщиков, но может быть тяжелее для других членов команды.
Мы не считаем, что вы должны выступать за эволюционный подход. Мы не утверждаем, что вы должны проповедовать определенный жизненный цикл. Мы говорим, что выбранные подходы сильно отличаются и выбор не всегда является простым.
Позволь менеджеру проекта выбрать жизненный цикл продукта.
Модель жизненного цикла продукта это описание архитектуры продукта и процессов его разработки от первой мысли о нем до того, как он будет представлен публике и начнет использоваться.
Мы отвергаем идею единственного лучшего жизненного цикла разработки ПО. Каждая модель фиксирует определенные аспекты разработки и оставляет другие открытыми для пересмотра. Модели жизненных циклов отличаются в тех аспектах, которые они оставляют открытыми.
Некоторые компании следуют стандартным моделям, но, по нашему опыту, всегда остается место для ручной настройки руководителем проекта. Каждый руководитель выбирает тот подход, который регламентирует то, чем трудно плавно управлять и оставляет открытыми вопросы, в которых он силен. Каждый выбор несет в себе риски и последствия. Выбор не всегда удобен группе тестирования и не всегда удается выбрать именно вам. В той мере, в которой можно что-то изменять, право выбора принадлежит руководителю проекта.
В следующих двух уроках мы рассмотрим водопад и эволюционные жизненные циклы. Водопад, часто защищаемый тестировщиками-консультантами, не всегда в наших интересах. Эволюционная модель лучше для тестировщиков, но может быть тяжелее для других членов команды.
Мы не считаем, что вы должны выступать за эволюционный подход. Мы не утверждаем, что вы должны проповедовать определенный жизненный цикл. Мы говорим, что выбранные подходы сильно отличаются и выбор не всегда является простым.
Lesson 163
Сестра подогнала сувенирный карандашик.
Карандашик будет использоваться на стендап митингах. Вписывать ответственных и мотивировать безответственных, значится.
Слово Канеру
Проекты включают в себя компромисс между фичами, качеством, временем и деньгами.
Работа менеджера проекта — предоставить набор фич с определенным уровнем качества, вовремя и за бюджет. Это сложный компромисс.
Фичи Выбери верный набор функций, так, чтобы они были не слишком дороги для того, чтоб заинтересованные стороны не захотели их приобретать.
Качество Создайте продукт, но остерегайтесь тратить бесконечное количество ресурсов на то, чтоб убедиться, что продукт прекрасно работает при любых мыслимых обстоятельствах.
Время Запустите продукт в производство как можно скорее.
Стоимость Создайте продукт за максимально низкую цену. Стоимость включает в себя деньги и другие возможные издержки. В то время, как вы используете критичные ресурсы (специально обученный персонал или уникальные машины) в вашем проекте, этот ресурс недоступен для других проектов.
Мы охарактеризовали это как компромисс, так как менеджер проекта может получить больше в одном измерении, пожертвовав другим. Например, можно получить больше фич, если вы потратите больше времени на создание продукта.
Если вы хотите понять кажущиеся странными решения менеджера проекта, попробуйте понять, как они влияют на каждую переменную (фичи, качество, время до релиза подукта, стоимость).
 |
| Альбом: office |
Карандашик будет использоваться на стендап митингах. Вписывать ответственных и мотивировать безответственных, значится.
Слово Канеру
Проекты включают в себя компромисс между фичами, качеством, временем и деньгами.
Работа менеджера проекта — предоставить набор фич с определенным уровнем качества, вовремя и за бюджет. Это сложный компромисс.
Фичи Выбери верный набор функций, так, чтобы они были не слишком дороги для того, чтоб заинтересованные стороны не захотели их приобретать.
Качество Создайте продукт, но остерегайтесь тратить бесконечное количество ресурсов на то, чтоб убедиться, что продукт прекрасно работает при любых мыслимых обстоятельствах.
Время Запустите продукт в производство как можно скорее.
Стоимость Создайте продукт за максимально низкую цену. Стоимость включает в себя деньги и другие возможные издержки. В то время, как вы используете критичные ресурсы (специально обученный персонал или уникальные машины) в вашем проекте, этот ресурс недоступен для других проектов.
Мы охарактеризовали это как компромисс, так как менеджер проекта может получить больше в одном измерении, пожертвовав другим. Например, можно получить больше фич, если вы потратите больше времени на создание продукта.
Если вы хотите понять кажущиеся странными решения менеджера проекта, попробуйте понять, как они влияют на каждую переменную (фичи, качество, время до релиза подукта, стоимость).
суббота, 1 сентября 2012 г.
Lesson 162
Слово Канеру
Изменения всегда опаздывают.
Многие традиционные подходы к управлению проектами предназначены для ограничения и контроля изменений, но другие подходы готовы к ним (например см. Weinberg 1992, Beck 1999, Beck et al. 2001, и Krutchen 2000). Тем не менее, все подходы к управлению проектами имеют дело с изменениями.
Представьте себе создание нового стула, взамен сломанного. Понятно, зачем он нужен, что с ним будут делать и каким нагрузкам он будет подвержен. Вы сможете найти людей, которые сделают стул очень похожий на тот, что был у вас.
В программном обеспечении все не так. В большинстве проектов никто не создавал именно этот продукт раньше, и даже если у других такой продукт есть, то эти люди работают не у нас. Кроме того, люди, которые его используют, не использовали его раньше. Хотя они и имеют представление о том, чего хотят, но не знают, как сформулировать свои потребности, потому что:
- Они не в курсе всех своих требований.
- Их требования меняются, поскольку они пробуют использовать ранние версии продукции конкурентов. Они открывают новые способы использования ПО и придумывают новые цели, которых они могли бы достичь, но пока не могут.
- У разных заинтересованных сторон разные потребности, часто конфликтующие. Ни один документ не вместит себя сбалансированные формулировки противоречивых требований.
Кроме того, по мере того, как компоненты, инструменты и навыки будут развиваться, ожидаемые затраты для обеспечения заданного уровня будут меняться, делая более простым или сложным удовлетворение потребностей заказчика.
Требования являются результатом непрерывной борьбы между тем, что мы хотим и тем, что мы можем (Bach 1999a). По мере развития проекта требования меняются.
Изменения всегда опаздывают.
Многие традиционные подходы к управлению проектами предназначены для ограничения и контроля изменений, но другие подходы готовы к ним (например см. Weinberg 1992, Beck 1999, Beck et al. 2001, и Krutchen 2000). Тем не менее, все подходы к управлению проектами имеют дело с изменениями.
Представьте себе создание нового стула, взамен сломанного. Понятно, зачем он нужен, что с ним будут делать и каким нагрузкам он будет подвержен. Вы сможете найти людей, которые сделают стул очень похожий на тот, что был у вас.
В программном обеспечении все не так. В большинстве проектов никто не создавал именно этот продукт раньше, и даже если у других такой продукт есть, то эти люди работают не у нас. Кроме того, люди, которые его используют, не использовали его раньше. Хотя они и имеют представление о том, чего хотят, но не знают, как сформулировать свои потребности, потому что:
- Они не в курсе всех своих требований.
- Их требования меняются, поскольку они пробуют использовать ранние версии продукции конкурентов. Они открывают новые способы использования ПО и придумывают новые цели, которых они могли бы достичь, но пока не могут.
- У разных заинтересованных сторон разные потребности, часто конфликтующие. Ни один документ не вместит себя сбалансированные формулировки противоречивых требований.
Кроме того, по мере того, как компоненты, инструменты и навыки будут развиваться, ожидаемые затраты для обеспечения заданного уровня будут меняться, делая более простым или сложным удовлетворение потребностей заказчика.
Требования являются результатом непрерывной борьбы между тем, что мы хотим и тем, что мы можем (Bach 1999a). По мере развития проекта требования меняются.
Подписаться на:
Сообщения (Atom)