Необычная методика разработки

Добрый день, уважаемые форумчане!

Тезисно распишу ситуацию:

1) Есть команда разработчиков и большой проект.

2) Разработка функционала меня немного привела в ступор: тот функционал, ради которого создавался проект еще не готов, зато других фич порядком хватает.

3) В итоге тест план по которому рассчитывалось проводить тестирование - бесполезен!

4) Время выделялось только на основной функционал, но он не готов, а тестировать все эти фичи даже невозмно. (см. п 5)

5) Смешно до слез, но даже не реализована регистрация.

Дедлайн через 3-4 недели.

О кол-ве костылей которые будут я даже говорить не буду.

Если кто нибудь сталкивался с подобной ситуацией, отпишите пожалуйста.

если ты никак не может влиять на процесс разработки/тестирования, то ... увольняться? :)

Хотелось бы услышать конструктивный ответ.

это (увольнение) один из вариантов, почему нет?

Ну либо работать 7 дней в неделю, чтобы успеть к дедлайну - такой вариант ещё есть.

И кстати ничего необычного в такой ситуации нет - так много где.. неверно рассчитали, что-то не учли, вообще не планировали трудозатраты, вот оно и вышло.

А в чем суть темы-то? Отписаться у кого так? К примеру, у меня так. Дальше-то что?

Хе-хе, ну ты попал, парень!) Это что - стартап не случаем? Считай, что ты в АДУ! Через пару лет, если выдержишь, будешь воспринимать более спокойно такой метод разработки. Причем ещё более смешно, когда будете сдавать проект, половину фич, которые ты протестировал и уделил внимание, просто вырежут, а во вторая половина будет изменена без твоего ведома. В итоге, ты окажешься в полной Ж и пойдешь бить морду разработчикам, пм (если есть, хотя сомневаюсь) и ещё к-н, кто у вас там останется...

А если конструктивно вижу два варианта:

1. Увольняешься и ищешь аналогичную г-но-контору

2. Считаешь себя ковбоем на диком западе, забываешь о тестплане как об устаревшем г-не (Как тестируют в Гугл как раз пишут, что тестпланы быстро устаревают и в быстром мире он не годится) и динамически подстраиваешься под процесс разработки. В данной ситуации убеждать руководство, что так дела не делаются, скорее всего весу не хватит.

Удачи и терпения!

В чем именно проблема?

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

А регистрация  - это основной функционал? Руками можете пользователя в БД создать?

Если ты не можешь влиять на процесс разработки, то выдохни и отойди в сторону. Зачем тратить свои нервы на то, что не можешь изменить?

есть ещё один вариант:

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

А если конструктивно вижу два варианта:

1. Увольняешься и ищешь аналогичную г-но-контору

А какой в этом конструктив - найти аналогичную контору?)

И, кстати, менеджер у этой разработки есть?

Менеджер есть.

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

Регистрацию привел в пример. 

 

А если конструктивно вижу два варианта:

1. Увольняешься и ищешь аналогичную г-но-контору

А какой в этом конструктив - найти аналогичную контору?)

 

И, кстати, менеджер у этой разработки есть?

 

конструктивное решение проблемы, почему нет? Если от ТС ничего не зависит и повлиять он на процесс и менеджера не может.

Я так думаю, разработчики скорее начнут увольняться первыми :)

Оффтопик пошел))

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

Насчет разработчиков тоже интересно. Мы не знаем (пока) из-за чего процесс пошел так, а не иначе. Может это заварили разработчики и их все устраивает. Они знают, что они все успеют написать к сроку и все ок.

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

Так что надо смотреть истоки.

Менеджер есть.

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

Регистрацию привел в пример. 

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

То есть пользователь уже есть и регистрация не нужна для тестирования имеющегося функционала?

Да. Вы правы- без регистрации можно приступить к тестированию. Большое "НО" касаемого функционала.(ни один основной функционал не доработан до конца)

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

Оффтопик пошел))

Найти аналогичную контору - это не конструктивно, на мой взгляд.

....

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

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

А менеджер Вам скажет, что сейчас вот вот продукт сдадим и займемся жизненным циклом ПО, ты потерпи брат ещё чутка...

Уходить и мысли не было, спасибо всем за предложенные варианты. О результате отпишу.

1. Для начала можно организовать критерий приёмки проекта в тестирование.

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

3. Гнать впереди паровоза тоже не нужно -  есть менеджер, который отвечает за проект и за программистов. Вы не СПАСИТЕЛЬ ПРОЕКТА и КРИЧАТЬ ЧТО ВСЕ ПЛОХО И МЫ ПРОПАЛИ не ваша обязанность - вы должны обеспечить свою часть работы в виде тестирование.

4. Предполагаю вы знаете, что от вас ожидает руководство. Объясните им, что вы в текущих условиях сможете сделать это и это, а вот это уже не реально сделать за отведенное время. И это нужно сделать сразу, а не если вдруг проект провалиться. 

5. Зарубите идею о KPI до тех пор пока все не станет рельсы. 

6. На эти 3-4 недели до дедлайна ваш процесс должен быть максимально прозрачен, чтобы ваш руководитель был в курсе, что вы делаете и почему ИМЕННО ЭТО вы делаете.

Как и обещал, о результатах:

- В течении получаса объяснил PM-у о том что в такой ситуации в лучшем случае основной функционал пройду.

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

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

- Хорошо что PM с головой на плечах и понимает что тестировщик это не пылесос и не панацея от багов, 

Хорошее начало.

Сам процесс разработки не поменялся?