Долгая счастливая жизнь

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

=== Почему:

1 . Проект разрабатывается уже 2 года, но пока еще релиза не было => это значит, что что-то идет не так.

2 . Очень жирный список фич для первого релиза.

Записал только фичи из первого майлстоуна в трелло https://trello.com/b/bfFBZmfz/cev-eris

Инвайт в трелло: https://trello.com/invite/b/bfFBZmfz/4af2e33b214f13d8865680aa5fc53c55/cev-eris

Поправьте меня, если я не прав. Но мне кажется, что это очень очень очень много работы.

Я уже видел это.

У нас (10 разработчиков и 4 тестировщика) был огроменный релиз, в котором переписывалась большая часть нашего продукта. Разработка писала код в течение двух с половиной месяцев. И столько же мы потом тестировали и правили баги.

К чему это привело:

-один разработчик не выдержал и ушел в яндекс

-после первого месяца у всей команды была очень низкая мораль. Из-за этого хорошие люди много ругались и работали плохо.

-миллиону багов, в том числе перекрестных (чинили одно, поломали другое)

-в итоге оказалось, что это не совсем то, чего хотели пользователи

Первые три пункта должны еще сильнее бить по опенсорс-командам, где никто никаких денег не получает и все завязано на личной мотивации.

3 . Тестирование ведется, как придется. Разработчики сами тестируют свои фичи, проверки не документируют.

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

=== Что я предлагаю:

1 . Распилить майлстоун на много маленьких. Идеально, если в каждом будет по одной фиче из вышеперечисленных.

Чем это может помочь:

• Выпуск каждого майлстоуна - это буст морали команды. Мораль = люди не уходят.
• Чем меньше релиз, чем меньше в нем багов (убывают в геометрической прогрессии)
• После каждого законченного этапа можно бахать анонсы и заниматься прочей PR мишурой. В том числе это может способствовать притоку людей в команду разработки.

2 . Тестировать каждый майлстоун и записывать, что протестировано.

Обязательно в каждом майлстоуне прогонять регрессионные тесты (хотя бы проверять, что те же наноуи не отвалились)

• Игроки не увидят большинства багов, найденных при ручных тестах. Этим билд будет отличаться от прочих тг и бэев.

Прикинул процесс, по котором можно делать фичи и достигать майлстоунов. Что думаете?

https://github.com/Algol12/CEV-Eris/wiki

Тестовый майлстоун - https://github.com/Algol12/CEV-Eris/milestone/4?closed=1

=== Что я могу сделать сам

• ковырятся в коде и делать простые задачи - в бьонде я не силен, так что это будет долго

• тестировать релизы (а именно, регрессионное тестирование и перепроверка того, что протестировали разработчики в своих фичах)

• вести бюрократию с релизами, майлстоунами и таким вот

• помочь попилить все на майлстоуны и спланировать