Недавно я с удивлением узнал, что не смотря на накопленный за последние десятилетия опыт в разработки программного обеспечения и большое количество написанной литературы, водопад (Waterfall) по-прежнему применяется, и причем даже в интернет-проектах.
Причем водопад именно в своем классическом понимании – с длинным циклом разработки, последовательными переходами между фазами, фиксацией требований, кода и пр.
Не особо понимаю, как водопад может сознательно применяться. Я всегда думал, что это описание некоторых проблем.
ОтветитьУдалить@Pavel Hritonenko, а как же госсектор или военка?
ОтветитьУдалитьНу там не водопад, там принудительный тупак. Водопад - это болезнь, а не подход, по-моему.
ОтветитьУдалитьСамое смешное, я где-то читал, что создатель водопадной модели в своё время (и достаточно очень давно, когда эта модель ещё только становилась популярной) недоумённо сказал: "ребята, да я не то имел в виду..." :)
ОтветитьУдалитьВ частности там говорилось, что он не подразумевал таких несуразностей, как кларификация и заморозка требований на момент начала проекта и т.д.
Так и вспоминается тот же Несчастный Случай:
- Да ну, да я не то имел в виду!
- Что ты имел в своём виду расскажешь маме с папой!
- Что вы, ребята?!
- Какие мы те нафик ребята?! Ребята все покакали и спять, а тут паши, как на субботнике!
И индустрия пошла "пахать" :)
Миш, это где, у индусов чтоли? :)))
ОтветитьУдалитьДык да...
ОтветитьУдалитьMichael Smirnov ну тут низя сравнивать что мол waterfall фигня, все делаем тока agile без понятия что за проект. Agile применяется где у нас есть большие риски, где мы не знаем как делать чтото, и ценность в agile что мы можем динамически меняться и реагировать под изменяюшиеся требоваия и условия. Но это только часть проектов.
ОтветитьУдалитьЕсть проекты где все известно как и что и почему делать и нет никаких изменичивых факторов. В таких проектах waterfall отлично работает. Для примера авиация, постройка атомных станций, военные системы в основном создаются используя waterfall т.е. все ясно на перед что будем делать. Тут не бывает случаев что к конце постройки самолета выяснили что крылья не в ту сторону сделали, и нужно поменять быстро. Или же в процессе постройки 20 этажа здания вспомнили что нам нужно было сделать на 5ть эжажей парковку подземную :)
Michael Nemtsev Миша про Software Development говорит.
ОтветитьУдалитьAlexey Raga а какая разница? SD это частный случай всего лишь, где работают определенные методики. не более того
ОтветитьУдалитьAlexey Raga допустим возьми инфраструктуру телекомуникаций в здании. вот тебе IT. на первых этажах уже все поштукатурили, и забетонировали, а тут ты вспомнил что мол мало кабелей проложили
ОтветитьУдалитьMichael Nemtsev Частный случай, для которых "классический" waterfall неприменим в реальной жизни.
ОтветитьУдалитьДа и в construction ты бы удивился как бывает что всё меняется сильно уже в процессе. Более того, сам процесс там немерено сложен, чтобы его взять вот так, сначала распланировать полностью, а потом тока делать, делать, делать.
Michael Nemtsev Никто, кстати, не переводил разговор в чёрно-белую плоскость типа "если не waterfall - то agile".
ОтветитьУдалитьAlexey Raga я тоже :) просто написал почему я думаю waterfall жив :)
ОтветитьУдалитьMichael Nemtsev А расскажи про это поподробнее? Почему ты думаешь, что там именно waterfall, а не спонтанная разработка и отсутствие какой-либо методологии в принципе? На изменения требований не реагируют? Так может им просто это делать напряжно (в связи с качеством кода, например) и оттого они посылают?
ОтветитьУдалитьИли это действительно у них такой процесс? Как он выглядит тогда? Интересно!
Я не против waterfall, как такового - в принципе, я думаю, что в некоторых областях он действительно может применяться. И наверное даже должен.
ОтветитьУдалитьНо если речь идет о коммерческих интернет-проектах - мне кажется, что waterfall - не самый удачный выбор.
Я, кстати, тоже не считаю, что если не waterfall, то обязательно Agile.
еще есть FDD и FDD (это на самом деле две разных аббревиатуры)! :)
ОтветитьУдалитьТочно :)
ОтветитьУдалитьЕсть ещё BDD и BDD и ещё даже BDD - и это тоже разные аббревиатуры :)
ОтветитьУдалитьМде :)
ОтветитьУдалить@Alexey Raga хмм!! Behaviour-Driven Development, а еще? (я надеюсь остальные BDD это тоже методологии, а не какая нибудь бяка-кака?)
ОтветитьУдалить@Andrey Markeev Ещё Business Driven Development и "бяка-кака" в виде Bug Driven Development, но тоже встречается :)
ОтветитьУдалитього! круто, не знал)) а у меня имелось в виду Feature Driven Development - ну это наверное известная вещь, а также Fear Driven Development, это с хабра, из жаргона программистов, запомнилось :) Типа, работай, иначе уволят...
ОтветитьУдалить@Andrey Markeev Bug Driven Development примерно из той же оперы: тебе лепят баг типа "а вот не работает то-то", а то, что этой фичи никогда и в планах-то не было, не то, чтобы её делать, что под неё надо достаточно много подготовить и это займёт много времени - всем начхать. Типа Важный Кастомер пожаловался, с точки зрения его бизнес процесса отсутствие такой возможности - это баг, поэтому кастомер фигачит его в саппорт, саппорт заводит багу, программисты эту "багу" типа "фиксят" :)
ОтветитьУдалитьХа-ха... Ну да, знакомо, печально, но знакомо! :(
ОтветитьУдалитьПо поводу того, что такс пишется в баг - я в прошлом году проводил опрос среди знакомых контор - большинство не парятся по этому поводу - пишут все в один элемент.
ОтветитьУдалитьИ на самом деле, разницы в workflow таска и бага не много.
Все, конечно, зависит от конкретной конторы, но все же...
В шаблоне ScrumForTS в этом плане - всё хорошо. Багом считается продукт тестирования, оценивается только его критичность. Для его исправления заводится обычная задача.
ОтветитьУдалитьMichael Smirnov Разница есть в процессе работы с оным всё же есть. Можно, как Паша говорит, для каждого бага заводить таску (SBI) и процессить как таску (либо стори (PBI). В ScrumForTS, насколько я помню, бага находится на том же уровне, что и PBI. Но это большой оверхэд, связанный с workflow этой штуки: её надо разбить на таски, проэстимировать, включить в итерацию и т.д.
ОтветитьУдалитьПодавляющее большинство багов всё же относится к категории "если понял что это - считай пофиксил", тут уже никакая эстимация не нужна, тем более включение в следующие итерации. Допускаю, что есть и "сложные" баги, требующие подобного подхода, но, как правило, их не много и в этом случае уже можно рассматривать не как баг, а как недоработанную либо неработающую фичу.
Кроме того, баги - это такие штуки, без которых продукт данный продукт правильно работать не может. То есть, он работает неправильно - и это плохо, и это может быть источником проблем и т.д.
Фича - это то, без чего продукт прекрасно живёт. Новая фича просто добавляет новый функционал.
Отсюда и логическая разница между багом и новой фичей.
Ошибки надо править, делать так, чтобы те фичи, которые есть в продукте, работали правильно и кастомер не огребал с ними. Иногда править надо немедленно, сразу. Прямо сейчас пофиксить и задеплоить через полчаса.
Баги сами диктуют как порядок их фикса, так и тайминги.
Я бы даже больше сказал, баги в чём-то - это не проектная работа (project), а операционная (operational, routine).
Новые фичи - это проектная работа. Мы полностью управляем расписанием их появления в продукте, планировать ресурсы и всё, что мы делаем, планируя итерацию.
Workflow совершенно другой. Если он не другой и люди не видят разницы между багом и таском - тут уж извините, я только хмыкну. Это один из тех бредов, с которым я постоянно борюсь в нашей компании с переменным успехом :) Это очень сильно импактит производительность, ясность процесса, чёткость его управления.
Багами у нас, например, занимается постоянно часть народу вне всяких спринтов, на "операционной" основе (а как иначе?). Этим людям нельзя давать делать таски!!! Не потому, что люди плохие (люди всё время разные) а потому, что начинается жуткая смесь проектных и операционных задач.
Очень важно, чтобы каждый "баг" оценивался, таки является он багом или нет. Это сразу отвечает на вопрос, кто будет делать задачу, как она будет процесситься. И сразу резко снижает количество неуправляемого месса.
Я согласен что баги и таски в большинстве своем вещи разные.
ОтветитьУдалитьНо, как сказал Паша, таск может состоять в том, чтобы исправить баг :)
Alexey Raga а вы баги линкуете к SBI/PBI?
ОтветитьУдалитьMichael Smirnov И я объяснил, почему это является неверным.
ОтветитьУдалитьMichael Nemtsev Нет. У нас был зоопарк и мы использовали для трекинга багов вообще другую софтину, тогда как артефакты скрама были в TFS.
ОтветитьУдалитьСейчас мы переходим на JIRA, но, насколько я понимаю, подобное не планируется.
Хотя давай разберёмся о каких багах мы говорим.
Если мы говорим о багах, которые тестеры (или сама команда) находит в функциональности, которая находится в процессе разработки, либо сдаётся в релиз (то есть в той, которая ещё не принята и не релизнута) - то тут да, эти баги могут и вероятно должны быть привязаны к соответствующему PBI (_не_ SBI, конечно).
Я бы тут, между нами, назвал это Internal Bugs :)
А те баги, которые найдены в релизнутом софте... Те - нет. Там есть категория, area какая-нибудь, как эти баги классифицируются. Это отдельные "операционные" задачи до тех пор, пока мы не захотим на основе них создать PBI с соответствующим жизненным циклом (и тогда он уже переходит из разряда багов в разряд нормальных проектных задач).
Меня Jira что-то пока не впечатляет....
ОтветитьУдалитьMichael Smirnov Я имел в виду JIRA + Greenhoper. Пока ничего более гибкого и удобного просто не встречалось... Может не там смотрели :)
ОтветитьУдалитьСейчас посмотрим что за Greenhopper....
ОтветитьУдалитьЭх..... оказывается его так просто не поставишь - нужен админ JIRA.
ОтветитьУдалитьMichael Smirnov На локальный комп поставь и то и другое - и смотри :)
ОтветитьУдалить> а вы баги линкуете к SBI/PBI?
ОтветитьУдалитьЯ линкую (related). Ну и чаще всего для исправлени создается SBT в том же PBI.
Да что толку-то - на рабочую JIRA поставить его все равно будет нереально.
ОтветитьУдалитьMichael Smirnov Почему? Админ злой?
ОтветитьУдалитьAlexey Raga: Бюрократия...
ОтветитьУдалитьAlexey Raga а вы jira тока для багов используете?
ОтветитьУдалитьMichael Nemtsev Нет, на Jira перешли, чтобы использовать его для всего :)
ОтветитьУдалитьА что ж вы так?
ОтветитьУдалитьВроде TFS-то поудобнее....
Michael Smirnov экономят :)
ОтветитьУдалить@Michael Nemtsev, я недавно офигел с ряда партнерок и статусов - тот же ISV дает 10-ток студий и немного лицензий. А еще говорят - с MS жить невозможно, все дорого бла-бла-бла.
ОтветитьУдалитьMichael Smirnov Далеко нет. В TFS, я тебе уже говорил, более чем посредственное всё: и билд сервер, и тем более посредственный соурс контрол, и ещё более воркайтемы и процессы всякие.
ОтветитьУдалитьНо в TFS есть одна очень сильная сторона: интеграция этого всего дела между собой. Но она всего одна. Нам просто оказалось более выгодно пользоваться более удобными и современными инструментами. Поэтому сейчас перешли на Jira, в неясном пока будущем есть планы перейти на что-нибудь вроде TeamCity в качестве билд-сервера и есть смутные намётки слинять на Mercurial какой-нибудь, но это пока серьёзно не обсуждается.
Anton Vishnyakov Да это линуксоиды говорят, которые на эклипсе работают, так они сразу к аду готовятся, чтобы там шоком не оказалось :)
ОтветитьУдалитьНа деле всё с MS гораздо веселее :)
Michael Nemtsev Чё экономят-то? Я не уверен, что Jira + GH дешевле (хотя и не знаю цен). В любом случае, у нас, насколько мне память не изменяет, лицензии на TFS в любом случае по статусу есть. Дело не в деньгах было.
ОтветитьУдалитьAlexey Raga а Project Management вы не использовали в связке с ProjecServer->TFS?
ОтветитьУдалитьХм, Леша, я помню ты говорил, что TFS - самый удобный инструмент, который ты встречал.
ОтветитьУдалитьНу видимо тогда еще Jira не встречал...:)
Michael Smirnov Да, не встречал, но дело-то не в этом :)
ОтветитьУдалитьПросто у нас стали появляться требования, при которых мы упираемся в ограничения TFS.
Например, нам нужно, чтобы к воркайтемам, репортам и прочей обвязке имели доступы (причём разные) разные люди из разных доменов. И даже просто левые люди. Поэтому нам приходилось держать зоопарк в виде отдельной тулзы, о которой я писал раньше - TFS этого не позволяет.
Например, нам теперь нужно, чтобы при создании бранча у этого бранча сразу был билд на билдовой машине, такой же, как у родительского бранча. Ну, чтобы там сразу был CI, чтобы можно было точно так же в один клик сделать деплоймент на UAT или Test, например. TFS этого не умеет.
У нас есть необходимость работы с удалённым соурс контролом, который вообще не наш. При этом мы хотим иметь у себя свою версию кода (а не работать всем с тамошним соурс контролом), от которой уже наши разработчики будут делать свои ветки (с билдами, да), сливать с нашей основной веткой, чтобы мы могли из удалённой основной ветки брать изменения, когда нам надо и чтобы мы могли сливать туда наши изменения, те, что мы хотим. Это крайне геморно делается с TFS, практически никак и вручную.
Я не говорю, что TFS плох, нет. Но просто требования такие.
Если подобных требований нет или пока нет - то отличный инструмент, кто же спорит. У нас вот появились. Мы пытались бороться всякими воркэраундами и как-то игнорировать требования, но достало это. Не попрёшь против требований-то.
> в неясном пока будущем есть планы перейти на что-нибудь вроде TeamCity в качестве билд-сервера
ОтветитьУдалитьЯ не понимаю, чем он лучше встроенного. Я с ним работал, ТФСный - сильно удобней, хотя TeamCity интегрируется с джирой.