svetasmirnova
маленький монстрик
_RVK_
А сам-то ты в паре работаешь?
А сам-то ты в паре работаешь?
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
XP - практика применения.
- Автор темы _RVK_
- Дата начала
Sherman
Mephi
В паре работать сложно, даже не технически, а чисто психологически. Чтобы было комфортно работать в паре нужно, чтобы люди были действительно командой, обладали бы психологической совместимостью(аки косманавты
), были примерно на одном техническом уровне, и желательно исповедовали бы общие принципы разработки ПО.
А то ведь знаете как может быть, работаешь с человеком, вроде все ок, а потом начальство говорит:
— А что это у нас Василий за двоих работает, а вы баклуши бьете!
— !!? :E
— Василий, что за куйня!
— ...
Имхо, производительность труда часто снижается...зато споры на тему holy wars в курилках многокртано усиливаются
), были примерно на одном техническом уровне, и желательно исповедовали бы общие принципы разработки ПО.А то ведь знаете как может быть, работаешь с человеком, вроде все ок, а потом начальство говорит:
— А что это у нас Василий за двоих работает, а вы баклуши бьете!
— !!? :E
— Василий, что за куйня!
— ...
Имхо, производительность труда часто снижается...зато споры на тему holy wars в курилках многокртано усиливаются
ZN
Новичок
Нет, я не использую.
Потому, что если Заказчик станет членом команды, и начнёт писать UserStories вместо нормального четкого ТЗ, то это выльется в "вы не так поняли этот пункт, переделайте; а мы хотели ещё вот это, дописывайте" - и всё это за день до сдачи проекта. Мы всегда подробно обсуждаем с заказчиком ТЗ, объясняем ему все мелочи, прописываем в нём весь нужный ему функционал, а после принятия и на протяжении всего проекта ТЗ не меняется ни на один символ и всё делается в строгом соответствии с ним. Я к тому, что имхо это даёт больше четкости и определённости. Мы тратим неделю на подписание ТЗ и потом спокойно работаем, не дёргая заказчика, и он нам не пишет "я придумал: сделайте ещё вот это".
Потому, что мы в команде давно договорились об основных принципах разработки, ввели общие для всех стандарты разработки и придерживаемся их, прекрасно обходясь без юнит-тестов и собраний стоя (имхо вообще идиотизм - если мы хотим поговорить по делу, мы поговорим и лёжа, а если нет - то хоть раком встань, а всё равно будут обсуждаться последние мыши от Logitech). Тут, кстати, знакомый на работу устроился тестером програмного обеспечения авиалайнеров. Так вот там именно тестеры пишут эти юнит-тесты, а не прогеры.
Потому, что если Заказчик станет членом команды, и начнёт писать UserStories вместо нормального четкого ТЗ, то это выльется в "вы не так поняли этот пункт, переделайте; а мы хотели ещё вот это, дописывайте" - и всё это за день до сдачи проекта. Мы всегда подробно обсуждаем с заказчиком ТЗ, объясняем ему все мелочи, прописываем в нём весь нужный ему функционал, а после принятия и на протяжении всего проекта ТЗ не меняется ни на один символ и всё делается в строгом соответствии с ним. Я к тому, что имхо это даёт больше четкости и определённости. Мы тратим неделю на подписание ТЗ и потом спокойно работаем, не дёргая заказчика, и он нам не пишет "я придумал: сделайте ещё вот это".
Потому, что мы в команде давно договорились об основных принципах разработки, ввели общие для всех стандарты разработки и придерживаемся их, прекрасно обходясь без юнит-тестов и собраний стоя (имхо вообще идиотизм - если мы хотим поговорить по делу, мы поговорим и лёжа, а если нет - то хоть раком встань, а всё равно будут обсуждаться последние мыши от Logitech). Тут, кстати, знакомый на работу устроился тестером програмного обеспечения авиалайнеров. Так вот там именно тестеры пишут эти юнит-тесты, а не прогеры.
syfisher
TDD infected!!
Sherman
-- Эй, Василий уже 100 кб кода написал. А вы тут парочку простеньких классов доделать вдвоем не можете??
-- Ага, а потом мы неделю будет переделывать его лапшу и copy+paste, если заказчик изменит требования?
-- Это не мои проблемы! А что б ваша работа была готова через час!!
-- ??!!
Пара программистов всегда производит лучший код, чем два программиста по отдельности. Гораздо выше шансы на выделение абстракций, повторного использования, меньше ошибок, выше интенсивность труда. Мы пишем до 60% всего кода в паре. Однообразные работы стараемся загонять под автогенераторы, опять же таки в паре и т.д.
Парное программирование очень помогает, когда нужно сделать важные архитектурные решения. Недавно я занимался довольно серьезной переделкой классов команд, ломал очень древнюю и явно негибкую иерархию. У меня были тесты и все такое. Но процесс шел очень медленно. Но только до тех пор, пока я не позвал снача одного напарника, а затем через некоторое время - уже другого - помочь. 15 минут, которые я тратил на объяснение ситуации хватало, чтобы им понять, в чем мои проблемы, да и мне понять, где нужно делать самые большие изменения. Затем в течение часа - двух мы вырабатывали решение, которые я, правда, в основном реализовывал самостоятельно. Когда я застревал в следующие раз - звал следующего. Даже такие короткие сесии парного программирования - очень полезны. Я просто уверен, что будь у меня постоянный партнер по время этого рефакторинга - я бы закончил в два раза быстрее, совершив намного меньше ошибок.
ZN
Изменения от Заказчика всегда приветствуются, так как они позволяют делать проект, который приносит больше пользы Заказчику. Но все это только в ситуации коротких итераций и отсутствия фиксированной стоимости работ, на что наши заказчики идут пока очень неохотно. Поэтому разработчики себя страхуют очень подробными ТЗ - и мы тоже так делаем.
В последнее время я заметил еще одну особенность. Если клиенту действительно нужен проект, тогда он скорее всего согласится работать по XP. Особенно, если у него уже был опыт работы с командой разработчиков. У нас уже такие прецеденты есть, и я надеюсь, что их будет все больше. Когда клиент заинтересован не в поделке, не в гипертекстовой картинке, а в реальном проекте, который будет ему приносить деньги, когда он заинтересован в качестве, в быстром выводе проекта на рабочие рельсы, в гибкости проекта - вот тогда есть очень большие шансы на согласие с XP.
-- Эй, Василий уже 100 кб кода написал. А вы тут парочку простеньких классов доделать вдвоем не можете??
-- Ага, а потом мы неделю будет переделывать его лапшу и copy+paste, если заказчик изменит требования?
-- Это не мои проблемы! А что б ваша работа была готова через час!!
-- ??!!
Пара программистов всегда производит лучший код, чем два программиста по отдельности. Гораздо выше шансы на выделение абстракций, повторного использования, меньше ошибок, выше интенсивность труда. Мы пишем до 60% всего кода в паре. Однообразные работы стараемся загонять под автогенераторы, опять же таки в паре и т.д.
Парное программирование очень помогает, когда нужно сделать важные архитектурные решения. Недавно я занимался довольно серьезной переделкой классов команд, ломал очень древнюю и явно негибкую иерархию. У меня были тесты и все такое. Но процесс шел очень медленно. Но только до тех пор, пока я не позвал снача одного напарника, а затем через некоторое время - уже другого - помочь. 15 минут, которые я тратил на объяснение ситуации хватало, чтобы им понять, в чем мои проблемы, да и мне понять, где нужно делать самые большие изменения. Затем в течение часа - двух мы вырабатывали решение, которые я, правда, в основном реализовывал самостоятельно. Когда я застревал в следующие раз - звал следующего. Даже такие короткие сесии парного программирования - очень полезны. Я просто уверен, что будь у меня постоянный партнер по время этого рефакторинга - я бы закончил в два раза быстрее, совершив намного меньше ошибок.
ZN
В XP нет такого понятия, как deadline, проект функционально готов, пусть и очень ограниченно, на каждой итерации.
Изменения от Заказчика всегда приветствуются, так как они позволяют делать проект, который приносит больше пользы Заказчику. Но все это только в ситуации коротких итераций и отсутствия фиксированной стоимости работ, на что наши заказчики идут пока очень неохотно. Поэтому разработчики себя страхуют очень подробными ТЗ - и мы тоже так делаем.
В последнее время я заметил еще одну особенность. Если клиенту действительно нужен проект, тогда он скорее всего согласится работать по XP. Особенно, если у него уже был опыт работы с командой разработчиков. У нас уже такие прецеденты есть, и я надеюсь, что их будет все больше. Когда клиент заинтересован не в поделке, не в гипертекстовой картинке, а в реальном проекте, который будет ему приносить деньги, когда он заинтересован в качестве, в быстром выводе проекта на рабочие рельсы, в гибкости проекта - вот тогда есть очень большие шансы на согласие с XP.
Ты ничего не перепутал?? Может это просто автоматизированные приемочные тесты? Модульные тесты пишутся на отдельные классы. Не понимаю, как тестер может писать white-box тесты, если он не участвовал в реализации.
_RVK_
Новичок
ZN
"Заказчик" это не обязательно тот кто платит деньги. Конечно это идеальный вариант но заказчики обычно толстые и очень занятые дядьки. Роль заказчика, как я уже упоминал, может играть Progect Manager. У нас роль заказчика играет продюссер проекта. Очень удобно когда заказчик находится на растоянии 4 м.
Пользовательские исмтории это тоже удобно. Перед началом проекта мы устроили совещание, в конце которого у нас уже были общие тезисы. Я за пару часов расписал их на подзадачи. На втором совещании задачи были уточнены и распределены по программистам. Сейчас на стене висит четкий план на первые 2 этапа, и каждый четко знает чем ему нужно заниматься. Если что-то непонятно, он может всегда спросить непосредственно заказчика.
Я даже пытался написать ТЗ, но быстро понял что ТЗ здесь не нужно. Все и так понятно. Из всей документации пара UML диаграмм.
"Заказчик" это не обязательно тот кто платит деньги. Конечно это идеальный вариант но заказчики обычно толстые и очень занятые дядьки. Роль заказчика, как я уже упоминал, может играть Progect Manager. У нас роль заказчика играет продюссер проекта. Очень удобно когда заказчик находится на растоянии 4 м.
Пользовательские исмтории это тоже удобно. Перед началом проекта мы устроили совещание, в конце которого у нас уже были общие тезисы. Я за пару часов расписал их на подзадачи. На втором совещании задачи были уточнены и распределены по программистам. Сейчас на стене висит четкий план на первые 2 этапа, и каждый четко знает чем ему нужно заниматься. Если что-то непонятно, он может всегда спросить непосредственно заказчика.
Я даже пытался написать ТЗ, но быстро понял что ТЗ здесь не нужно. Все и так понятно. Из всей документации пара UML диаграмм.
Фантазер
Новичок
Из всех XP практик у меня имеется только одна -- работа с заказчиком итерациями. Хочется сказать очень хорошо работает. Никаких "мы просили одно, а вы сделали другое" -- все видно в процессе работы. Более того -- почти не бывало срывов графика -- "если что-то добавляется все видно -- все фиксируется в мантисе -- выбирается приоритет -- т.е. тема текущей итерации".
А вот тяжелая артилерия -- писание тестов до писания кода -- мы только-только пробуем. И надо сказать -- дело это не легкое и на первых порах имеются тормоза. Однако что-то в этом есть, поскольку хоть и тяжело идет (потому, что старый код не удобно тестировать) а писать код без тестов больше не хочется
Поскольку мы работаем удаленно с программированием парами -- беда. очень хочется попробовать, но не понятно как это можно сделать при удаленной работе.
А вот тяжелая артилерия -- писание тестов до писания кода -- мы только-только пробуем. И надо сказать -- дело это не легкое и на первых порах имеются тормоза. Однако что-то в этом есть, поскольку хоть и тяжело идет (потому, что старый код не удобно тестировать) а писать код без тестов больше не хочется
Поскольку мы работаем удаленно с программированием парами -- беда. очень хочется попробовать, но не понятно как это можно сделать при удаленной работе.
robocomp
Новичок
2whirlwind
XP -- это Extreme Programming -- методология разработки ПО (Software engineering process). Насколько я понимаю, у неё есть авторы. У этой методологии.
И вот они считают, что для того, чтобы их методология работала, необходимо следовать всем практикам.
Т.е., да, если ты не разрабатываешь в парах -- у тебя не ХР (полагаю, исключением будет случай, когда разарботчик один -)))
Твоё личное понимаение ХР -- это прекрасно. Но это не то, что под этим понимают остальные разработчики всего мира, а то, как ты понимаешь ХР в силу того, что недоконца проникся.
Не хотел задеть или обидеть нисколько, просто выражаю свою точку зрения.
-~{}~ 15.02.06 15:17:
2ZN
Здорово вам удаётся договорится с заказчиком ) Расскажите о ваших проектах, пож-та.
Действительно у вас получается за неделю увтердить ТЗ, а потом разрабатывать и сдавать? И всё? Ничего не править больше?
КРУТО!
Пожалуйста, покажитье проекты, а? Дико интересно.
Просто я еще ни разу не слашыл о таком.
Кстати, о небольших минусах.
А что если ТЗ, которое вы утвердили и по котором сделали продукт (допусти, за три месяца) -- больше не надо заказчику. Он посмотрел на него (первый раз за три месяца) и сказал: "А мне не надо этого вовсе" -- что тогда? Он вам отдает деньги за то, что ему не надо и еще раз потоврояет трёхмесячную итерацию? Или наступает на горло своей песне и пользуется тем, что вы написали по своему тз?
В общем -- очень было бы интересно узнать, как у вас всё устроено.
-~{}~ 15.02.06 15:25:
2 RVK -- ответ на самый главный вопрос темы.
Мы в нашей компании (наверное, не будет плохо, если я скажу, что это ehouseholding.ru)
в новом филиале в г. Таганроге решили внедрить "гибкие методы разработк" ТМ -)
Так вот. Получилось пока что только внедрить постоянную интеграцию и модульное тестирование. Разарботка через тестирование -- не пошла.
Автоматические приёмочные тесты -- пошли. Но пока не так живо, как модульные.
С парной разработкой -- большая проблема. Насчет совпадения уровня разработчиков -- это не так. Самое главное, чтобы в коллективе был кто-то, кто следит за тем, что разработка ведётся парная.
И чтобы в каждой паре присутсвовал человек, который понимает, в чём прикол этой техники.
Т.е. для начала надо только одного человека, который понимает. Он работает в паре с наиболее адекватным. Затем эта пара делится. И так до того момента, пока все не начнут кодить в парах..
О времени от начала внедрения до плодов. Могу сказать о вариантах использования и модульных тестах.
Лично в нашем случае понадобилось 6 месяцев, чтобы модульные тесты и варианты использования (use cases, в принципе, чуть более сложный формат user story) стали органично вливаться в процесс разработки
XP -- это Extreme Programming -- методология разработки ПО (Software engineering process). Насколько я понимаю, у неё есть авторы. У этой методологии.
И вот они считают, что для того, чтобы их методология работала, необходимо следовать всем практикам.
Т.е., да, если ты не разрабатываешь в парах -- у тебя не ХР (полагаю, исключением будет случай, когда разарботчик один -)))
Твоё личное понимаение ХР -- это прекрасно. Но это не то, что под этим понимают остальные разработчики всего мира, а то, как ты понимаешь ХР в силу того, что недоконца проникся.
Не хотел задеть или обидеть нисколько, просто выражаю свою точку зрения.
-~{}~ 15.02.06 15:17:
2ZN
Здорово вам удаётся договорится с заказчиком ) Расскажите о ваших проектах, пож-та.
Действительно у вас получается за неделю увтердить ТЗ, а потом разрабатывать и сдавать? И всё? Ничего не править больше?
КРУТО!
Пожалуйста, покажитье проекты, а? Дико интересно.
Просто я еще ни разу не слашыл о таком.
Кстати, о небольших минусах.
А что если ТЗ, которое вы утвердили и по котором сделали продукт (допусти, за три месяца) -- больше не надо заказчику. Он посмотрел на него (первый раз за три месяца) и сказал: "А мне не надо этого вовсе" -- что тогда? Он вам отдает деньги за то, что ему не надо и еще раз потоврояет трёхмесячную итерацию? Или наступает на горло своей песне и пользуется тем, что вы написали по своему тз?
В общем -- очень было бы интересно узнать, как у вас всё устроено.
-~{}~ 15.02.06 15:25:
2 RVK -- ответ на самый главный вопрос темы.
Мы в нашей компании (наверное, не будет плохо, если я скажу, что это ehouseholding.ru)
в новом филиале в г. Таганроге решили внедрить "гибкие методы разработк" ТМ -)
Так вот. Получилось пока что только внедрить постоянную интеграцию и модульное тестирование. Разарботка через тестирование -- не пошла.
Автоматические приёмочные тесты -- пошли. Но пока не так живо, как модульные.
С парной разработкой -- большая проблема. Насчет совпадения уровня разработчиков -- это не так. Самое главное, чтобы в коллективе был кто-то, кто следит за тем, что разработка ведётся парная.
И чтобы в каждой паре присутсвовал человек, который понимает, в чём прикол этой техники.
Т.е. для начала надо только одного человека, который понимает. Он работает в паре с наиболее адекватным. Затем эта пара делится. И так до того момента, пока все не начнут кодить в парах..
О времени от начала внедрения до плодов. Могу сказать о вариантах использования и модульных тестах.
Лично в нашем случае понадобилось 6 месяцев, чтобы модульные тесты и варианты использования (use cases, в принципе, чуть более сложный формат user story) стали органично вливаться в процесс разработки
ZN
Новичок
robocomp
Да, действительно так. Сначала утверждаем ТЗ. Время утверждения разное: иногда клиент смотрит наше портфолио и говорит - хочу точно такой же сайт, как www.site.ru - тогда два-три дня достаточно для подписания. Бывает клиенту нужно что-то нестандартное, какие-то тонкости много значат - тогда можно и в течении месяца обсуждать (но это редкость). В среднем на достаточно стандартный интренет-магазин уходит неделя (я имею в виду подписание ТЗ).
Я не говорил, что мы ничего не правим после сдачи. Конечно бывает возникают баги. Но все правки - только в рамках ТЗ. То есть правится то, чего не хватает для удовлетворения ТЗ.
Что если после сдачи заказчик понял, что это не то, что ему надо было? Это его проблемы. он поставил подпись под договорм и ТЗ. Вообще в ТЗ присутствует следующее:
1.Заказчику объяснены все положения Технического задания.
2.Заказчик не вправе требовать от исполнителя выполнения любых работ, не описанных в данном документе.
3.Заказчик не вправе требовать от исполнителя соблюдения норм и стандартов не описанных в данном документе.
4.Заказчик не вправе требовать от исполнителя дополнительных работ, ссылаясь на неоднозначное понимание технического задания.
"Он посмотрел на него (первый раз за три месяца)" - я же объясняю, что перед тем, как подписать ТЗ заказчику всё подробно объясняют, всё с ним обсуждается.
Тут вот писали "Изменения от Заказчика всегда приветствуются, так как они позволяют делать проект, который приносит больше пользы Заказчику." Да, мы стараемся сделать то, что будет полезно заказчику. Для этого мы с большим старанием подходим к разработке ТЗ и объяснения всего заказчику. Но в конечном итоге мы делаем деньги. Наша цель - заработать, а не осчастливить всех заказчиков.
Ещё писали про "отсутствие фиксированной стоимости работ". Пойдите найдите такого заказчика, которому вы скажете, что назовёте цену после сдачи. Как вы вообще собрались договор подписывать? "Стоимость работ по данному договору будет изобретена исполнителем позднее" ?
Что значит покажите прожекты? Честно, не хочется выкладывать на этом форуме всоё портфолио из-за присутствия на нём людей(?) вроде Фаната. Если вам интересно - пишите в приват. Хотя я не очень понимаю, как вы, глянув на готовый сайт, поймёте, как проходила его разработка.
Да, действительно так. Сначала утверждаем ТЗ. Время утверждения разное: иногда клиент смотрит наше портфолио и говорит - хочу точно такой же сайт, как www.site.ru - тогда два-три дня достаточно для подписания. Бывает клиенту нужно что-то нестандартное, какие-то тонкости много значат - тогда можно и в течении месяца обсуждать (но это редкость). В среднем на достаточно стандартный интренет-магазин уходит неделя (я имею в виду подписание ТЗ).
Я не говорил, что мы ничего не правим после сдачи. Конечно бывает возникают баги. Но все правки - только в рамках ТЗ. То есть правится то, чего не хватает для удовлетворения ТЗ.
Что если после сдачи заказчик понял, что это не то, что ему надо было? Это его проблемы. он поставил подпись под договорм и ТЗ. Вообще в ТЗ присутствует следующее:
1.Заказчику объяснены все положения Технического задания.
2.Заказчик не вправе требовать от исполнителя выполнения любых работ, не описанных в данном документе.
3.Заказчик не вправе требовать от исполнителя соблюдения норм и стандартов не описанных в данном документе.
4.Заказчик не вправе требовать от исполнителя дополнительных работ, ссылаясь на неоднозначное понимание технического задания.
"Он посмотрел на него (первый раз за три месяца)" - я же объясняю, что перед тем, как подписать ТЗ заказчику всё подробно объясняют, всё с ним обсуждается.
Тут вот писали "Изменения от Заказчика всегда приветствуются, так как они позволяют делать проект, который приносит больше пользы Заказчику." Да, мы стараемся сделать то, что будет полезно заказчику. Для этого мы с большим старанием подходим к разработке ТЗ и объяснения всего заказчику. Но в конечном итоге мы делаем деньги. Наша цель - заработать, а не осчастливить всех заказчиков.
Ещё писали про "отсутствие фиксированной стоимости работ". Пойдите найдите такого заказчика, которому вы скажете, что назовёте цену после сдачи. Как вы вообще собрались договор подписывать? "Стоимость работ по данному договору будет изобретена исполнителем позднее" ?
Что значит покажите прожекты? Честно, не хочется выкладывать на этом форуме всоё портфолио из-за присутствия на нём людей(?) вроде Фаната. Если вам интересно - пишите в приват. Хотя я не очень понимаю, как вы, глянув на готовый сайт, поймёте, как проходила его разработка.
_RVK_
Новичок
ZN
Ты рассказал практику, принятую в большенстве студий где я работал. И по моему опыту такая схема очень неэфективна. Почему? Потому что программист, чаще всего не принимает участия в согласовании ТЗ, и то, что менджеру(часто просто директору, потому что даже на менеджера раскашелится ума не хватает), кажется ясным как день, программисту не так понятно. А детали, действительно необходимые программисту, в ТЗ упущены, а возможности уточнить нет.
Во вторых за месяц проработки ТЗ, можно написать кучу полезного кода. Ты сам говоришь что средний магазин делается 2 недели. Если бы заказчимк был бы рядом, то времени на ТЗ просто не потребовалось бы.
Но видимо ты просто не знаешь что такое ХР. Советую почитать те ссылки что были приведены в самом начале.
Ты рассказал практику, принятую в большенстве студий где я работал. И по моему опыту такая схема очень неэфективна. Почему? Потому что программист, чаще всего не принимает участия в согласовании ТЗ, и то, что менджеру(часто просто директору, потому что даже на менеджера раскашелится ума не хватает), кажется ясным как день, программисту не так понятно. А детали, действительно необходимые программисту, в ТЗ упущены, а возможности уточнить нет.
Во вторых за месяц проработки ТЗ, можно написать кучу полезного кода. Ты сам говоришь что средний магазин делается 2 недели. Если бы заказчимк был бы рядом, то времени на ТЗ просто не потребовалось бы.
Но видимо ты просто не знаешь что такое ХР. Советую почитать те ссылки что были приведены в самом начале.
ZN
Новичок
_RVK_
> Потому что программист, чаще всего не принимает участия в согласовании ТЗ
У нас принимает самое непосредственное.
>А детали, действительно необходимые программисту, в ТЗ упущены
Учитесь составлять ТЗ. Я же говорил, что у нас в ТЗ всё подробно прописано. И прогаммисту из ТЗ всё ясно.
>Во вторых за месяц проработки ТЗ, можно написать кучу полезного кода. Ты сам говоришь что средний магазин делается 2 недели.
Не надо путать. Я же сказал, что месяц может уйти на сложный нестандартный проект, а не на средний магазин.
>Но видимо ты просто не знаешь что такое ХР
Вы ошиблись, я знаю.
Видимо вы просто никогда не видели хороших ТЗ.
> Потому что программист, чаще всего не принимает участия в согласовании ТЗ
У нас принимает самое непосредственное.
>А детали, действительно необходимые программисту, в ТЗ упущены
Учитесь составлять ТЗ. Я же говорил, что у нас в ТЗ всё подробно прописано. И прогаммисту из ТЗ всё ясно.
>Во вторых за месяц проработки ТЗ, можно написать кучу полезного кода. Ты сам говоришь что средний магазин делается 2 недели.
Не надо путать. Я же сказал, что месяц может уйти на сложный нестандартный проект, а не на средний магазин.
>Но видимо ты просто не знаешь что такое ХР
Вы ошиблись, я знаю.
Видимо вы просто никогда не видели хороших ТЗ.
robocomp
Новичок
Уважаемый ZN! Пожалуйста, поделитесь примером правильного тз, если можно. Мне действительно (да я думаю и всем остальным) было бы очень интересно, как писать правильное тз.
Кроме того, если не сложно, дайте ссылку на самый ваш сложны й и интересный проект.
Понимаете, ваша точка зрения сильно отличается от моей и от большинства моих коллег. Было бы интересно, к чему это приводит на практике. Моя почта вроде как есть в контактах.
Заранее спасибо.
pachanga
Новичок
Очень интересно звучит. Так вы что же пишете модульные тесты уже после имплементации?
И насчет CI(постоянной интеграции) - нельзя ли поподробнее? Что используете: самописные утилиты или что-то известное, как CruiseControl, DamageControl, Rephlux? Насколько всеобъемлющим является процесс CI, т.е. что в него входит в вашем случае? Насколько процесс CI автоматизирован? Мы очень активно занимаемся этой темой, поэтому интересно услышать чужой опыт.