Scrum, Agile и иже с ними
Личный опыт работы с разными аджайл-подходами показал что всё это очень круто и весело но только при 2 условиях.
1) В команде есть не только любители попиздеть, но и действительно толковые люди. ПРичём этих толковых должно быть больше
2) Ведётся именно разработка, а не разработка+поддержка. Иначе невозможно выдержать итеративный ритм выкладок, и, соответсвенно, спринтов.
1) В команде есть не только любители попиздеть, но и действительно толковые люди. ПРичём этих толковых должно быть больше
2) Ведётся именно разработка, а не разработка+поддержка. Иначе невозможно выдержать итеративный ритм выкладок, и, соответсвенно, спринтов.
Пара вопросов:
1. Что за продукт разрабатывали, насколько большой, сколько человек в команде?
2. Проект закрыт и развитие не подразумевается ?
3. Если проект закрыт, насколько проблемным видется его возобновление или просто встали с конечной точки и поехали ?
4. Проблема с ТП связана с ограниченным ресурсом (нехваткой людей) или же проблема связана с усложнением функций продукта (ТП не успевает за изменениями)?
1. Что за продукт разрабатывали, насколько большой, сколько человек в команде?
2. Проект закрыт и развитие не подразумевается ?
3. Если проект закрыт, насколько проблемным видется его возобновление или просто встали с конечной точки и поехали ?
4. Проблема с ТП связана с ограниченным ресурсом (нехваткой людей) или же проблема связана с усложнением функций продукта (ТП не успевает за изменениями)?
Считаю, что это всё околосектантские технологии. В работе лучше думать головой и проектировать "на бумаге" в терминах предметной области и сразу писать надежный и простой код. А если квалификации программистов не хватает, то начинается всякая суета и ухищрения вроде agile и scrum.
Считаю, что это всё околосектантские технологии. В работе лучше думать головой и проектировать "на бумаге" в терминах предметной области и сразу писать надежный и простой код. А если квалификации программистов не хватает, то начинается всякая суета и ухищрения вроде agile и scrum.Agile Development - это целый класс технологий, из которых многие (например, TDD) довольно удобны в работе.
ты не в теме, погуляй.
Считаю, что это всё околосектантские технологии. В работе лучше думать головой и проектировать "на бумаге" в терминах предметной области и сразу писать надежный и простой код. А если квалификации программистов не хватает, то начинается всякая суета и ухищрения вроде agile и scrum.
Agile Development - это целый класс технологий, из которых многие (например, TDD) довольно удобны в работе.Только в работе? А если для дома такое брать? Всякие хобби-проекты в одиночку - будет ок использовать?
хобби-проекты в одиночкудаа, одной левой!
тупой боян, даже объяснять не буду.
Погулял бы сам, проветрил ум от agile-словоблудия!
Считаю, что вообще ничего не надо, просто садишься и пишешь проект. А кто так не может - все дураки.
C 33 стороны разработка действительно большого проекта силами > 3 разработчиков уже требует адекватного менеджмента. Ибо просто написанием кода нихера не сделать
адекватного менеджментауправление чего? кода, быдло программистов или чего?
как показывает практика >3 программеров уже не умеют мирно декомпозировать и распределять задачи.
Выпадает взаимозаменяемость (каждый делает строго свой кусок и в остальные никто не лезет).
И самое стрёмное - программеры могут вполне удариться в перфекционизм и рефакторинг
Выпадает взаимозаменяемость (каждый делает строго свой кусок и в остальные никто не лезет).
И самое стрёмное - программеры могут вполне удариться в перфекционизм и рефакторинг
не умеют мирно декомпозировать и распределять задачи.Если не умеют декомпозировать, то это по определению плохие программисты, об этом еще Дейкстра писал.
... мирно ...Есть иерархия программистов младший, простой, старший, ведущий.
Выпадает взаимозаменяемость (каждый делает строго свой кусок и в остальные никто не лезет).
что хорошо или плохо?
И самое стрёмное - программеры могут вполне удариться в перфекционизм и рефакторингой, да мало ли какой херней могут страдать дураки
Это всё лирика. Словоблудие уровня аджайл презентаций.
Я про личный опыт с адекватными и соображающими людьми
это уже частично менеджмент
Я про личный опыт с адекватными и соображающими людьми
Есть иерархия программистов младший, простой, старший, ведущий.
это уже частично менеджмент
Если не умеют декомпозировать, то это по определению плохие программисты, об этом еще Дейкстра писал.Есть разница между "не умеют декомпозировать", "не умеют декомпозировать и распределять задачи" и "не умеют мирно декомпозировать и распределять задачи"
жизненная ситуция: есть задача X. она декомпозируется на A,B,C
Задачу А и B успешно и уверенно делает один человек, а вот с задачей С лучше справится другой.
И тут начинаются конфликты а-ля "я лучше сам всё сделаю, не надо мне помощников для части задачи", "да мне в падлу с ним это делать, он апи хреново сделает, не хочу в его коде разбираться и вообще он сам хочет всё сделать".
В итоге мы имеем недогруженного своей работой второго, и перегруженного первого. Который ещё и затупит при выполнении не профильной задачи
добавь к этому количество модулей/команд >30 , интеграцию с внешними подсистемами, а следовательно срачь кому и что менять, да еще и заказчика, который четко требования сформулировать не может/не хочет, потому-что либо просто нет экспертизы, или если она есть, то конкретные люди брать на себя ответсвенность не хотят и тянут.
Каким образом в компании это внедрено? (интересует практика)обычно либо внедрён scrum-no, либо команда работает аджайлно, но никак это не называет
Agile сам по себе это всего лишь несколько мыслей/идей
типа там:
1. ты делаешь продукт не для себя а для клиента, поэтому думай что клиенту нужно а не что тебе прикольно запрогать
2. ты должен уважать своих сотрудников/коллег и даже уборщиц иначе они будут неэффективно работать или мешать другим эффективно работать
Пример такой компании - Apple и продукт айфон
Пример не такой компании - Microsoft и продукт Windows XP
Подчеркиваю именно продукт, потому что вполне допускаю что другие продукты этих компаний совсем по другмоу устроены.
Всяие scrum, kanban и т.п. это конкретные рекомендации о том что можно сделать чтобы улучшить свою эффективность и начать работать в соответствии с Ajile идеями
Scrum-no - это шуточное название того как на самом деле большинство команд используют Scrum. Аналог поговорки: научи дурака богу молиться он и лоб расшибет.
Самый часто нарушаемый принцип Scrum - нет "команды". "Команда" в scrum это одно из самых главных. В "команде" должен быть идеально дружный сработавшийся коллектив. Если кто-то хоть как-то выделяется - его необходимо тут же менять на другого. Пример несоответствия: все любят лыжи, а он любит коньки.
И самая большая проблема не то что законодательство не позволяет увольнять человека в секунды или что трудно найти других людей на рынке труда. А то что никто не может решиться уволить лучшего сотрудника только из-за того что он не соответствует этой данной конкретной команде.
Пример команды - компания Valve.
в соответствии с Ajile идеямиПардон, тут возможно двоякое толкование, уточни плз.
Пардон, тут возможно двоякое толкование, уточни плз.Описка по Фрейду.
> "Команда" в scrum это одно из самых главных.
> В "команде" должен быть идеально дружный сработавшийся коллектив.
> Если кто-то хоть как-то выделяется - его необходимо тут же менять на другого.
Тоталитарасты ликуют.
---
...Я работаю антинаучным аферистом...
> В "команде" должен быть идеально дружный сработавшийся коллектив.
> Если кто-то хоть как-то выделяется - его необходимо тут же менять на другого.
Тоталитарасты ликуют.
---
...Я работаю антинаучным аферистом...
> "Команда" в scrum это одно из самых главных.Тоталитарасты ликуют.
> В "команде" должен быть идеально дружный сработавшийся коллектив.
> Если кто-то хоть как-то выделяется - его необходимо тут же менять на другого.
та не
теоретики
Оставить комментарий
forenius
кто реально использует при разработке ?Каким образом в компании это внедрено? (интересует практика)