Процесс разработки по

1) здравый смысл

больше пунктов нет, самое гиблое что можно придумать это юзать методологию ради метологии или «умл потому что так делают»

используют ли сейчас UML диаграммы.

Практически нет. Сам удивляюсь (С)

1) Как наладить процесс разработки по с нуля.

Смотря что за разработка. Продукт который будет продаваться или разовый проект? B2B || B2C? Срок жизни? Очередное мегаприложение под андроид или какой нибудь софт для управления ядерным реактором?

2) Как создавать требования, техзадание, используют ли сейчас UML диаграммы.

Головой и руками в любом текстовом редакторе, желательно сразу онлайновом типа вики или confluence. Но можно хоть в ворде, храня документы в VCS.

C юэмэлем послдние лет 5 точно не сталкивался, хоть и далеко не один проект видел.

3) Как спроектировать красивый API.

Красота - понятие субъективное, так что в общем случае никак. Все равно найдутся люди, для которых он будет какашкой.

4) Что можно использовать для организации разработки опенсорс-продукта.

Ыыы, гитхаба вполне достаточно.

По лучше всего разрабатывать лёгкой гимнастикой в спортивном зале. ПО же — см. фиг. 1.

Процесс разработки по

Херак-херак и в продакшин.

1) здравый смысл

больше пунктов нет, самое гиблое что можно придумать это юзать методологию ради метологии или «умл потому что так делают»

Кроме здравого смысла еще используют юзерстори, техзадания, пм-ов и тимлидов, бизнес-аналитиков. Мне надо разобраться что к чему и зачем.

это буллшит, не запутайся в нем 8)

тебе надо знать «что нужно» - это ты можешь называть ТЗ, юзер стори, статуя из говна, но сут ьв том что это все вместе даже не ответит на вопрос, а значит нужно сразу учитывать что «интимная хотелка заказчика» отличается от того что он изложил на бумаге или словами, с этого все траблы и куча всяческого булшита который направлен на формализацию общения между исполнителем и заказчиком - ну чтобы потом можно было на что опираться в спорах «а почему это не так», а они полюбому будут если есть хоть какаято обратная связь.

но сут ьв том что это все вместе даже не ответит на вопрос, а значит нужно сразу учитывать что «интимная хотелка заказчика» отличается от того что он изложил на бумаге или словами

+100500 к мнению оратора.

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

1) Как наладить процесс разработки по с нуля

http://motivateclock.org/
http://www.axure.com/
https://www.jetbrains.com/youtrack/
https://bitbucket.org/
https://www.jetbrains.com/idea/ [clion|webstorm|phpstorm|pycharm|rubymine|resharper]
http://www.sublimetext.com/3 или vim/emacs
Куча плагинов под эти IDE в зависимости от требований
Дизассемблеры/анпакеры/декрипторы/декомпилиторы/деобфускаторы и их антонимы
Дебагеры, профайлеры, прочие тулзы
http://snippets.me/ и собственная коллекция
Собственная коллекция библиотек и ресурсы на подобии https://android-arsenal.com/
http://themeforest.net/
http://codecanyon.net/
Всевозможные плагины к хрому/фурифоксу на подобии https://chrome.google.com/webstore/detail/advanced-rest-client/hgmloofddffdnp...
Поиск готовых наработок https://code.openhub.net/
Контакт-лист с различного рода разработчиками, которые способны помочь советом, взять на себя работу за деньги
И я не учитываю коммандную разработку

2) Как создавать требования, техзадание, используют ли сейчас UML диаграммы

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

3) Как спроектировать красивый API

https://www.youtube.com/watch?v=aAb7hSCtvGw
http://lcsd05.cs.tamu.edu/slides/keynote.pdf

4) Что можно использовать для организации разработки опенсорс-продукта

http://i.imgur.com/7IQbWD9.png

http://ic.pics.livejournal.com/droids_life/68035718/427/427_600.jpg

Дедлайн. 7 бед - один ответ.

спасибо за развернутый ответ!

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

А тебе сколько лет и чем ты раньше занимался? Какой опыт работы?

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

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

Просто по всем пунктам твоего поста можно ответить, что нужен личный опыт.

Ну проблема в том, что требования давали БА, архитектуру продумывали архитекторы, мы получаем уже готовые задачи для работы. Мне интересно понять, как все это организовывать.

Вряд ли по книжкам олучится сделать сразу все правильно. Нужен или личный опыт, или хорошее образование тима «менеджмент в IT». Ну или на ходу набивать шишки.

Просто нет однозначного ответа, как все организовывать. Зависит от обстоятельств - сколько есть денег, кто заказчики, для чего пишется проект, какие программисты, кто менеджеры и т.д. В каких-то случаях можно вообще ничего не организовывать, а послать программиста поговорить с заказчиком. Чтобы он на месте посмотрел что ему надо сделать, и надеяться что он все сделает правильно. Например потому что денег нет на что-то большее, или программист всего один.
А если есть стартап с финансированием в несколько десятков миллионов $, там можно нанять архитектора, лид девелопера, рассказать им суть проекта и по полной программе полгода поднимать инфраструктуру тестов с моками, с ежедневными билдами, рисовать диаграммы, писать ТЗ ка каждый экран приложения и делать прочие полезные вещи.

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

если учебный тогда:

1) открываешь текстовый редактор и хреначишь туда неформализованные хотелки и варианты использования (юзкейсы, причем не обязательно в умл)

2) из 1 формируешь: четкое ТЗ (можно даже по ГОСТУ, благо такой есть), высокоуровневую архитектуру (модулей, подсистем смотря какя толщина проекта)

3) из 2 создаешь задачи верхнего уровня, типа «создать модуль конфигурации», затем берешь одну задачу и детализируешь: «создать парсер и writer конфигов», «создать модифицируемое хранилище конфигурации с конкуррентным доступом и поддержкой событий» - при этом описывая там требования из тз и требования вытекающие из взаимодествия с другими модулями (последнии и есть «контакты», оне частично представлены API)

4) из 3 пишешь код, затем тест или наоборот, смотря какую методологию предпочитаешь, в любом случае требования API и поведения у тебя должны быть в 3

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

У меня вот проблема по детализации. Хочется разбить проект на спринты, типа аджайл, все дела. На работе водопад, как разбивают функциональность при итеративном подходе - хз вообще. Может есть примеры какие? Гугл мне выдает кучу всякой фигни и ничего полезного.

ТППО в универе не изучали? Самое время.

2 пункт для колхозников

Изучали, читали Соммервиля Инженерию ПО, делади УМЛ-диаграммы, но вот сложить все в кучу пока не выходит. Может что-то годное почитать посоветуешь?

а как солнцеликие пишут код?

примеры детализации идут из недр понимания приципов проектирования и прочих эпических вещей

напиши сюда простенькое задание на кусок ПО я тебе его детализирую

и не важно какой подход - это влияет не на детализацию а на порядок детализации и выдачи заданий

Тут много полезной информации http://brightoutsource.com/

У меня тут была попытка разделить задачи по спринтам с последующим добавлением функционала. https://github.com/movax10/sublator/wiki/Brief-sprint-plan Нверное требования нужно описывать в каком-то другом виде?

У меня вот проблема по детализации. Хочется разбить проект на спринты, типа аджайл, все дела. На работе водопад, как разбивают функциональность при итеративном подходе - хз вообще. Может есть примеры какие? Гугл мне выдает кучу всякой фигни и ничего полезного.

А что не ясно? Сначала определяешься с длинной спринта (от 2 недель до 2 месяцев). Потом определяешься с единицами оценки - story points. Например, 1sp - 1 рабочий день. Дальше разбиваешь всё на задачи размером не больше спринта (лучше - сильно меньше) и сваливаешь это все в трекер. Каждая задача должна иметь четко заданный результат - артефакт (код, дизайн, и т.п.). Дальше задачи приоретизируются в трекере, чтобы было видно с чего начинать. Не Major/Minor/т.п., а относительно друг друга. Дальше на каждый спринт выбираются наиболее приоритетные задачи, согласно кол-ву sp в спринте. В идеале в конце каждого спринта должен выходить releasable продукт (при желании можно взять и зарелизить).

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

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

Не говоря о том, что с ТЗ не было ни одного удачного проекта. Они пишутся, по ним делается, потом ТЗ, пишется новое и так по кругу.

Про требования. Некорые компании, которые можно найти на ХХ.ру. Пишут такую фразу «Анализ, выявление требований к ПО»... Вот хоть десять раз повтори медлено «требования к ПО».. фраза бессмысленная. Требовать - значит предъявлять. Что можно предъявить ПО? Оно не только неодушевленное, оно просто информация, которая ничего не делает без процессора. Предъявить может клиент исполнителю, только зачем заказчику связываться с таким исполнителем, от которого приходится что-то требовать. Требовать, например, может руководитель проекта от разработчиков, тестировщиков. Только опять не понятно, почему от них что-то требовать.

У меня однажды был разговор с одим новоиспеченным рукводителем, который хотел всем показать «кто тут царь природы». Я ему сказал, что я пришел работать не потому что должен или обязан, а потому что сам так захотел. Он замолчал.

Без относительно к написанию кода или созданию проекта, решению задачи даже не связанной к ИТ. Схема вобщем-то простая и универсальная.

Первое, нет никакого «Как?». ТЗ пытается на него ответить, но безуспешно. Поиск ответа на вопрос «Как?» - это самый трудоемкий и самый затратный способ найти ответ, решение и добараться до финиша.

Второе, часто в начале возникает сметение, вопрос «С чего начать, за что хвататься?». Ответ - собирать информацию, это очень просто. Голова вообще не требуется. Собирается вся возможная информация, обязательно, без разбора.

Третье, сбор информации постепенно переходит к анализу. Отделить главное и второстепенное, разложить на аспекты. Анализом, уточнением вопросов, которые возникаю по ходу, занимается аналитик. Он же взаимодействует с заказчиком и исполнителями, а так же сопровождением. В результате появляется «постановка». Этот документ отвечает на вопрос целей и возможностей.

На этом этапе возникает, то что люди называют «видение». Это сродни тому как самолет поднимается высоко в небо, и оттуда видно все вокруг. Плюс, как для самолета, так и для проекта - это высшая точка потенциала. Кто смог «раскуритить» потенциал, тому легко. Кто не смог, у того самолет быстро «плюхается на брюхо» и дальше его все тащут за собой. Мало того, на земле не видно куда идти и тащить этот самолет.

Поднявшись в небо, опять нет никакого вопроса «Как?», все и так видно. Хочешь дом у моря, рулишь к морю. Постепенно спускаясь подруливаешь к идеальному результату. В 10-ку.

В самом начале, никто не знал где координаты того самого результата. Это нельзя увидеть сразу.

разработка сервиса трансляции (сервис это термин в разработке а не интернет-сервис): постановка требований к АПИ транслятора (в общем случае метод translate(config, srcText), где config - объект включающий с какого языка, на какой язык и опционально подсказки для переводчика типа «компьютеры, учеба», НО если транслятор выдает несколько вариантов то надо вернуть список вариантов), имплементация транслятора на базе онлайн или локального переводчика (в зависимости от выбора тут будут разные нюансы)

разработка парсера\генератора субтитров: требования к апи (поточный метод парсера принимающий на вход поток, структуру с mime, имя файла и т.п. и коллбек в который будут сыпаться структурки с кусками субтитров), реализация реестра парсеров (мы ведь будем поддерживаь несколько форматов?), реализация поддержки выбранных форматов на базе имеющихся готовых библиотек

разработка менеджера переводов: проектирование апи (менеджер предоставляет коллбэк в парсер, в коллбек сыпятся субтитры которые отправляются в транслятор, если вариантов несколько то надо спросить юзера, затем их надо отфроматировать)

это причем самый самый базовый вариант детализации, без UI, и вопросов как «спросить юзера» при нескольких вариантах перевода

Выходит, что мне нужно делить на модули и задачи финальную версию продукта, или для каждого спринта?

если методология мешает то проще ее выкинуть, это раз

ты за неделю что-то напишешь? нет? или это будет «готовый к релизу» кусок статичного html?

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

Хотя да, через неделю ты можешь релизнуть какойнить сервис который проходит тесты.

Все постоянно требуют техзадание, описание продукта, что за черт?

Тут конечно требуется определенное искусство. Но как правило проще всего это решить административным ресурсом. Приходит к тебе исполнитель и начинает ныть про ТЗ, постановку задачи, тесты и т.д. Идешь к директору и говоришь что эти мудаки хотят нам сорвать сроки! Он их натягивает на кукан. После чего приходит от исполнителя самый толковый прогер которому ты на пальцах объясняешь что от них нужно. Давая возможность неописанные места додумать самому. Профит!

PS забыл запятые расставить: ,,,,,,,

Изучали, читали Соммервиля Инженерию ПО, делади УМЛ-диаграммы, но вот сложить все в кучу пока не выходит. Может что-то годное почитать посоветуешь?

А что тут еще можно посоветовать? Как проектировать ПО — представляешь, как работать в команде — тоже, как писать код — знаешь. Дальше только практика. Берешь да делаешь потихоньку.

Тот, кто лучше шарит в БД, пусть проектирует БД (или какие у вас там будут структуры данных) и вообще отвечает за «бекенд». Тот, кто знает, как делать интерфейс, пусть его и делает. Техзадание пусть вычитывают все поочереди. Джуниоры пусть занимаются «грязной» работой и одновременно подтягивают недостающие в команде знания. Требования должен писать человек с ясной головой (== хорошим фразопостроением).

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

UML ради UML'а использовать не надо. Чаще всего обходятся упрощенными блок-схемами, если это не АЭС.

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

Со временем оно само придет куда надо. Главное, не бояться, а постоянно пробовать и в случае необходимости переделывать (без фанатизма, конечно). Невозможно научиться ездить на велосипеде, ни разу не упав.