понедельник, 18 апреля 2011 г. - www.msmirnov.ru

Водопад жив…

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

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

Мой сайт - www.msmirnov.ru

52 комментария:

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

    ОтветитьУдалить
  2. @Pavel Hritonenko, а как же госсектор или военка?

    ОтветитьУдалить
  3. Ну там не водопад, там принудительный тупак. Водопад - это болезнь, а не подход, по-моему.

    ОтветитьУдалить
  4. Самое смешное, я где-то читал, что создатель водопадной модели в своё время (и достаточно очень давно, когда эта модель ещё только становилась популярной) недоумённо сказал: "ребята, да я не то имел в виду..." :)
    В частности там говорилось, что он не подразумевал таких несуразностей, как кларификация и заморозка требований на момент начала проекта и т.д.

    Так и вспоминается тот же Несчастный Случай:
    - Да ну, да я не то имел в виду!
    - Что ты имел в своём виду расскажешь маме с папой!
    - Что вы, ребята?!
    - Какие мы те нафик ребята?! Ребята все покакали и спять, а тут паши, как на субботнике!

    И индустрия пошла "пахать" :)

    ОтветитьУдалить
  5. Миш, это где, у индусов чтоли? :)))

    ОтветитьУдалить
  6. Michael Smirnov ну тут низя сравнивать что мол waterfall фигня, все делаем тока agile без понятия что за проект. Agile применяется где у нас есть большие риски, где мы не знаем как делать чтото, и ценность в agile что мы можем динамически меняться и реагировать под изменяюшиеся требоваия и условия. Но это только часть проектов.
    Есть проекты где все известно как и что и почему делать и нет никаких изменичивых факторов. В таких проектах waterfall отлично работает. Для примера авиация, постройка атомных станций, военные системы в основном создаются используя waterfall т.е. все ясно на перед что будем делать. Тут не бывает случаев что к конце постройки самолета выяснили что крылья не в ту сторону сделали, и нужно поменять быстро. Или же в процессе постройки 20 этажа здания вспомнили что нам нужно было сделать на 5ть эжажей парковку подземную :)

    ОтветитьУдалить
  7. Alexey Raga а какая разница? SD это частный случай всего лишь, где работают определенные методики. не более того

    ОтветитьУдалить
  8. Alexey Raga допустим возьми инфраструктуру телекомуникаций в здании. вот тебе IT. на первых этажах уже все поштукатурили, и забетонировали, а тут ты вспомнил что мол мало кабелей проложили

    ОтветитьУдалить
  9. Michael Nemtsev Частный случай, для которых "классический" waterfall неприменим в реальной жизни.
    Да и в construction ты бы удивился как бывает что всё меняется сильно уже в процессе. Более того, сам процесс там немерено сложен, чтобы его взять вот так, сначала распланировать полностью, а потом тока делать, делать, делать.

    ОтветитьУдалить
  10. Michael Nemtsev Никто, кстати, не переводил разговор в чёрно-белую плоскость типа "если не waterfall - то agile".

    ОтветитьУдалить
  11. Alexey Raga я тоже :) просто написал почему я думаю waterfall жив :)

    ОтветитьУдалить
  12. Michael Nemtsev А расскажи про это поподробнее? Почему ты думаешь, что там именно waterfall, а не спонтанная разработка и отсутствие какой-либо методологии в принципе? На изменения требований не реагируют? Так может им просто это делать напряжно (в связи с качеством кода, например) и оттого они посылают?
    Или это действительно у них такой процесс? Как он выглядит тогда? Интересно!

    ОтветитьУдалить
  13. Я не против waterfall, как такового - в принципе, я думаю, что в некоторых областях он действительно может применяться. И наверное даже должен.

    Но если речь идет о коммерческих интернет-проектах - мне кажется, что waterfall - не самый удачный выбор.

    Я, кстати, тоже не считаю, что если не waterfall, то обязательно Agile.

    ОтветитьУдалить
  14. еще есть FDD и FDD (это на самом деле две разных аббревиатуры)! :)

    ОтветитьУдалить
  15. Есть ещё BDD и BDD и ещё даже BDD - и это тоже разные аббревиатуры :)

    ОтветитьУдалить
  16. @Alexey Raga хмм!! Behaviour-Driven Development, а еще? (я надеюсь остальные BDD это тоже методологии, а не какая нибудь бяка-кака?)

    ОтветитьУдалить
  17. @Andrey Markeev Ещё Business Driven Development и "бяка-кака" в виде Bug Driven Development, но тоже встречается :)

    ОтветитьУдалить
  18. ого! круто, не знал)) а у меня имелось в виду Feature Driven Development - ну это наверное известная вещь, а также Fear Driven Development, это с хабра, из жаргона программистов, запомнилось :) Типа, работай, иначе уволят...

    ОтветитьУдалить
  19. @Andrey Markeev Bug Driven Development примерно из той же оперы: тебе лепят баг типа "а вот не работает то-то", а то, что этой фичи никогда и в планах-то не было, не то, чтобы её делать, что под неё надо достаточно много подготовить и это займёт много времени - всем начхать. Типа Важный Кастомер пожаловался, с точки зрения его бизнес процесса отсутствие такой возможности - это баг, поэтому кастомер фигачит его в саппорт, саппорт заводит багу, программисты эту "багу" типа "фиксят" :)

    ОтветитьУдалить
  20. Ха-ха... Ну да, знакомо, печально, но знакомо! :(

    ОтветитьУдалить
  21. По поводу того, что такс пишется в баг - я в прошлом году проводил опрос среди знакомых контор - большинство не парятся по этому поводу - пишут все в один элемент.
    И на самом деле, разницы в workflow таска и бага не много.

    Все, конечно, зависит от конкретной конторы, но все же...

    ОтветитьУдалить
  22. В шаблоне ScrumForTS в этом плане - всё хорошо. Багом считается продукт тестирования, оценивается только его критичность. Для его исправления заводится обычная задача.

    ОтветитьУдалить
  23. Michael Smirnov Разница есть в процессе работы с оным всё же есть. Можно, как Паша говорит, для каждого бага заводить таску (SBI) и процессить как таску (либо стори (PBI). В ScrumForTS, насколько я помню, бага находится на том же уровне, что и PBI. Но это большой оверхэд, связанный с workflow этой штуки: её надо разбить на таски, проэстимировать, включить в итерацию и т.д.

    Подавляющее большинство багов всё же относится к категории "если понял что это - считай пофиксил", тут уже никакая эстимация не нужна, тем более включение в следующие итерации. Допускаю, что есть и "сложные" баги, требующие подобного подхода, но, как правило, их не много и в этом случае уже можно рассматривать не как баг, а как недоработанную либо неработающую фичу.

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

    Фича - это то, без чего продукт прекрасно живёт. Новая фича просто добавляет новый функционал.

    Отсюда и логическая разница между багом и новой фичей.
    Ошибки надо править, делать так, чтобы те фичи, которые есть в продукте, работали правильно и кастомер не огребал с ними. Иногда править надо немедленно, сразу. Прямо сейчас пофиксить и задеплоить через полчаса.
    Баги сами диктуют как порядок их фикса, так и тайминги.
    Я бы даже больше сказал, баги в чём-то - это не проектная работа (project), а операционная (operational, routine).

    Новые фичи - это проектная работа. Мы полностью управляем расписанием их появления в продукте, планировать ресурсы и всё, что мы делаем, планируя итерацию.
    Workflow совершенно другой. Если он не другой и люди не видят разницы между багом и таском - тут уж извините, я только хмыкну. Это один из тех бредов, с которым я постоянно борюсь в нашей компании с переменным успехом :) Это очень сильно импактит производительность, ясность процесса, чёткость его управления.

    Багами у нас, например, занимается постоянно часть народу вне всяких спринтов, на "операционной" основе (а как иначе?). Этим людям нельзя давать делать таски!!! Не потому, что люди плохие (люди всё время разные) а потому, что начинается жуткая смесь проектных и операционных задач.

    Очень важно, чтобы каждый "баг" оценивался, таки является он багом или нет. Это сразу отвечает на вопрос, кто будет делать задачу, как она будет процесситься. И сразу резко снижает количество неуправляемого месса.

    ОтветитьУдалить
  24. Я согласен что баги и таски в большинстве своем вещи разные.
    Но, как сказал Паша, таск может состоять в том, чтобы исправить баг :)

    ОтветитьУдалить
  25. Michael Smirnov И я объяснил, почему это является неверным.

    ОтветитьУдалить
  26. Michael Nemtsev Нет. У нас был зоопарк и мы использовали для трекинга багов вообще другую софтину, тогда как артефакты скрама были в TFS.
    Сейчас мы переходим на JIRA, но, насколько я понимаю, подобное не планируется.

    Хотя давай разберёмся о каких багах мы говорим.
    Если мы говорим о багах, которые тестеры (или сама команда) находит в функциональности, которая находится в процессе разработки, либо сдаётся в релиз (то есть в той, которая ещё не принята и не релизнута) - то тут да, эти баги могут и вероятно должны быть привязаны к соответствующему PBI (_не_ SBI, конечно).
    Я бы тут, между нами, назвал это Internal Bugs :)

    А те баги, которые найдены в релизнутом софте... Те - нет. Там есть категория, area какая-нибудь, как эти баги классифицируются. Это отдельные "операционные" задачи до тех пор, пока мы не захотим на основе них создать PBI с соответствующим жизненным циклом (и тогда он уже переходит из разряда багов в разряд нормальных проектных задач).

    ОтветитьУдалить
  27. Меня Jira что-то пока не впечатляет....

    ОтветитьУдалить
  28. Michael Smirnov Я имел в виду JIRA + Greenhoper. Пока ничего более гибкого и удобного просто не встречалось... Может не там смотрели :)

    ОтветитьУдалить
  29. Сейчас посмотрим что за Greenhopper....

    ОтветитьУдалить
  30. Эх..... оказывается его так просто не поставишь - нужен админ JIRA.

    ОтветитьУдалить
  31. Michael Smirnov На локальный комп поставь и то и другое - и смотри :)

    ОтветитьУдалить
  32. > а вы баги линкуете к SBI/PBI?

    Я линкую (related). Ну и чаще всего для исправлени создается SBT в том же PBI.

    ОтветитьУдалить
  33. Да что толку-то - на рабочую JIRA поставить его все равно будет нереально.

    ОтветитьУдалить
  34. Alexey Raga а вы jira тока для багов используете?

    ОтветитьУдалить
  35. Michael Nemtsev Нет, на Jira перешли, чтобы использовать его для всего :)

    ОтветитьУдалить
  36. А что ж вы так?
    Вроде TFS-то поудобнее....

    ОтветитьУдалить
  37. @Michael Nemtsev, я недавно офигел с ряда партнерок и статусов - тот же ISV дает 10-ток студий и немного лицензий. А еще говорят - с MS жить невозможно, все дорого бла-бла-бла.

    ОтветитьУдалить
  38. Michael Smirnov Далеко нет. В TFS, я тебе уже говорил, более чем посредственное всё: и билд сервер, и тем более посредственный соурс контрол, и ещё более воркайтемы и процессы всякие.
    Но в TFS есть одна очень сильная сторона: интеграция этого всего дела между собой. Но она всего одна. Нам просто оказалось более выгодно пользоваться более удобными и современными инструментами. Поэтому сейчас перешли на Jira, в неясном пока будущем есть планы перейти на что-нибудь вроде TeamCity в качестве билд-сервера и есть смутные намётки слинять на Mercurial какой-нибудь, но это пока серьёзно не обсуждается.

    ОтветитьУдалить
  39. Anton Vishnyakov Да это линуксоиды говорят, которые на эклипсе работают, так они сразу к аду готовятся, чтобы там шоком не оказалось :)
    На деле всё с MS гораздо веселее :)

    ОтветитьУдалить
  40. Michael Nemtsev Чё экономят-то? Я не уверен, что Jira + GH дешевле (хотя и не знаю цен). В любом случае, у нас, насколько мне память не изменяет, лицензии на TFS в любом случае по статусу есть. Дело не в деньгах было.

    ОтветитьУдалить
  41. Alexey Raga а Project Management вы не использовали в связке с ProjecServer->TFS?

    ОтветитьУдалить
  42. Хм, Леша, я помню ты говорил, что TFS - самый удобный инструмент, который ты встречал.

    Ну видимо тогда еще Jira не встречал...:)

    ОтветитьУдалить
  43. Michael Smirnov Да, не встречал, но дело-то не в этом :)
    Просто у нас стали появляться требования, при которых мы упираемся в ограничения TFS.

    Например, нам нужно, чтобы к воркайтемам, репортам и прочей обвязке имели доступы (причём разные) разные люди из разных доменов. И даже просто левые люди. Поэтому нам приходилось держать зоопарк в виде отдельной тулзы, о которой я писал раньше - TFS этого не позволяет.

    Например, нам теперь нужно, чтобы при создании бранча у этого бранча сразу был билд на билдовой машине, такой же, как у родительского бранча. Ну, чтобы там сразу был CI, чтобы можно было точно так же в один клик сделать деплоймент на UAT или Test, например. TFS этого не умеет.

    У нас есть необходимость работы с удалённым соурс контролом, который вообще не наш. При этом мы хотим иметь у себя свою версию кода (а не работать всем с тамошним соурс контролом), от которой уже наши разработчики будут делать свои ветки (с билдами, да), сливать с нашей основной веткой, чтобы мы могли из удалённой основной ветки брать изменения, когда нам надо и чтобы мы могли сливать туда наши изменения, те, что мы хотим. Это крайне геморно делается с TFS, практически никак и вручную.

    Я не говорю, что TFS плох, нет. Но просто требования такие.
    Если подобных требований нет или пока нет - то отличный инструмент, кто же спорит. У нас вот появились. Мы пытались бороться всякими воркэраундами и как-то игнорировать требования, но достало это. Не попрёшь против требований-то.

    ОтветитьУдалить
  44. > в неясном пока будущем есть планы перейти на что-нибудь вроде TeamCity в качестве билд-сервера

    Я не понимаю, чем он лучше встроенного. Я с ним работал, ТФСный - сильно удобней, хотя TeamCity интегрируется с джирой.

    ОтветитьУдалить