How to become an author
Search
Write a publication
Pull to refresh

Comments 64

Для крупных проектов стараемся следовать RUP, для мелких водопад
Total votes 4: ↑4 and ↓0+4
А какую именно модель из RUP используете?
Total votes 1: ↑1 and ↓0+1
Я думаю, что вот так под одну гребенку не очень корректно всех загонять.

Есть ведь клиентская разработка. Есть внутренние проекты. Подходы во многом разные.

И если ко внутренним проектам можно хорошо прикрутить scrum/kanban, то в клиентской разработке это сильно, имхо, расшатывает проект и повышает риски. Потому как зачастую бюджеты не резиновые, сроки тоже; клиенту нужен план и понимание когда будет финальный релиз. И ему до одного места, каким образом это будет достигаться. Главное, чтобы была прозрачность и соответствие бюджетам/срокам.
Total votes 4: ↑2 and ↓20
Главное, чтобы была прозрачность и соответствие бюджетам/срокам.


Знакомо, при этом собственно проект всем до ж*пы. Давайте разделять разработку и занятие х**ней (это когда код пишут, диаграммы всякие рисуют, а результат по факту нахрен никому не нужен — обычно для больших корпораций и госструктур).
Total votes 4: ↑3 and ↓1+2
В основном мой опыт — аутсорсинг: гибкие подходы порой внедряются самим заказчиком, не говоря уже о том, что все крупные аутсорсеры имеют внутренние отделы внедряющие agile-практики.
This comment wasn’t rated yet0
Дык аналогично, коллега. Но у нас все индивидуально. Иногда и в вотерфолл скатываемся. Страшного в этом я ничего не вижу.
This comment wasn’t rated yet0
У нас смесь Scrum и Kanban. Команда разработки одна, проектов несколько.
Total votes 3: ↑3 and ↓0+3
Это, наверное, в «Agile собственного приготовления» укладывается.
Total votes 6: ↑6 and ↓0+6
При scrum основная проблема была в шеринге ресурсов между проектами, взяв от Kanban систему контейнеров(процессов в виде дизайн/верстка/программирование итд) проблема ушла сама собой.
This comment wasn’t rated yet0
О, мы тоже пришли к такому же в итоге :)
This comment wasn’t rated yet0
У нас смесь Scrum и через жопу. Интересно, это укладывается в «Agile собственного приготовления»? :)
Total votes 7: ↑7 and ↓0+7
Я думаю, это зависит от того, насколько силен эмоциональный окрас. :)
Total votes 1: ↑1 and ↓0+1
Скрумбан можно смело добавлять имхо. Я его три конторы подряд пользую.
Total votes 1: ↑1 and ↓0+1
Просто оставлю это здесь… (18+)

image
Total votes 81: ↑78 and ↓3+75
Всегда интересно было кто авторы.
Total votes 3: ↑3 and ↓0+3
Первый даже есть на хабре.
Total votes 1: ↑1 and ↓0+1
Это методика концепции «пиши код, блеять!». Странно, что ее нет в голосовалке.
Total votes 1: ↑1 and ↓0+1
Она там есть — это второй по популярности ответ.
This comment wasn’t rated yet0
В последних небольших проектах используем канбан (Trello), с навесками для Scrum плагинами.
Total votes 2: ↑2 and ↓0+2
А я вот часто вижу декларируемый agile / scrum / kanban который на самом деле либо уже через ж@пу либо скоро таковым будет. Это я к тому что между что отвечают в опросе и что происходит на деле есть некоторая разница.
Total votes 8: ↑8 and ↓0+8
+1.

Есть на эту темы определение: скрамбат (scrum but), то есть у нас Скрам, но… :)
Total votes 6: ↑6 and ↓0+6
Agile без вовлеченности обеих сторон (клиент + исполнитель) имхо невозможен в принципе. Как еще agile может быть через ж*пу, я не представляю.
This comment wasn’t rated yet0
У нас: на словах — Scrum, Kanban; на деле — через %опу.
Total votes 7: ↑7 and ↓0+7
В конце проектов месяца за 2:
Total votes 9: ↑9 and ↓0+9
Похоже на схему раздачи «пинков» для ускорения работы сотрудников.
При этом нужно произносить заклинание «А-А-А-А!».
Total votes 2: ↑2 and ↓0+2
Что подразумевается под «концом» проекта?
Просто в скольких проектах ни работал, нигде не было конца.
Total votes 5: ↑5 and ↓0+5
По моему опыту, «Agile собственного приготовления» это «Как получится» в гриме.

Так что лидер — он по-прежнему лидер.
Total votes 12: ↑12 and ↓0+12
Где «литературное программирование»?
Total votes 1: ↑0 and ↓1-1
Я прошу прощения, а что это такое?
This comment wasn’t rated yet0
Это калька с «literate programming».
This comment wasn’t rated yet0
Госструктура.
Команда по-максимуму пытается использовать Scrum (и довольно неплохо получается), но т.к. руководству (высшему, не прямому) такие слова неизвестны, получается все равно через жопу. Все эти планирования, спринты и прочее летят в трубу, когда руководство внезапно решило подкинуть еще один проект, иногда вообще никак не связанный с разработкой. Увы и ах, чо.
Total votes 5: ↑5 and ↓0+5
Как по мне — правильнее было бы делать радиобаттон с выбором подхода, типа скрам, вотерфолл, канбан и так далее и отдельным пунком галочку «через жопу». Потому что абсолютно любую идею можно применять именно этим способом, что зачастую и делается. И результаты опросов по годам говорят скорее не о том что лидер в организации работы сменился, а о том что люди лучше овладели терминологией и теперь точно знают что именно у них на проектах применяется через неё, родимую.

Это, конечно, моё личное мнение. Основанное на том что менеджмент у нас уверен что мы работаем на скраме, а факты говорят иное.
Total votes 4: ↑4 and ↓0+4
Это, конечно, моё личное мнение. Основанное на том что менеджмент у нас уверен что мы работаем на скраме, а факты говорят иное.


Такое бывает сплошь и рядом, по-моему. :)

Строго говоря, «через %опу» — это даже не методология, а отношение к происходящему. :) Но по историческим причинам оставлено как отдельный вариант. :)
This comment wasn’t rated yet0
А была ещё какая-то картинка с бизнесом в Китае. Там не то что АААА, там — лапша!
Total votes 1: ↑1 and ↓0+1
для «Agile собственного приготовления» — есть отличный термин ScrumBut

У меня сложилось впечатление, что даже те, кто вроде как используют Scrum, на самом деле используют ScrumBut ))

Мы используем Youtrack для организации рабочего процесса, не смотря на конские цены и проблемы с переездом на него, он реально очень удобный.
Total votes 1: ↑1 and ↓0+1
У нас все, от кого зависит методология, проектирование и принятие решений, из всех слов, перечисленных в опросе, слышали только эти, с символом процента. Так что, здравствуй, %, новый год…
This comment wasn’t rated yet0
Я подозреваю, что на опрос может оказывать влияние некоторый максимализм присущий разработчикам. Для многих слегка измененный относительно святого писания agile это уже «через жпу».
Total votes 2: ↑2 and ↓0+2
Вы бы еще объяснили, что значат все эти умные слова…
Total votes 4: ↑4 and ↓0+4
Тут, надо бы отдельную статью писать, а то и не одну… Но в рамках опроса — если вы этих слов не слышали, скорее всего, этого у вас нет. :)
Total votes 1: ↑1 and ↓0+1
Ну почему же? Не все же так глубоко в термины лезут.
Полез в Вики. Допустим вторая методология, которая нашей почте и не снилась или являлась только в мечтах (чаще в мечтах клиентов)
Канбан — система организации производства и снабжения, позволяющая реализовать принцип «точно в срок».

Не все же создают опросы, некоторым работать приходится :D
И во время работы невольно приходят к одной из методологий, о которой ни разу не слышали.

С такими вариантами надо проводить опрос среди соответствующих специалистов. Среди обычных разработчиков и студий тут победитель ясен без голосования.

Это примерно как, предложить в обществе интеллигентных и не очень* людей травку Канабис, в то время как 99% (субъективно) присутствующих не знаю что это за трава. А предложи им общеизвестное название — поймут** 99%.

* то есть. не увлекающихся этим делом
** я не говорю о согласие
This comment wasn’t rated yet0
В прошлой команде у нас была методология «как получится» и мы умудрялись писать и ядро без, которое использовалось в пяти независимых друг от друга приложениях без особых проблем, хотя заказчик был тот еще. Да у нас даже тестировщиков не было. В текущей команде у нас скрам практически по всем правилам, с досками, спринтами и тестированием и мы срываем сроки из-за того что не понимаем как сделать правильно — как всегда архитектура не учитывала неожиданных поворотов событий )

Мое личное мнение такое, что на самом деле не так важна методология как слаженная команда, хорошая архитектура и понятный код
Total votes 3: ↑3 and ↓0+3
+1

Есть отличная статья Алистера Коберна «Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения».

Оттуда:

1. Практически любую методологию можно с успехом применять в каком-нибудь проекте.

2. Любая методология может привести к провалу проекта.

3. Тяжеловесные методологии тоже могут успешно применяться в работе.

4. Облегченные методологии чаще приводят к успеху, и, что более важно, разработчики сами говорят, что успех проекта был обеспечен именно методологией.
Total votes 1: ↑1 and ↓0+1
UFO just landed and posted this here
А за какой вариант нужно голосовать, если рабочее время тратится непосредственно на работу, а не соответствие методологиям?
Total votes 4: ↑3 and ↓1+2
В зависимости от получаемого результата — или 'Как получится', или 'Через ж… у'.
Прям как у нас :)
Total votes 3: ↑3 and ↓0+3
UFO just landed and posted this here
Не могу определится, а Через %опу + итерации, это можно назвать «Agile собственного приготовления»?
Total votes 1: ↑1 and ↓0+1
Итерации были давно :) Так что вопрос очень правильный.
This comment wasn’t rated yet0
FDD + пиши код, блеать + херак в продакшн. Очень эффективно в сферах, где ошибки не критичны и есть возможность их исправить.

А Срам — это методика очковтирательства для манагеров, где можно годами рубить бабло закрывая незначительные фичи и баги, отодвигая или размазывая критичные проблемы.
Total votes 1: ↑1 and ↓0+1
Web-разработка крупных проектов в непосредственном контакте с заказчиком. Kanban + оценка по времени тасков + периодические митинги. Scrum так ни разу не удалось применить из-за его ограничений: фиксированный спринт и полная взаимозамеяемость членов команды друг другом. На практике второе условие не соблюдается почти никогда, да и с первым тоже сложно.
Total votes 2: ↑2 and ↓0+2
а PMBOK вы не относите к методологии? Мы например у себя используем ее, и у нас все получается.
Пришлось поставить другое.
This comment wasn’t rated yet0
Спасибо за комментарий — в следующий раз сделаем, да. А то меня вот и Иван Селиховкин (наш эксперт по управлению проектами) всячески застыдил. :)
This comment wasn’t rated yet0
PMBoK не методология, это «свод знаний».

Нельзя просто так взять, и применить PMBoK. :) (разве что под монитор подложить)

А вот строить управление своими проектами, применяя знания и рекомендации, вырванные из контекста PMBoK, неправильно интерпретированные и не туда приспособленные, можно запросто. Получится «что-то собственного приготовления».
This comment wasn’t rated yet0
Насчет того, что правильно применять знания PMBOK — это далеко не просто, тут полностью согласен.
Леонид, вы случайно не работали в 1 из 2 компаний, лидеров на рынке России по предоставлению услуг УП на базе PMBOK? (Не буду называть, какие. Думаю вы меня поймете)
This comment wasn’t rated yet0
Да, в управлении (особенно — в разработке) теоретические знания применять непросто. Из БоКа или откуда бы там ни было. Банально в силу его, управления, двойственной природы.

Полагаю, что не работал. По крайней мере, задачами, связанными с управленческими услугами «на продажу», не занимался.

This comment wasn’t rated yet0
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr