Справка - Поиск - Участники - Войти - Регистрация
Полная версия: IT специалист кто это?
Частный клуб Алекса Экслера > Деловые вопросы
Страницы: 1, 2, 3, 4
Troubleshooter
8 ноября 2015, 14:33

Dead Knight написал:
Это одновременно и правда и ложь. Правда, что ошибки в дизайне ватерфолла вылазят в конце, ложь в том, что когда об этом ты знаешь, ты начинаешь очень внимательно относится к этапам дизайна и планирования. В скраме, я чаще всего наблюдал обратную ситуацию, казалось бы, все правильно и система габкая, однако ошибки возникающие от недостаточного внимания к дизайну начинают складываться, и с какого-то момента система резко перестает быть стабильно.

Здесь перепутаны две совершенно разные вещи. Профессиализм участников проекта отвечающих за дизайн приложения и планирование со способом контроля создания приложенмя на разных стадиях разработки. Цена ошибки при waterfall часто бывает значительно выше. Да, скрам не поможет создать дизайн приложения. Он поможет быстрей обноружить проблемы и соответсвенно понять что нужно что то делать по этому поводу. Непосредственное создание дизайна не относится ни к Скраму ни к waterfall, а зависит от знаний и способностей человека (иди группы людей) отвечающего за дизайн приложения
Не Кролик
8 ноября 2015, 20:26

whitekiller написал: У меня сейчас один проект идет под скрамом и довольно успешно.

Я не говорил, что это невозможно. просто отметил, что редко встречается.

whitekiller написал: Главное преимущество - ежедневные, а иногда и 3-4 раза в день отчеты о проделанной работе.

Отчет - это вообще излишне. Пустая трата времени. Если у работников короткие таски, они их просто чекинят с автоматической записью в трекер (Jira, Redmine или что там еще). Менеджер отслеживает по трекеру как продвигается проект. Хочет - ежедневно, хочет - 10 раз в день. Если таск больше дня, то требовать по нему отчет 4 раза в день означает одну из двух вещей - или работники посредственные и отлынивают от работы, когда за ними не следят, или начальнику нечем больше заняться кроме как отвлекать людей, занятых делом.
Я бы после 3 вопроса за день попытался объяснить, что мне надо создавать условия для работы, а не мешать, а на второй день подобного - начал бы рассылать резюме в другие места.

Troubleshooter написал: Было бы интересно узнать в чем отличался успешный процесс в стартапе от скрама.

Несмотря на то, что Джоел Спольски написал эту короткую статью более 15 лет назад, она куда больше помогает в работе над проектом, чем тщательное следование всяким умным словам.
BigSister
8 ноября 2015, 20:29

Не Кролик написал: Честно говоря, за всю свою карьеру мне не разу не довелось увидеть правильное использование Скрама. В во всех местах, где его применяли, единственный результат заключался в пустой трате времени и ресурсов.

У нас, в виду специфики, оно сразу было не совсем "правильным", но результаты были лучше, чем до.


Не Кролик написал: А в тех случаях, когда процесс организовывал я (будучи R&D Manager старт-апа, например), то мы прекрасно обходились без Скрама.

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


Dead Knight написал: Это одновременно и правда и ложь. Правда, что ошибки в дизайне ватерфолла вылазят в конце, ложь в том, что когда об этом ты знаешь, ты начинаешь очень внимательно относится к этапам дизайна и планирования.

Лжи нет. Сколь внимательно ни относись к дизайну и планированию, а) лопухнуться можно ещё на стадии понимания требований клиента; б) пока ты два года в поте лица трудишься над реализацией ТЗ, желания клиента уже поменялись smile.gif
BigSister
8 ноября 2015, 20:38

Не Кролик написал: Несмотря на то, что Джоел Спольски написал эту короткую статью более 15 лет назад, она куда больше помогает в работе над проектом, чем тщательное следование всяким умным словам.


For this very reason, the last company I worked at switched from WISE to InstallShield

По этой причине перешли с WISE на InstallShield

smile.gif
Не Кролик
8 ноября 2015, 20:50

BigSister написала:

smile.gif

Во-во.
Это именно то, о чем я и говорю.
Когда словам придается больше значения, чем сути.
Есть разница, что именно делает билд, тул, забытый 10 лет назад или Дженкинс?
Dead Knight
8 ноября 2015, 21:13
Вообще, все медленно скатывается к холивару. как по мне, то пофиг, какой процесс используется, если организован он правильно и есть заинтересованность разработчиков в хорошем результате, то результат скорее всего будет хорошим. А если организация через одно место, разработчики тупо занимаются логированием своего времени, написанием бесконечных отчетов и отсиживанием задницы на постоянных митингах, то ничто уже не поможет.

BigSister
8 ноября 2015, 21:31

Не Кролик написал: Во-во.
Это именно то, о чем я и говорю.
Когда словам придается больше значения, чем сути.
Есть разница, что именно делает билд, тул, забытый 10 лет назад или Дженкинс?

А я как раз о сути. Дженкинс к нам добрался вместе со скрамом smile.gif, но "в одиночку" справиться не может. У нас громадная система, с кучей модулей и разными языками. Установка системы у клиента - сам по себе отдельный проект. Собственно, дофига и версий, и клиентов. Ну и по моему опыту, "идеальными" бывают только мелкие проекты.
BigSister
8 ноября 2015, 21:32

Dead Knight написал:Вообще, все медленно скатывается к холивару.  как по мне, то пофиг, какой процесс используется, если организован он правильно и есть заинтересованность разработчиков в хорошем результате, то результат скорее всего будет хорошим. А если организация через одно место, разработчики тупо занимаются логированием своего времени, написанием бесконечных отчетов и отсиживанием задницы на постоянных митингах, то ничто уже не поможет.

Мир, дружба, жвачка smile.gif
whitekiller
8 ноября 2015, 22:19

Не Кролик написал: Я бы после 3 вопроса за день попытался объяснить, что мне надо создавать условия для работы, а не мешать, а на второй день подобного - начал бы рассылать резюме в другие места.

А кто говорил о вопросах? Просто у нас раз в квартал бывает свистопляска, когда за 3 дня надо собрать данные с порядка 20 разных систем, которые закрывают квартал в разное время и почти все руками. Это надо тщательно отслеживать и реагировать. Почему так - это другой вопрос, а пока так - скрам + Jira очень помогают. Из-за них я и вопросов почти не задаю.

Schenja
8 ноября 2015, 22:58

BigSister написала:
Лжи нет. Сколь внимательно ни относись к дизайну и планированию, а) лопухнуться можно ещё на стадии понимания требований клиента; б) пока ты два года в поте лица трудишься над реализацией ТЗ, желания клиента уже поменялись smile.gif

в) Нормативно-правовая база за эти два года поменялась так, что, даже если желания клиента и были поняты правильно, и не поменялись, все надо переписывать заново. 3d.gif
BigSister
8 ноября 2015, 23:02

Schenja написала: в) Нормативно-правовая база за эти два года поменялась так, что, даже если желания клиента и были поняты правильно, и не поменялись, все надо переписывать заново.

Яволь smile.gif
Troubleshooter
9 ноября 2015, 01:13

Не Кролик написал:

Несмотря на то, что Джоел Спольски написал эту короткую статью более 15 лет назад, она куда больше помогает в работе над проектом, чем тщательное следование всяким умным словам.

В этой статье тоже умные слова написаны. Стоит ли им следовать? wink.gif

Все что там написано, все правильно. Как это противопоставляется скраму? То что написал
Dead Knight о своем проекте это классическая ситуация, в которой многие работающие над большими проектами побывали.У меня складывается впечатление что нет понимания что такое скрам, а также опыта работы в больших проектах где скрам применялся успешно. Отсюда и сарказм поэтому поводу.
Troubleshooter
9 ноября 2015, 01:43

Dead Knight написал: Вообще, все медленно скатывается к холивару. как по мне, то пофиг, какой процесс используется, если организован он правильно и есть заинтересованность разработчиков в хорошем результате, то результат скорее всего будет хорошим. А если организация через одно место, разработчики тупо занимаются логированием своего времени, написанием бесконечных отчетов и отсиживанием задницы на постоянных митингах, то ничто уже не поможет.

Я бы не назвал это холивор. Холивор был бы если бы мы сравнивали, например, Scrum c Kanban. Изначально сравнивался скрам с waterfall (или с полным отсутствием методологии). Как процесс waterfall значально более рискован и поэтому это пройденный этап. Фактически это тоже самое как если бы кто то стал защищать разработку сложного энтерпрайз приложения на ассемблере, говоря что главное это "заинтересованность разработчиков в хорошем результате" (Уверен что похожие обсуждения были когда только стали появились структурные языки).
Troubleshooter
9 ноября 2015, 01:59

Не Кролик написал:
Во-во.
Это именно то, о чем я и говорю.
Когда словам придается больше значения, чем сути.
Есть разница, что именно делает билд, тул, забытый 10 лет назад или Дженкинс?

Если внимательно прочитать статью то там так же написано "9. Do you use the best tools money can buy". Поэтому разница есть. Но если имеется ввиду что лучше хоть какой инструмент для Continues Integration чем никакого, то я с этим согласен.
Глеб
9 ноября 2015, 03:24

Не Кролик написал:
Честно говоря, за всю свою карьеру мне не разу не довелось увидеть правильное использование Скрама. В во всех местах, где его применяли, единственный результат заключался в пустой трате времени и ресурсов.
А в тех случаях, когда процесс организовывал я (будучи R&D Manager старт-апа, например), то мы прекрасно обходились без Скрама.

Каниничного скрама практически не существует, ибо он слишком сферический и религиозный одновременно. А вот скрамовские практики в общем поле эджайла - вполне себе работают, особенно на продуктовых задачах. Стендапы, спринты, планирование, ревью и т.д.
Глеб
9 ноября 2015, 03:27

Dead Knight написал:
Это одновременно и правда и ложь. Правда, что ошибки в дизайне ватерфолла вылазят в конце, ложь в том, что когда об этом ты знаешь, ты начинаешь очень внимательно относится к этапам дизайна и планирования.

Не существует систем, которые были бы хорошо сделаны с первого раза. Несмотря на любое количество времени,отпущенного на дизайн.
Глеб
9 ноября 2015, 03:29

Troubleshooter написал:

Было бы интересно узнать в чем отличался успешный процесс в стартапе от скрама.

Например тем, что там может не быть спринтов. Ибо они реально далеко не всегда нужны.
Не Кролик
9 ноября 2015, 03:54

Глеб написал:
Каниничного скрама практически не существует, ибо он слишком сферический и религиозный одновременно. А вот скрамовские практики в общем поле эджайла - вполне себе работают, особенно на продуктовых задачах. Стендапы, спринты, планирование, ревью и т.д.

Вот как-то так. Берешь разумные идеи и используешь те из них, которые годятся в конкретном проекте.
Проблема в том, что когда начальство решает использовать Скрам, то оно использует СКРАМ - все сразу и без разбора. Написано Спринт, значит будет Спринт (я у себя приводил пример, как Скрам-мастер попросил разделить не помещающийся в Спринт таск и радостно утвердил разделение на первую фазу и вторую фазу. А фигли, это его профессия, он ведет десяток разных проектов и один хрен не разбирается ни в программировании, ни в химии, в которой наш проект специализируется). Сказано Скрам-покер, значит будет покер и в нем будут участвовать наравне кодеры и график дизайнеры.
Можно сказать, что это частности неправильного применения, но проблема в том, что это как раз обыденность, ибо, как написано у Мерфи, каждый начальник стремится выйти на пик своей неквалифицированности, а если в моде Скрам, то оттуда, с этого пика он и прикажет использовать "канонический" скрам.
Troubleshooter
9 ноября 2015, 11:13

Глеб написал:
Например тем, что там может не быть спринтов. Ибо они реально далеко не всегда нужны.

Ты можешь сказать что такое спринт зачем, что он даёт и затем описать проект где бы он не использовался?
Troubleshooter
9 ноября 2015, 11:29

Глеб написал:
Каниничного скрама практически не существует, ибо он слишком сферический и религиозный одновременно. А вот скрамовские практики в общем поле эджайла - вполне себе работают, особенно на продуктовых задачах. Стендапы, спринты, планирование, ревью и т.д.

Проблема этого обсуждения в том что, у обсуждабщих нет понимания что такое Скрам (естественно сужу на основании написанного). В одну кучу валятся технические части разработки софта (например код ревью, который будет при любой методологии, хоть waterfall, хоть скрам. Раньше это были элементы Continues Integration, которые тоже можно организовать при любой методологи) с организацией работы разработчиков (планирование, коммуникация между разработчиками, контроль).

Из-за этой каши появляются выражения "Каниничного скрама практически не существует, ибо он слишком сферический и религиозный одновременно." Это примерно как если бы сказать, "каноническим алгоритмом сортировки слиянием ни кто не пользуется ибо он слишком сферический и религиозный одновременно".
Глеб
9 ноября 2015, 12:17

Troubleshooter написал:
Проблема этого обсуждения в том что,  у обсуждабщих нет понимания что такое Скрам (естественно сужу на основании написанного). В одну кучу валятся технические части разработки софта (например код ревью

Я имел ввиду спринт-ревью.

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

Типичный фейл в ДНК скрам-процесса:

1) Сделали спринт
2) Запланировали следующий до полной готовности и тестирования предыдущего. Потому что иначе планирование не успеть.
3) В предыдущем полезли баги больше, чем запланировано на багфикс.
4) Баги переносятся на +1 спринт.
5) Возвращаемся на пункт 2 уже с текущим спринтом.

Недотепы делают в этом случае финт ушами и доходят даже до "багофикс-спринтов" каждые N нормальных спринтов. В итоге разработчики переключаются вообще все время и не доделывают ни одну из задач до конца. И так вплоть до увольнения директора по IT (видел подобный результат уже два раза).
До понимания, что им, например, может хватить одной канбан-доски, при этом доходит мало кто. Ибо СКРАМ.
матроскин
9 ноября 2015, 13:37

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

Сразу плюсую.
Щас уже отошел от дел.
Но в свое время пришлось поработать с контрагентом из Минвуз, который программировал нам ПЛИС для спецкомпьютера решения задач распознавания образов при обнаружении подводных лодок по их поверхностному следу.
Прошло примерно два года, пока мы начали понимать друг друга, т.е. обмениваться одними и теми же терминами.
Хотя я сам уже давно отошел от проблем ИТ, а они вообще вначале не представляли наших проблем.
Но после того, как я несколько раз свозил их на наши полигоны в Заполярье и Крыму, мы стали говорить на одном языке.
К сожалению после того, как мы почти все сделали, тему закрыли.
У нас все делается не так. inv.gif
Troubleshooter
9 ноября 2015, 14:30

Глеб написал:
Я имел ввиду спринт-ревью.

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

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



Типичный фейл в ДНК скрам-процесса:

1) Сделали спринт
2) Запланировали следующий до полной готовности и тестирования предыдущего. Потому что иначе планирование не успеть.
3) В предыдущем полезли баги больше, чем запланировано на багфикс.
4) Баги переносятся на +1 спринт.
5) Возвращаемся на пункт 2 уже с текущим спринтом.
....
До понимания, что им, например, может хватить одной канбан-доски, при этом доходит мало кто. Ибо СКРАМ.

Понятно. Ты о Scrumban слышал ?
Глеб
9 ноября 2015, 15:34

Troubleshooter
Понятно. Ты о Scrumban слышал ?

Слышал. И даже использую. Но это не скрам.
Troubleshooter
9 ноября 2015, 15:43

Глеб написал:
Слышал. И даже использую. Но это не скрам.

Другими словами утверждается что Scrum с элементами Kanban перестал быть Scrum'ом? Что там говорили о религиозности? smile.gif
Глеб
9 ноября 2015, 20:24

Troubleshooter написал:
Другими словами утверждается что Scrum с элементами Kanban перестал быть Scrum'ом? Что там говорили  о религиозности? smile.gif

Есть скрам, а есть околоскрамвский эджайл в т.ч. со скрамбаном. Нельзя просто так разбрасываться терминами, если каждый из них имеет свое определенное значение.
Troubleshooter
10 ноября 2015, 13:21

Глеб написал:
Есть скрам, а есть околоскрамвский эджайл в т.ч. со скрамбаном. Нельзя просто так разбрасываться терминами, если каждый из них имеет свое определенное значение.

Это не проблема терминологи. Нужно не только знать термины но и понимать что стоит за ними. Хорошо что такое скрамбан описано здесь:

https://en.m.wikipedia.org/wiki/Scrumban:

Scrumban is a management framework that emerges when teams employ Scrum as their chosen way of working and use the Kanban Method as a lens through which to view, understand and continuously improve how they work

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

Эта версия форума - с пониженной функциональностью. Для просмотра полной версии со всеми функциями, форматированием, картинками и т. п. нажмите сюда.
Invision Power Board © 2001-2017 Invision Power Services, Inc.
модификация - Яро & Серёга
Хостинг от «Зенон»Сервера компании «ETegro»