SCRUM или рыночные отношения

В этом посте я отступлю от темы тестирования и коснусь управления разработкой, a именно, популярной и многими любимой технологии SCRUM. Эта технология оценки трудоемкости и управления задачами обладает многими преимуществами перед классическим водопадом. Она проста и понятна.  За исключением одного момента – Story point. Эти условные “баллы сложности” вначале всегда вызывают вопросы – что же это?
Классики советуют не думать о них в понятиях времени, тем не менее, в большинстве случаев использования, поинты приводятся к часам, ну или дням, кому как удобнее. Думать о storypoint как о строчках кода - тоже неправильно. Количество строк кода очень сложно определить заранее и зачастую это не показатель.
Когда я рассказывал о scrum своим коллегам, я получил вопрос – каков же физический смысл в этих оценках?
Физический смысл донельзя прост – это деньги. Смотрите, что получается…

Давайте для простоты приравняем очко сложности ста рублям.  Тогда задачи будут оцениваться в деньгах. Процедура оценки задач станет торговлей – руководитель проекта выставляет задачу на торги, эту задачу один программист готов выполнить за 1000 рублей, другой за 750. Остальная практика оценки задач не меняется, не буду описывать – все по скраму. Мы избавляемся от преобразований баллов в человеко-часы, это больше не нужно. Программисту сразу понятно, сколько он заработает и сколько он теряет занимаясь прокастинацией. Сроки отходят на второй план, они будут минимальны.
Думать о сложности в понятиях денег проще и руководителю и программисту. Руководитель имеет перед собой общий бюджет проекта, как правило согласованный заранее, его задача не выйти за эти пределы. Думая о проекте в абстрактных единицах легко забыть о реальности, а тут – живые деньги, которые получит программист за выполнение определенной задачи. Понятия “хороший” программист и “плохой” программист обретают свой физический смысл – хороший выполняет задачи за более короткое время и, о чудо!, получает больше. Причем сразу, не дожидаясь признания коллег и начальства, зачастую субъективного.  Программист волен в определении сроков выполнения той или иной задачи – ему все равно заплатят по сложности. Мотивация налицо – быстрее делаешь – больше получаешь. Вопрос качества пока отложим, тестировщики должны получать зарплату по другому, но очевидно, нельзя засчитывать задачу выполненной без ее принятия ответственным лицом. Это относится не только к скраму.  Программист волен в распределении времени в пределах задачи, сколько потратить на код а сколько на изучение проблемы.  Смысл в графике рабочего времени снижается до минимума, достаточно определить время общих собраний или вовсе обойтись смс рассылкой.

Я надеюсь, что такой взгляд на SCRUM вызовет обсуждение, жду ваши комментарии

Главный вопрос

Не буду тянуть резину, главный вопрос на который руководитель должен ответить - что мы должны тестировать. Определение границ проекта поможет отсечь лишнее и не упустить необходимого. На первый взгляд ответ прост и банален - программисты пишут - мы проверяем - тестируем софт, что же еще! Обычно такова точка зрения бывшего программиста.
К примеру - система пожарной охраны, датчики покупные, софт ваш. Казалось бы, зачем тестировать датчики? Однако, если датчики интеллектуальные - в из прошивке тоже могут содержаться ошибки и ваша система также будет работать некорректно. Если же ваша система не подразумевает обработку сигналов датчиков, а лишь осуществляет трансляцию данных от них на уровень выше, то какая вам разница, есть ли в этих данных ошибки или нет.  
Правильный ответ лучше всего получить в "продажном отделе" (не любят они когда я их так называю :)) . Тестировать надо то, что вы продаёте, если, конечно, вы это продаёте.

Новая работа, новые коллеги

Вот еще вчера  вы были инженером, а сегодня вас позвал директор и сказал - Вася! Ты теперь начальник группы тестирования, в помощь тебе вот эти двое, ибо самые молодые, давай, жду от тебя план действий. Знакомо? Многим руководителям пришлось пройти именно по такому пути. 

Достаточно популярный вопрос на форумах тестировщиков, а в особенности их начальников - как построить группу(отдел, сектор) тестирования с нуля. Один раз мне это уже удалось, и вот, новая работа, старые задачи - решением руководства создана группа тестирования во главе с вашим покорным слугой.  Собственно, "вторая часть марлезонского балета" и будет основным предметом дальнейших публикаций в этом блоге. 

Прошло два месяца с момента последнего поста, один из них нерабочий, второй - рабочий донельзя. Нервная и физическая нагрузка у всей конторы зашкаливает за красную линию.  Близятся бАльшие испытания, "испытания всего"... Ударная сборка стендов, подготовка оборудования, написаний методик и программ испытаний умножается на финансовый кризис. Люди работают на износ, и самое худшее, САМОЕ ХУДШЕЕ, не то, что мы сдачу вовремя почти ничего не получим сверху, не то, что за несдачу вовремя с нас снимут три шкуры, а то, что совершенно непонятно, когда это закончится. 

No goals - no results. Аксиома, блин. 
Самая худшая цель - "сделать все".  Самый худший срок - "как можно быстрее"

Редеплой

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

BUG удрал.

Опять о неработе. BUG сбежал. Упустили, теперь будем искать по новой. Ребята шутят - его пофиксили уборщицы

Мы поймали BUG!

Декабрь. Снег. Лабораторя  наша в подвале, форточка под самым потолком в  тридцати сантиметрах над землёй. Придя с обеда мы обнаружили, что посреди лаборатории ползает BUG. Самый настоящий, черный такой, здоровый.  Назвали "Косяк", теперь это наш талисман. Ищем ему подходящий инсектарий :)