Цена за отсутствие гибкости бывает не меньше.
Дело не в этом, есть такая замануха agile = дешевле в разы. Я про это
Sergey
Sergey
Да вы жгете :)
Vladimir
Дело не в этом, есть такая замануха agile = дешевле в разы. Я про это
Почему не в этом? Цена изменений бывает слишком высока.
Sergey
Дело не в этом, есть такая замануха agile = дешевле в разы. Я про это
Ох уж эти сказочники (с) :)
Oleg
Сергей удивляет каждый раз)
Sergey
Ох уж эти сказочники (с) :)
Суровая реальность :) Раз вы гибкие, то вам это ничего не стоит :)
Sergey
Почему не в этом? Цена изменений бывает слишком высока.
Да, и зачастую не важно какой методогией пользуешься, но есть вера у заказчиков, что цену можно снизить просто применив «правильную» методогию.
Vladimir
Да, и зачастую не важно какой методогией пользуешься, но есть вера у заказчиков, что цену можно снизить просто применив «правильную» методогию.
А разве цена не снижается, когда применяешь "правильную методологию"?
Sergey
А разве цена не снижается, когда применяешь "правильную методологию"?
Вот можешь привести такой пример? Желательно с цифрами.
Sergey
У меня пока только отрицательные примеры.
Oleg
Довольно часто такое бывает. Если вы работали по вотерфоллу, то зачастую заказчик пытается максимально детализированно описать все, в т.ч. кучу фич, без какого либо обоснования. По эджайлу эти фичи могут быть урезаны до начала разработки.
Vladimir
У меня тоже только отрицательные. Немного верну беседу в русло тех долга.
Есть мнение, что качество продукта дается бесплатно в больших проектах.
Почему так? Потому что о нем думают заранее, тратят на это много времени в начале, но по итогу - имеют хорошую модель предметки, имеют хорошее разделение на слои, имеют меньше зависимостей между модулями и т.д. На это надо потратить время да, зато через 2 года не придется 3 дня искать опечатку.
Цифр привести не могу, но видел развитие двух похожих проектов, в одном думали о качестве, в другом - нет. Разница в бажности была ощутима.
Oleg
на качество влияют сроки
Alexey
Цена этому техдолг
В правильном Agile-процессе техдолг отсутствует как класс.
потому что стремление к Качеству обеспечивается за счет:
1. тесты первыми
2. переработка кода
3. непрерывная интеграция.
4. Простой дизайн
Техдолга не - потому что переработка кода идет всегда , в каждой задаче.
Тесты обеспечивают - высокую надежность.
Тесты первыми - обеспечивают минимизацию рабочего кода, мы не предполагаем что "наверное нам эта функция потребуется" а уже точно знаем какие функции требуются, а какие нет.
Конечно чтобы "Тесты первыми " работало нужно понимать как работает вся система, а значит появляется - описание поведения первым, описание работы пользователя (Руководство по Эксплуатации) первым. и тд.
Плата за гибкость - это компромис между "минимизируй усилия сейчас" и "давай заложим точки расширения" . Но разработка через тесты зачастую сама закладывает нужную гибкость и мобильность, за счет того, что мы хотим тестировать МЕНЬШЕ и делаем более автономные объекты не требующие много вешних связей. А если таковые нужны, то интерфейсы создаются тут же, на месте, что неожиданно "детонирует" на поздних фазах когда "А нам надо бы... - о! у же все есть".
Конечно если проект поворачивает на 90 градусов то, это значит, что половина существующего кода отправляется в корзину. Но опять же принцип "заказчик и команда работают вместе" - это значит ежедневно в тесном контакте, а не раз в неделю. Это снижает недопонимание и рисики такого поворота но и повышает нагрузку на "заказчика" - это тоже плата за гибкость. Но в тоже время, это плата за получение именно того результата который нужен, а не который опеределен в "жестком" контракте.
Denis
Товарищи, еще не пятница, но тут есть филосовский вопросец, который обсуждали с моим товарищем. Он говорит, дескать Agile - это фикция (ну это наброс конечно). Но аргумент у него очень любопытный. Говорит, что суть критики водопада в том, что дорого вносить изменения на поздних стадиях проекта. Но не дороже ли это в Agile?! В водопаде есть какой-никакой, но анализ проекта до начала, что готовит архитектуру к возможным изменениям. Да, угадать сразу все сложно. Но может даже "зафакапленный" водопад лучше Agile? Типа пытаемся делать водопад, но держим в уме, что итерации неизбежны. Где подвох?
Alexey
конкретные практики по обеспечения качества могут быть и другими), важно, что его нужно удерживать)), а техдолг возникает, особенно, если изменения на поздних стадиях))
Поговорим о Качестве. список практик студию! %)
Alexey
Товарищи, еще не пятница, но тут есть филосовский вопросец, который обсуждали с моим товарищем. Он говорит, дескать Agile - это фикция (ну это наброс конечно). Но аргумент у него очень любопытный. Говорит, что суть критики водопада в том, что дорого вносить изменения на поздних стадиях проекта. Но не дороже ли это в Agile?! В водопаде есть какой-никакой, но анализ проекта до начала, что готовит архитектуру к возможным изменениям. Да, угадать сразу все сложно. Но может даже "зафакапленный" водопад лучше Agile? Типа пытаемся делать водопад, но держим в уме, что итерации неизбежны. Где подвох?
Подвох в подмене понятий.
1. "водопада" не существовало.
2. Agile != Scrum
🦠
планировалось, что user path такой, а оказалось, что бизнес внес изменения в процесс и какой-то из этапов проскакивается, хотя в коде и тестах он покрыт
🦠
воткнули быстрый костыль, убрали проверку в тесте - ура, техдолг возник, тесты этот кейс не покрывают, цифра покрытия 100%
🦠
техдолг != баги
Denis
Подвох в подмене понятий.
1. "водопада" не существовало.
2. Agile != Scrum
А по-подробней? Что это меняет? Да, в оригинальной работе водопад был итеративный, но так и лучше.
Sergey
А по-подробней? Что это меняет? Да, в оригинальной работе водопад был итеративный, но так и лучше.
Водопад это модель разработки! МОДЕЛЬ которой не существует в природе.
В рамках этой модели не подразумевается **воообще** никаких измений. Как написано, так и слелано
Alexey
А по-подробней? Что это меняет? Да, в оригинальной работе водопад был итеративный, но так и лучше.
» В водопаде есть какой-никакой, но анализ проекта до начала, что готовит архитектуру к возможным изменениям.
вот тут противопоставление.
в Scrum - поставка ценности каждый спринт , и длительное проектирование не рассматривается (нафига это коммуникационному каркасу?)
основной Agile процесс для разрабоки ПО
http://www.extremeprogramming.org/map/images/project.gif
Denis
Водопад это модель разработки! МОДЕЛЬ которой не существует в природе.
В рамках этой модели не подразумевается **воообще** никаких измений. Как написано, так и слелано
Ну тут уже упомянули, в оригинальной работе модель водопада таки итеративная
Denis
» В водопаде есть какой-никакой, но анализ проекта до начала, что готовит архитектуру к возможным изменениям.
вот тут противопоставление.
в Scrum - поставка ценности каждый спринт , и длительное проектирование не рассматривается (нафига это коммуникационному каркасу?)
основной Agile процесс для разрабоки ПО
http://www.extremeprogramming.org/map/images/project.gif
Если переформулировать, а является ли постоянная поставка ценности sustainable процессом? Если да, то что ее обеспечивает? Что если упрешься в архитектурное противоречие, которое нельзя исправить итеративно?
Denis
Я это для себя понимаю так, что мы просто берём на себя риск того, что скрам проект станет набором костылей к концу проекта. И это ок. То есть процесс быстрый, но в нем действительно больше рисков.
============ FALCON ============
Задам тупой вопрос: а что такое тех долг?)
Aijan
Задам тупой вопрос: а что такое тех долг?)
Аман, вспоминаю твой приезд к нам и аналогичный вопрос))
============ FALCON ============
😁
Aijan
кстати, было очень полезно
============ FALCON ============
Тогда я спрашивал про майндсет кажется)
Aijan
и про техдолг тоже
Aijan
вот тогда до меня дошло
============ FALCON ============
Аа)
============ FALCON ============
Рад быть полезен)
Sergey
Что такое техдолг есть в глоссарии на scrum.org, сейчас попробую найти
============ FALCON ============
А ечли мы не по скраму работаем?
Denis
Кстати по техдолгу. Не всякий техдолг можно выплатить практически. Например, если пришло осознание того, что база данных выбрана не правильно, то обычно или осень долгий процесс переделывания проекта или просто данность с которой живут дальше.
Sergey
https://www.scrum.org/resources/scrum-glossary Technical Debt: the typically unpredictable overhead of maintaining the product, often caused by less than ideal design decisions, contributing to the total cost of ownership. May exist unintentionally in the Increment or introduced purposefully to realize value earlier.
Alexey
Если переформулировать, а является ли постоянная поставка ценности sustainable процессом? Если да, то что ее обеспечивает? Что если упрешься в архитектурное противоречие, которое нельзя исправить итеративно?
Постоянная поставка - это следствие.
Базовая основа постоянного прцоесса - непрерывная интеграция, качество и быстрая обратная связь.
Мы в своей практике "вшивали" нерперывное проектирование наперёд в сам процесс.
Все что намечалось к разработке было запроектировано. это те самые "Achitecture Spike" (архитектурные вбросы)
А если новое требование запрашивает реинжиниринг архитектуры (потому что протитворечие есть), то это делается частями. Если система накрыта тестами = это безопасно. Как правило, ключевые изменения для перехода на новую архитектуру делаются за 1-3 недели после подготовки всей обвязки.
Denis
Постоянная поставка - это следствие.
Базовая основа постоянного прцоесса - непрерывная интеграция, качество и быстрая обратная связь.
Мы в своей практике "вшивали" нерперывное проектирование наперёд в сам процесс.
Все что намечалось к разработке было запроектировано. это те самые "Achitecture Spike" (архитектурные вбросы)
А если новое требование запрашивает реинжиниринг архитектуры (потому что протитворечие есть), то это делается частями. Если система накрыта тестами = это безопасно. Как правило, ключевые изменения для перехода на новую архитектуру делаются за 1-3 недели после подготовки всей обвязки.
Вот как-то про 1-3 неделю не очень верится. Я всегда работал по agile, но и всегда знал и понимал эту проблему - переход на новую технологию занимает столько времени, что почти не происходит практически. Только после наступления кризиса.
Denis
А тут мне товарищ как бы ткнул носом что ли, что это не «жизненные сложности», а скорее проблема Agile
Alexey
Кстати по техдолгу. Не всякий техдолг можно выплатить практически. Например, если пришло осознание того, что база данных выбрана не правильно, то обычно или осень долгий процесс переделывания проекта или просто данность с которой живут дальше.
В случае с БД - для перехода на новую - просто вшивается дублирование операций в обе БД то есть запускаем зеркалирование.
есть 5 фаз:
1. Начальное состояние
2. Запуск. Новая архитектура копирует из старой данные и зеркалирует все операции.
3. Миграция. Большая часть потребителей используют новый метод.
4. Обратная совместимость - новая архиектура становится мастером , но поддерживает старый метод.
5. Полный переход. Все потребители используют только новый метод. Поддержка старого метода убирается.
"поребитель" - подсистемы, классы использующие целевую подсистему.
Есть риск что система может зависнуть на фазе 3. просто потому что новая архитектура не имеет такого же удобного способа доступа. Более мелкие детали или структура объектов. Но за счет того, что новые части системы будут делаться уже на новой архитектуре, то система плавно перейдет на фазу 4.
Этот способ лично я применил несколько раз на разных проектах, обеспечивая непрерывную поставку продукта.
============ FALCON ============
https://youtu.be/SfWCRl75Kas
============ FALCON ============
Интересно рассуждает про тех долг
🦠
важнее понять, что без периодической выплаты по техдолгу никакой постоянной велосити и стабильного бизнес-инкремента не достичь
🦠
техдолг в этом случае субоптимальное решение в пользу решения "здесь и сейчас"
============ FALCON ============
Статистика говорит что все так и есть, но еще говорят что статистика врет)
============ FALCON ============
В общем it depends
Pavel
Из-за обновившегося клиента я вижу, что меня где-то упоминали в чате, но не могу найти, где и в каком контексте
Pavel
Если был вопрос, продублируйте пожалуйста.
Pavel
опять играли в экзамен, а я все пропустил?
Pavel
Нашли?:)
Yuriy
50/50, конечно
Yuriy
я думаю, все как обычно, решается на уровне "люди и взаимодействие" 😄
Pavel
Ну... да, это же Agile :)
Yuriy
ночные игры 😎
Sergey
Q. A team practices pair programming. Jason is one team member about who everyone has come to you to complain about him. Anyone who pairs with him gets caught in design and architecture decision discussion..
As a scrum master what will your do(choose two)
a)Raise a concern to HR and get Jason removed from the team
b)Take Jason aside and express your concern over this behavior. Tell him to act as team player and comply to team decision
c)You suggest to open it up with full team now so that is does not further worsen. You propose to help initiate this discussion but not being the one to start it.
d)You observe this in Retrospective whether discussion on design and architecture is initiated, if not then check how comfortable is everyone with the way it is handled in project
Sergey
У меня тут в одной команде человек стал опаздывать часто. Так они втихушку HR пожаловались :) Он с ним поговорил. Как Вы думаете, помогла?
Pavel
Думаю нет :)
Pavel
Вообще идея команды, которая втихую жалуется HR...
Pavel
Smells like Antipattern!
Sergey
Так ведь не сказали даже, потом выяснил :) не помогл им HR конечно. Мой ответ cd
Sergey
Сами разобрались потом.
Sergey
Q. After several Sprints into a project, increment got release in the production and key stakeholders complains on performance issues. Even the PO agrees, he comes to Scrum Master. What should the scrum master do(choose one)
a)Tell PO that dev team own DoD and it is their duty to to decide acceptable perfromance standard
b)Encourage the PO to bring this up to the team so that team can come up with improved DoD, with strong SLA requirements for performance issues
c)Wait till retrospective , as this is the appropriate time for dev team to re-consider the DoD
Pavel
Сергей, у меня побочный вопрос - откуда ты взял все эти вопросы?:)
Pavel
И есть ли у тебя полный список отдельным файлом?
Sergey
Неа. Полного нет. Есть пара ресурсов, вот один из них http://mlapshin.com/index.php/blog/scrum-questions/comment-page-4/#comments
Sergey
Я сейчас ищу вопросы по фасилитации, у меня тамый провал
Pavel
Мне просто кажется, что посвятить один из bI-Weekly разбору этих вопросов было бы клево.
Sergey
Pavel
Две зоны, в которых у меня провал - урпавление бэклогом и фасилитация :)