Comments 25
1. От Эджайла не становятся счастливее автоматически, и в жизни каждого бывает момент, когда он весь этот Эджайл самозабвенно ненавидит.
2. Никогда не встречал человека, которому Саентология помогала на самом деле, а не для продаж этой самой Саентологии. А наши (и не только наши) разработчики фигачат двухнедельными спринтами, и вроде все работает, переходить на другую систему не планируют. Хотя… сейчас спрошу. Нет, не планируют.)
… А общее у них то, что мы не продаем, ни Эджайл, ни Саентологию. :-)
Прочитал первую и вторую из вышеозначенных книг. На мой субъективный взгляд книги совершенно бесполезные, по меньшей мере в плане практическом, в софтверных проектах. Как с точки зрения управляющего разработкой, так и с точки зрения человека, который пишет код. Мой список правильных книг про гибкую разработку:
- Кент Бек "Экстремальное программирование"
- Кент Бек "Экстремальное программирование. Разработка через тестирование"
- Роберт Мартин "Чистый Agile. Основы гибкости"
- Роберт Мартин "Идеальный программист"
- Роберт Мартин "Чистый код"
- Роберт Мартин "Чистая архитектура"
- Роберт Мартин "Гибкая разработка программ на Java и C++. Принципы, паттерны и методики"
- Роберт Мартин "Принципы, паттерны и методики гибкой разработки на языке C#"
- Мартин Фаулер "Рефакторинг"
… Если вы думаете, что у нас внутри команды есть согласие по поводу полезности конкретных книг, то нет, его нет.) У каждого свой глобус.) Автор об этом честно написал в начале статьи. Так мы и пришли к анализу статистики: решили посмотреть, что читают больше.
Так Agile в исходном виде даже не методология… набор принципов… не более.
Ну а что сейчас нового появилось из практик, чего не было в 2001 году?
Мдауш… Однако извините за неточность вопроса. Я под практиками подразумевал не ритуалы вроде "куры со свиньями танцуют под бубен по понедельникам", а про инженерные практики, типа TDD, CI/CD.
Ну блин… эта ветка комментариев стартанула с принципов Agile манифеста, которые с одной стороны однозначно привязаны к софтверной разработке, с другой стороны вообще не являются никакой не методологией и не организацией процессов, а лишь набором заявлений.
Ну и если аджайл это просто набор принципов, то скрам и канбан это уже конкретные методики. А я как бы «влез» в ветку после
зато куча вопросов по типу чем аджайл, скрам и канбан различаются.
Как скажете. Будь по вашему.
Ритуалы, описанные в двух первых вышеозначенных книгах я считаю бесполезной ерундой, а чтение этих книг, бесполезной тратой времени с точки зрения процесса софтверной разработки.
Что лично вы подразумеваете под терминами "скрам" и "канбан" мне конечно неизвестно. Может там у вас и впрямь алмазы-бриллианты-конкретные-методики.
И если уж на то пошло, то я вообще хороших книг на эту тематику пока не видел. Потому что это всё очень субъективно и индивидуально. И какой-то серебрянной пули не существует.
И всё что можно делать это в первую очередь придерживаться манифеста. А потом уже если и выбрал какую-то конкретную методику, то хотя бы просто не нарушать её правила. А правила того же скрама спокойно гуглятся и вообще влезают в небольшую брошюрку.
Канбан конечно менее жёстко дефинирован, но и него есть вещи вроде вот этого
Нашел ошибку в статье: Указана книга Майка Кона "Scrum: гибкая разработка ПО", а обложка другой книги и автора. По ссылка указана верная иллюстрация — https://analystpages.ru/education/books/%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D1%8B-%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B8/
Я внедрял. Да я думаю много кто внедрял. Однако я ни разу не видел чтобы в реальности оценки эти хоть сколько-нибудь точными. В общем на мой взгляд story point-ы это вообще хрень полная.
Пользовательские истории — это на мой взгляд удобная штука. Будучи включенными в итерацию, они однозначно и понятно показывают и заказчику и исполнителю, что они договорились реализовать к следующему деплою.
Однако я ни разу не видел чтобы в реальности оценки эти хоть сколько-нибудь точными. В общем на мой взгляд story point-ы это вообще хрень полная.
Если брать каждую user story по отдельности, то на мой взгляд тоже оценки редко попадают прямо в точку. Но вот если брать в весь спринт в среднем, то рано или поздно начинаешь угадывать сколько этих самых user story влезет в твой спринт. Естественно ошибки всё равно бывают, но опять же по моему опыту они со временем происходят всё реже и сами по себе становятся меньше.
Правда это работает только если команда не меняется. Поменяй даже одного человека и по моему опыту приходится «настриваться» чуть ли не с нуля…
1. Вы работали с классическими сторис, которые состоят из короткого описания и списка Acceptance Criteria, а все дизайны и более подробные требования находятся в спек шите эпика? QA-команда участвовала в написании AC?
2. Если через какое-то время после релиза фичи она меняется, должен заводиться новый тикет, в котором частично будет тот же спек шит, или используется старый эпик?
3. Если над фичами работает несколько команд, должны заводиться в продуктовом борде с эпиками в качестве свимлайнов, и к каждой стори в спринте дев команды заводят таски уже в своих бордах?
4. Если фичей в продукте много, как группируются эпики? Я встречал подход, когда вместо эпиков используются фичи, которые уже группируются в эпики, но не очень понятно, насколько это корректно.
5. Ну и самый неочевидный для меня вопрос: как все это правильно увязать со спринтами продуктовой и дизайн-команды?
Если где-то все это уже описано, буду очень признателен за ссылку.
Добавьте оригинальные названия на английском, чтобы проще их искать было
"100 лучших книг про Аджайл" - это, вообще-то, известный мем...
Восемь самых популярных книг по Agile, Scrum и Kanban