По мне, так ТЗ — это договор о намерениях между Заказчиком и Исполнителем. Один намеревается что-то такое сделать, а другой — как-то это использовать. :)
А то, что получится в итоге — это результат уточнений и компромиссов между Заказчиком и Исполнителем. И частенько бывает, что он не совсем похож на то, что первоначально описывалось в ТЗ.
Мне понравилось про дальтонизм!
Мой научный руководитель — дальтоник. И вот я ему показываю результаты моих исследований. И получается диалог в стиле Жванецкого об Авазе:
Я: Вот тут зелёным нарисовано то, что было, а тут то, что стало. (Зелёным и красным соответственно)
НР: Где?
Я: Вот тут и тут.
НР: Где тут?
Я: Ну вот. Здесь.
НР: Да где здесь-то?
И вот минут пять пререкались, пока я не сказал про красный и зелёный. Вот тут-то всё и выяснилось.
Ну это тоже не очевидно. Ищешь разработчика ADO.Net, а в резюме написано, что кандидат получил сертификат ОхренительногоДевелопера. Есть там то, что нужно, или нет? Рыться в Инете и выяснять это? Лень. А на память Вряд ли каждая убощица знает, что входит в экзамены.
Рассказать — это ещё не значит, что все согласны. А несогласные могут оказаться дополнительными трудностями на пути антикризисных действий. А их, трудностей, и так будет не мало.
Если мы говорим о кризисных проектах, то я бы ещё поставил пунктом 0 признание действующими лицами того, что проект в кризисе.
А то бывает так, что команда проекта думает, что всё плохо, а руководители предприятия — что всё просто замечательно и ничего спасать не надо. Или наооборот, руководство считает, что с проектом всё плохо, а команда — что всё идёт, как доктор прописал.
А как вы рассчитывали объём рынка? Если продавать расширения по $2-5, то их надо продавать как минимум десяток тысяч в месяц. При таком обилии вариантов на рынке управления задачами и проектами трудно поверить в возможность продаж такого количества расширений.
Или есть ещё соображения?
Трекинг задач?
Такой же, как и везде. Ставишь дату окончания и/или привязываешь к контрольной точке. После этого имеешь уведомления, отмеченные выполненные, невыполненные и просроченные задачи.
Я писал про цели тестирования. 1 и 2 — это состовляющие проверки качества.
Что касается остального, то я конечно понимаю, что тестерам можно поручить написание отчётов для обоснования расхода средств (цель 3). Но с таким же успехом мы можем поручить им мыть полы в офисе. Какое это имеет отношение к тестированию?
Встречаются два подхода к цели тестирования:
1. цель тестирования — это поиск багов.
2. цель тестирования — проверка качества продукта. Проще говоря, тестеры должны ставить диагноз и нести за этот диагноз ответственность.
Вроде очевидно, что первая цель странная, т.к. баги можно искать до полного посинения и всё равно они останутся. То есть цель недостижимая.
Но, к моему удивлению, практически все руководители проектов (да и прочие руководители), разработчики (это как раз не удивительно :)) и, часто, сами тестеры считают целью тестирования вылавливание багов. НА словах они соглашаются с объяснением о качестве, но по-факту…
Да уж, ещё немного и он начнёт говорит, что amazon работает себе в убыток. И на планшете они не собираются зарабатывать, и книги не больше 10 баксов, и авторам платить больше, и дата центр самые лучшие и самые дешёвые.
А на вопрос о том, как этого удалось добиться, неожиданный ответ. Издержки, оказывается, сокращаем. Кто бы мог подумать :). И ещё дефекты на корню пресекаем. Ужасно, блин, интересно.
Программирование — это пока исскуство, но по той причине, что не изобретены (или повсеместно не внедрены) методы, позволяющие получать гарантировано ожидаемый результат. Как научимся, программирование станет инженерией. У Макконелла целая книжка про это есть.
Я где-то пример читал о том, что в 19-м веке половина построенных больших мостов разваливалось. И построение мостов каждый раз было исскуством. А теперь это уже инжененрия. Всё посчитали, организовали и вперёд.
С самого начала Кармак оговаривается, что качество кода — не самое важное в разработке ПО, и «признание этого факта не является каким-то моральным поражением. Ценность — вот что вы пытаетесь создать, а качество — всего лишь один из аспектов, наряду со стоимостью, функционалом и другими факторами. Было много чрезвычайно успешных и уважаемых игр, полных багов и постоянно вылетающих; так что применение стиля программирования космических челноков в игровой разработке было бы идиотизмом. Однако, качество всё равно имеет значение».
А какие вы ограничения поставили? Например, в пуле не больше 5 фич на человека, ждут ревью не больше 2 фич на разработчикуа, ждут тестирования не больше 2 фич на тестера и т.п.
И куда попадают найденные ошибки? В отдельный пул? Есть ли по ним ограничения?
А то, что получится в итоге — это результат уточнений и компромиссов между Заказчиком и Исполнителем. И частенько бывает, что он не совсем похож на то, что первоначально описывалось в ТЗ.
ТЗ описывает то, что должна быть сделано. А Техпроект — как должно быть сделано.
Мой научный руководитель — дальтоник. И вот я ему показываю результаты моих исследований. И получается диалог в стиле Жванецкого об Авазе:
Я: Вот тут зелёным нарисовано то, что было, а тут то, что стало. (Зелёным и красным соответственно)
НР: Где?
Я: Вот тут и тут.
НР: Где тут?
Я: Ну вот. Здесь.
НР: Да где здесь-то?
И вот минут пять пререкались, пока я не сказал про красный и зелёный. Вот тут-то всё и выяснилось.
Рассказать — это ещё не значит, что все согласны. А несогласные могут оказаться дополнительными трудностями на пути антикризисных действий. А их, трудностей, и так будет не мало.
А то бывает так, что команда проекта думает, что всё плохо, а руководители предприятия — что всё просто замечательно и ничего спасать не надо. Или наооборот, руководство считает, что с проектом всё плохо, а команда — что всё идёт, как доктор прописал.
Или есть ещё соображения?
Такой же, как и везде. Ставишь дату окончания и/или привязываешь к контрольной точке. После этого имеешь уведомления, отмеченные выполненные, невыполненные и просроченные задачи.
Что касается остального, то я конечно понимаю, что тестерам можно поручить написание отчётов для обоснования расхода средств (цель 3). Но с таким же успехом мы можем поручить им мыть полы в офисе. Какое это имеет отношение к тестированию?
1. цель тестирования — это поиск багов.
2. цель тестирования — проверка качества продукта. Проще говоря, тестеры должны ставить диагноз и нести за этот диагноз ответственность.
Вроде очевидно, что первая цель странная, т.к. баги можно искать до полного посинения и всё равно они останутся. То есть цель недостижимая.
Но, к моему удивлению, практически все руководители проектов (да и прочие руководители), разработчики (это как раз не удивительно :)) и, часто, сами тестеры считают целью тестирования вылавливание багов. НА словах они соглашаются с объяснением о качестве, но по-факту…
А на вопрос о том, как этого удалось добиться, неожиданный ответ. Издержки, оказывается, сокращаем. Кто бы мог подумать :). И ещё дефекты на корню пресекаем. Ужасно, блин, интересно.
Я где-то пример читал о том, что в 19-м веке половина построенных больших мостов разваливалось. И построение мостов каждый раз было исскуством. А теперь это уже инжененрия. Всё посчитали, организовали и вперёд.
Цитата оттуда:
И куда попадают найденные ошибки? В отдельный пул? Есть ли по ним ограничения?