Комментарии 64
Для крупных проектов стараемся следовать RUP, для мелких водопад
Я думаю, что вот так под одну гребенку не очень корректно всех загонять.
Есть ведь клиентская разработка. Есть внутренние проекты. Подходы во многом разные.
И если ко внутренним проектам можно хорошо прикрутить scrum/kanban, то в клиентской разработке это сильно, имхо, расшатывает проект и повышает риски. Потому как зачастую бюджеты не резиновые, сроки тоже; клиенту нужен план и понимание когда будет финальный релиз. И ему до одного места, каким образом это будет достигаться. Главное, чтобы была прозрачность и соответствие бюджетам/срокам.
Есть ведь клиентская разработка. Есть внутренние проекты. Подходы во многом разные.
И если ко внутренним проектам можно хорошо прикрутить scrum/kanban, то в клиентской разработке это сильно, имхо, расшатывает проект и повышает риски. Потому как зачастую бюджеты не резиновые, сроки тоже; клиенту нужен план и понимание когда будет финальный релиз. И ему до одного места, каким образом это будет достигаться. Главное, чтобы была прозрачность и соответствие бюджетам/срокам.
Главное, чтобы была прозрачность и соответствие бюджетам/срокам.
Знакомо, при этом собственно проект всем до ж*пы. Давайте разделять разработку и занятие х**ней (это когда код пишут, диаграммы всякие рисуют, а результат по факту нахрен никому не нужен — обычно для больших корпораций и госструктур).
В основном мой опыт — аутсорсинг: гибкие подходы порой внедряются самим заказчиком, не говоря уже о том, что все крупные аутсорсеры имеют внутренние отделы внедряющие agile-практики.
У нас смесь Scrum и Kanban. Команда разработки одна, проектов несколько.
Это, наверное, в «Agile собственного приготовления» укладывается.
Скрумбан можно смело добавлять имхо. Я его три конторы подряд пользую.
Просто оставлю это здесь… (18+)
В последних небольших проектах используем канбан (Trello), с навесками для Scrum плагинами.
самодельный Scrumban, стремимся прийти к описанному в playbook.thoughtbot.com/
А я вот часто вижу декларируемый agile / scrum / kanban который на самом деле либо уже через ж@пу либо скоро таковым будет. Это я к тому что между что отвечают в опросе и что происходит на деле есть некоторая разница.
У нас: на словах — Scrum, Kanban; на деле — через %опу.
В конце проектов месяца за 2:
Промежуточные результаты (для тех, кто не зарегистрирован на Хабре, и их не видит):
По моему опыту, «Agile собственного приготовления» это «Как получится» в гриме.
Так что лидер — он по-прежнему лидер.
Так что лидер — он по-прежнему лидер.
Где «литературное программирование»?
Госструктура.
Команда по-максимуму пытается использовать Scrum (и довольно неплохо получается), но т.к. руководству (высшему, не прямому) такие слова неизвестны, получается все равно через жопу. Все эти планирования, спринты и прочее летят в трубу, когда руководство внезапно решило подкинуть еще один проект, иногда вообще никак не связанный с разработкой. Увы и ах, чо.
Команда по-максимуму пытается использовать Scrum (и довольно неплохо получается), но т.к. руководству (высшему, не прямому) такие слова неизвестны, получается все равно через жопу. Все эти планирования, спринты и прочее летят в трубу, когда руководство внезапно решило подкинуть еще один проект, иногда вообще никак не связанный с разработкой. Увы и ах, чо.
Как по мне — правильнее было бы делать радиобаттон с выбором подхода, типа скрам, вотерфолл, канбан и так далее и отдельным пунком галочку «через жопу». Потому что абсолютно любую идею можно применять именно этим способом, что зачастую и делается. И результаты опросов по годам говорят скорее не о том что лидер в организации работы сменился, а о том что люди лучше овладели терминологией и теперь точно знают что именно у них на проектах применяется через неё, родимую.
Это, конечно, моё личное мнение. Основанное на том что менеджмент у нас уверен что мы работаем на скраме, а факты говорят иное.
Это, конечно, моё личное мнение. Основанное на том что менеджмент у нас уверен что мы работаем на скраме, а факты говорят иное.
Это, конечно, моё личное мнение. Основанное на том что менеджмент у нас уверен что мы работаем на скраме, а факты говорят иное.
Такое бывает сплошь и рядом, по-моему. :)
Строго говоря, «через %опу» — это даже не методология, а отношение к происходящему. :) Но по историческим причинам оставлено как отдельный вариант. :)
А была ещё какая-то картинка с бизнесом в Китае. Там не то что АААА, там — лапша!
для «Agile собственного приготовления» — есть отличный термин ScrumBut
У меня сложилось впечатление, что даже те, кто вроде как используют Scrum, на самом деле используют ScrumBut ))
Мы используем Youtrack для организации рабочего процесса, не смотря на конские цены и проблемы с переездом на него, он реально очень удобный.
У меня сложилось впечатление, что даже те, кто вроде как используют Scrum, на самом деле используют ScrumBut ))
Мы используем Youtrack для организации рабочего процесса, не смотря на конские цены и проблемы с переездом на него, он реально очень удобный.
У нас все, от кого зависит методология, проектирование и принятие решений, из всех слов, перечисленных в опросе, слышали только эти, с символом процента. Так что, здравствуй, %, новый год…
Я подозреваю, что на опрос может оказывать влияние некоторый максимализм присущий разработчикам. Для многих слегка измененный относительно святого писания agile это уже «через жпу».
Вы бы еще объяснили, что значат все эти умные слова…
Тут, надо бы отдельную статью писать, а то и не одну… Но в рамках опроса — если вы этих слов не слышали, скорее всего, этого у вас нет. :)
Ну почему же? Не все же так глубоко в термины лезут.
Полез в Вики. Допустим вторая методология, которая нашей почте и не снилась или являлась только в мечтах (чаще в мечтах клиентов)
Не все же создают опросы, некоторым работать приходится :D
И во время работы невольно приходят к одной из методологий, о которой ни разу не слышали.
С такими вариантами надо проводить опрос среди соответствующих специалистов. Среди обычных разработчиков и студий тут победитель ясен без голосования.
Это примерно как, предложить в обществе интеллигентных и не очень* людей травку Канабис, в то время как 99% (субъективно) присутствующих не знаю что это за трава. А предложи им общеизвестное название — поймут** 99%.
* то есть. не увлекающихся этим делом
** я не говорю о согласие
Полез в Вики. Допустим вторая методология, которая нашей почте и не снилась или являлась только в мечтах (чаще в мечтах клиентов)
Канбан — система организации производства и снабжения, позволяющая реализовать принцип «точно в срок».
Не все же создают опросы, некоторым работать приходится :D
И во время работы невольно приходят к одной из методологий, о которой ни разу не слышали.
С такими вариантами надо проводить опрос среди соответствующих специалистов. Среди обычных разработчиков и студий тут победитель ясен без голосования.
Это примерно как, предложить в обществе интеллигентных и не очень* людей травку Канабис, в то время как 99% (субъективно) присутствующих не знаю что это за трава. А предложи им общеизвестное название — поймут** 99%.
* то есть. не увлекающихся этим делом
** я не говорю о согласие
В прошлой команде у нас была методология «как получится» и мы умудрялись писать и ядро без, которое использовалось в пяти независимых друг от друга приложениях без особых проблем, хотя заказчик был тот еще. Да у нас даже тестировщиков не было. В текущей команде у нас скрам практически по всем правилам, с досками, спринтами и тестированием и мы срываем сроки из-за того что не понимаем как сделать правильно — как всегда архитектура не учитывала неожиданных поворотов событий )
Мое личное мнение такое, что на самом деле не так важна методология как слаженная команда, хорошая архитектура и понятный код
Мое личное мнение такое, что на самом деле не так важна методология как слаженная команда, хорошая архитектура и понятный код
+1
Есть отличная статья Алистера Коберна «Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения».
Оттуда:
1. Практически любую методологию можно с успехом применять в каком-нибудь проекте.
2. Любая методология может привести к провалу проекта.
3. Тяжеловесные методологии тоже могут успешно применяться в работе.
4. Облегченные методологии чаще приводят к успеху, и, что более важно, разработчики сами говорят, что успех проекта был обеспечен именно методологией.
Есть отличная статья Алистера Коберна «Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения».
Оттуда:
1. Практически любую методологию можно с успехом применять в каком-нибудь проекте.
2. Любая методология может привести к провалу проекта.
3. Тяжеловесные методологии тоже могут успешно применяться в работе.
4. Облегченные методологии чаще приводят к успеху, и, что более важно, разработчики сами говорят, что успех проекта был обеспечен именно методологией.
НЛО прилетело и опубликовало эту надпись здесь
А за какой вариант нужно голосовать, если рабочее время тратится непосредственно на работу, а не соответствие методологиям?
Не могу определится, а Через %опу + итерации, это можно назвать «Agile собственного приготовления»?
FDD + пиши код, блеать + херак в продакшн. Очень эффективно в сферах, где ошибки не критичны и есть возможность их исправить.
А Срам — это методика очковтирательства для манагеров, где можно годами рубить бабло закрывая незначительные фичи и баги, отодвигая или размазывая критичные проблемы.
А Срам — это методика очковтирательства для манагеров, где можно годами рубить бабло закрывая незначительные фичи и баги, отодвигая или размазывая критичные проблемы.
Web-разработка крупных проектов в непосредственном контакте с заказчиком. Kanban + оценка по времени тасков + периодические митинги. Scrum так ни разу не удалось применить из-за его ограничений: фиксированный спринт и полная взаимозамеяемость членов команды друг другом. На практике второе условие не соблюдается почти никогда, да и с первым тоже сложно.
а PMBOK вы не относите к методологии? Мы например у себя используем ее, и у нас все получается.
Пришлось поставить другое.
Пришлось поставить другое.
Спасибо за комментарий — в следующий раз сделаем, да. А то меня вот и Иван Селиховкин (наш эксперт по управлению проектами) всячески застыдил. :)
PMBoK не методология, это «свод знаний».
Нельзя просто так взять, и применить PMBoK. :) (разве что под монитор подложить)
А вот строить управление своими проектами, применяя знания и рекомендации, вырванные из контекста PMBoK, неправильно интерпретированные и не туда приспособленные, можно запросто. Получится «что-то собственного приготовления».
Нельзя просто так взять, и применить PMBoK. :) (разве что под монитор подложить)
А вот строить управление своими проектами, применяя знания и рекомендации, вырванные из контекста PMBoK, неправильно интерпретированные и не туда приспособленные, можно запросто. Получится «что-то собственного приготовления».
del
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опрос: какая методология используется в вашем проекте или насколько все у нас через это?