Что читать по процессу разработке ПО

[tasol]

Нужно руководство по разработке ПО начиная от этапа описания проекта до релиза.

 

[Фанат]

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

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

 

[fixxxer]

полное руководство

 

[tasol]

полное руководство

к сожалению все так и происходит, поэтому совершил корпоративное самоубийство

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

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

есть идея своего проекта, есть потенциальный инвестор, нужно грамотно описать весь жизненный цикл продукта

для меня это как написать школьное сочинение на тему "Почему я не хожу в церковь?". Нельзя же просто написать: "Я атеист, хожу в лес". Также нельзя написать: 'Хуяк хуяк и в продакшн"... Нужно раскрыть тему.

надеюсь так заинтересовал, а то пиво не пью, сиськи не растут

 

[fixxxer]

ну если серьезно, то все зависит от религиозных взгядов =)

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

 

[Ragazzo]

На самом деле все методики agile лишь нужны для "верхушки", скрам-мастеры и т п.
Ну а так то наверное:
3 DDD :
хорошая подборка http://habrahabr.ru/post/61524/
2 BDD
specBDD и storyBDD (стоит лишь загуглить)
1 TDD(unit)
тут К. Бек с XP, и прочие книжки по рефакторингу. (куча книг)

 

[WMix]

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

 

[Redjik]

ой - а мне еще вот этот цикл статей нравится - http://habrahabr.ru/post/138749/

 

[Ragazzo]

WMix
<sarcasm>Ты вторгся в область DDD и общения с domain-experts</sarcasm>

 

[AmdY]

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

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

 

[WMix]

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

 

[Ragazzo]

WMix
я никуда не посылал) я просто "выпендрился" DDD
Кстати кратко и по делу (есть немного водички, но очень информативно все показывается):
http://www.infoq.com/minibooks/domain-driven-design-quickly
да, все верно ты говоришь