Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Программирование Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Ищу литературу (надоело проваливать сроки)  [new]
Програмёр
Member

Откуда: Москва
Сообщений: 2995
Всем привет.

Хочу повысить свой скилл, потому что начал замечать, что чем сложнее задача, тем больше недочётов на этапе оценки допускаю и потом за ними тянутся длинные хвосты, когда задачу оценил в 20-30 часов работы, а на реализацию ушли все 60. Полагаю основная проблема тут в моём неумении правильно и быстро проектировать систему и потому на этапе оценки сложность задачи и решение представляются совсем не такими, какими они оказываются по итогу реализации. Да и решения не всегда лучшие получаются (код легко поддерживается только первых пол года, потом возникают трудности... спустя год неизбежно появляется необходимость длительного рефакторинга).

Посоветуйте пожалуйста что по теме проектирования кода можно почитать, или если считаете, что указанные проблемы могут быть вызваны ещё чем-то, поделитесь пожалуйста литературой и по этим темам.

Заранее всем очень благодарен!

P.S. Я мог бы загуглить самостоятельно, но хотелось бы получить рекомендованную литературу именно по моей ситуации и желательно от тех, кто сам эту литературу читал :)

P.S. На всякий случай уточню: в основном занимаюсь вэбом и код пишу на php... Но как я понимаю с учётом интересующей темы это не должно иметь никакого значения :)
9 мар 19, 23:45    [21828578]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 6856
Програмёр,

хотелось бы посоветовать классиков.

https://ru.wikipedia.org/wiki/Денег_нет,_но_вы_держитесь
10 мар 19, 00:27    [21828586]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
Програмёр
Member

Откуда: Москва
Сообщений: 2995
Relic Hunter,

А кого именно из классиков? Я в вопросе литературы совсем не в теме.
Надеюсь классиков не имелось ввиду "но вы держитесь"
10 мар 19, 00:31    [21828588]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 6856
Програмёр
сложность задачи и решение представляются совсем не такими, какими они оказываются по итогу реализации
сделайте индексацию, поднимите пенсионный возраст, делов-то?
10 мар 19, 00:40    [21828590]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
Програмёр
Member

Откуда: Москва
Сообщений: 2995
Relic Hunter
Програмёр
сложность задачи и решение представляются совсем не такими, какими они оказываются по итогу реализации
сделайте индексацию, поднимите пенсионный возраст, делов-то?


Не вариант. по двум причинам:
1. Мне не нравится выполнять свою работу плохо (а срывать все планы - это плохо)
2. Мало кто согласится доплачивать, ведь нередко клиенты выбирают подрядчика и с учётом озвученной стоимости, а когда она вдруг "переиндексируется" у них возникают вполне обоснованные вопросы :)

Мы же не правительство, у нас тут конкуренция работает и свободный рынок.

Но как бы то ни было, это решение не позволит мне перейти на уровень Senior'а... так и останусь в мидлах до 60-ти, а потом мидлом и помру :)) Меня такая перспектива не устраивает.
10 мар 19, 00:59    [21828594]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
mayton
Member

Откуда: loopback
Сообщений: 39224
Програмёр
Всем привет.

Хочу повысить свой скилл, потому что начал замечать, что чем сложнее задача, тем больше недочётов на этапе оценки допускаю и потом за ними тянутся длинные хвосты, когда задачу оценил в 20-30 часов работы, а на реализацию ушли все 60. Полагаю основная проблема тут в моём неумении правильно и быстро проектировать систему и потому на этапе оценки сложность задачи и решение представляются совсем не такими, какими они оказываются по итогу реализации. Да и решения не всегда лучшие получаются (код легко поддерживается только первых пол года, потом возникают трудности... спустя год неизбежно появляется необходимость длительного рефакторинга).

Несколько мыслей.

Здесь в кучу смешано 2 разных поинта.
- эстемейшен
- поддерживаемость решения.

Надо-бы разделить.

Эстимейшен


По поводу часов. Достаточно сложно попадать в часовую оценку. Было оценено в 30 часов. Стало 60. Грубо говоря
вместо 3 дней стало 6. Это нормально для scrum/agile. Особенно если проект молодой. Никто не попадает в оценки.
Но если по результатам 2-3 спринтов реальная оценка всё равно в 2 раза больше - то можно просто делать поправку
в виде множителя.

Из личного наблюдения. Недо-эстимейт бывает там где что-то неясно или есть риски. Я в таких случаях включаю
мега-пессимизм и говорю что здесь есть ненулевой риск что "стрельнет" и это выльется в дополнительные поинты.
Вообще на планёрке надо быть пессимистом. И при этом желательно каждый день расписать.

В вашем случае если вы работали 6 дней вместо 3 надо проанализировать на что ушли лишние 3 дня и в будущем
учитывать постоянно.

Вообще. Чем больше срок - тем должны быть грубее критерии. Если задача мелкая (меньше 1 дня) - то ее можно
оценивать в часах. Если она тянется больше недели (6 рабочих дней) то часы уже не играют роли. Вы можете
добавлять к овер-эстимации дни. А дальше уже - недели. Принцип - как в относительной прогрешности. Больше
величина - больше погрешность. Когда вы вылезли за 1 неделю то плюс-минус 1 час уже роли не играют.
Добавляйте дни. Шкала чисел фибоначчи 1,2,3,5,8 - здесь как раз помогает.
10 мар 19, 01:18    [21828598]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
mayton
Member

Откуда: loopback
Сообщений: 39224
Програмёр
Да и решения не всегда лучшие получаются (код легко поддерживается только первых пол года, потом возникают трудности... спустя год неизбежно появляется необходимость длительного рефакторинга).

Посоветуйте пожалуйста что по теме проектирования кода можно почитать, или если считаете, что указанные проблемы могут быть вызваны ещё чем-то, поделитесь пожалуйста литературой и по этим темам.

Заранее всем очень благодарен!

По поводу поддерживаемости.

Я не спец в PHP и не знаю какие там могут быть вопросы длительного рефакторинга. Мне кажется хороший
вариант - позвать коллег и показать им ваш код на PHP с целью code-review и просто послушать их критику.

Критика будет неприятная. Приготовьтесь терпеть гнилые помидоры. Но каждый помидор надо запомнить
и подумать что было не так и что можно улучшить. Я сам очень долгое время не понимал пользу code-review
и теперь при любой возможности я зову коллег и прошу смотреть мой код. Это реально полезно.
Когда ты долго кодишь - твой глаз замыливается. И ты перестаёшь видеть очевидное. Это даже
не It. Это некая психо-физиология.

По поводу литературы - я сильно сомневаюсь что она поможет Вам. Но можете смотреть книжки:

Рефакторинг - Фаулера
Идеальный код - несколько авторов
***** - Роберт Мартин (не помню название)
Совершенный Код - Стив Макконел


По поводу растущей сложности внесения изменений.
Если есть признаки этой картинки (там где стоимость внесения изменений растет по эскспоненте) - там есть
растущий технический долг. И этот долг надо закрывать в процессе разаработки. Тоесть учитывать при эстимации.
Заказывайте не 30 и не 60 а все 120 часов разработки. И закрывайте все пункты которые в БУДУЩЕМ создадут
растущий CoC. Спрогнозировать это - большое искусство. Но обычно после десятка спринтов вы примерно
знаете свой проект и знаете его слабые места. Или непонятные места с точки зрения кода.
Картинка с другого сайта.
10 мар 19, 01:37    [21828603]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
Програмёр
Member

Откуда: Москва
Сообщений: 2995
mayton,

Так и пытаюсь всё делать... И по скраму давно уже пашем, и пессимистический режим ключаю, и постоянно пытаюсь по результату спринта разбирать проблемные места, и всё это приводит к улучшению, но очень медленному, при чём с перебоями :) Вот щас как-раз сдал задачу рассчитанную на день, которую 3 дня пилил (оценил в 8 баллов, а щас хочется все 24 сказать)... правда тут брал не пессимистическую оценку, а среднюю изначально... но и задачу сдаю с парочкой TODO в коде очень серьёзными. Походу на днях полезу допиливать, пока никто не нашёл тех мест, где оно гарантированно завалится.

В общем учитывая как всё медленно и сложно движется, есть ощущение, что я что-то очень неправильно делаю, и не могу понять что. Даже курс по скраму просмотрел, пытаюсь всем рекомендациям следовать, но у нас в основном проекты, к которым подобную практику сложно применить (точнее применимо всё, кроме указанной декомпозиции на задачи... никто не станет проверять по 5 раз каждую функцию на этапе разработки, чтобы проследить, что она правильно реализуется и расширяется). Ещё там была рекомендация умножать сроки в 3-4 раза, что больше похоже на костыль с пометкой "TODO: попытаться выяснить какого фига нам приходится постоянно этот коэффициент применять" :))

Какие ещё причины могут к такому приводить? Как я говорил в моём представлении только одна: мне нужно учиться лучше проектировать свои решения и желательно достаточно быстро, чтобы понимать пути решения уже на этапе оценки задачи, а не на этапе реализации, когда пришло понимание, что реализация предполагаемая на этапе оценки невозможна и первую половину задачи удалось реализовать как задумывалось, но вот с этого момента пора в другую сторону ползти :)
10 мар 19, 01:46    [21828606]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
mayton
Member

Откуда: loopback
Сообщений: 39224

Какие ещё причины могут к такому приводить? Как я говорил в моём представлении только одна: мне нужно учиться лучше проектировать свои решения и желательно достаточно быстро, чтобы понимать пути решения уже на этапе оценки задачи, а не на этапе реализации, когда пришло понимание, что реализация предполагаемая на этапе оценки невозможна и первую половину задачи удалось реализовать как задумывалось, но вот с этого момента пора в другую сторону ползти :)

Причины - скорее всего недостаток уровня senyority. Ты наверное просто мало опыта накопил.

Давай так. Чтоб топик не был эмоциональным. Если у тебя нет NDA и запретов на публикацию.
Покажи фрагмент кода (без бизнес-секретов и имен) где у тебя были проблемы. И расскажи
что ты сделал чтобы их решить.

Кто-то в топике знаток в PHP полюбому что-то подскажет.

P.S. Это не rocket science.
10 мар 19, 01:54    [21828609]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
Програмёр
Member

Откуда: Москва
Сообщений: 2995
mayton,

за книжечки спасибо. Роберта Мартина (дядю Боба) читал. Книга "Идеальный программист" называется, если не ошибаюсь. На самом деле хорошо мозги на место ставит и на работу настраивает, я после прочтения посадил менеджера проектов с которым работаю и долгие часы объяснял как оно должно быть... правда и тут от половины рекомендаций пришлось отказаться из-за "феее" от менеджера проекта, который сказал что так задачи готовить не сможет, бизнес аналитиков нет и не будет, тестировщиков тоже пока не будет и т.д. :)

А вот остальные не читал, но если они того же уровня, то почти уверен, что тоже много чего прояснят.
10 мар 19, 01:57    [21828610]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
Програмёр
Member

Откуда: Москва
Сообщений: 2995
mayton

Какие ещё причины могут к такому приводить? Как я говорил в моём представлении только одна: мне нужно учиться лучше проектировать свои решения и желательно достаточно быстро, чтобы понимать пути решения уже на этапе оценки задачи, а не на этапе реализации, когда пришло понимание, что реализация предполагаемая на этапе оценки невозможна и первую половину задачи удалось реализовать как задумывалось, но вот с этого момента пора в другую сторону ползти :)

Причины - скорее всего недостаток уровня senyority. Ты наверное просто мало опыта накопил.

Давай так. Чтоб топик не был эмоциональным. Если у тебя нет NDA и запретов на публикацию.
Покажи фрагмент кода (без бизнес-секретов и имен) где у тебя были проблемы. И расскажи
что ты сделал чтобы их решить.

Кто-то в топике знаток в PHP полюбому что-то подскажет.

P.S. Это не rocket science.


По самому коду обычно проблем особых нет. Скорее есть проблемы с тем, что для решения задачи нужна уйма вспомогательных телодвижений, которые не входят в изначальную оценку. В борьбе с этим последних несколько задач полностью проектировал в "event-driven process chain", но и тут вот с этой последней задачей провтыкнул, потому что выполнил всё больше на уровне взаимодействия пользователь-система (хотя в этом отношении помогло сильно, ни один момент клиентского интерфейса не остался без внимания, так что пользу принесло), и не влез вглубь системы, а там оказалось, что заказ создал - не просто услугу продли, а сначала её при создании заказа создай, при оплате заказа продли... потом с самим хранением услуги.. раньше в корзине идентификатором покупаемой позиции выступал ID товара, а теперь с появлением услуг, имеющих срок действия, уникальности посредством ID товара не добиться, нужна продолжительность (то есть нужно частично переписывать существующее решение, а это не было должным образом учтено)... Но и это решение было не лучшим, потому что при продлении услуг и это не даёт уникальности (я могу продлить 2 одинаковых услуги с одинаковым периодом действия) и нужно ещё и id продлеваемой услуги включать в идентификатор, чтобы он стал уникальным. Обновление заказа (добавление или удаление позиций) с учётом нововведений оказалось намного сложнее из-за тех самых скрытых телодвижений.

В общем там пол часа, тут час, там час... и так ещё на лишних часов 10 и набежало, а с учётом возросшей вдвое сложности задачи и отладка из планируемых часов 2 превратилась ещё часов в 6 устранения мелких багов, недочётов, просто опечаток и прочего :)
10 мар 19, 02:17    [21828613]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
Anatoly Moskovsky
Member

Откуда: Odessa
Сообщений: 6340
Програмёр
из планируемых часов 2 превратилась ещё часов в 6

Не волнуйтесь. Такое у всех.
Просто если вы неопытный умножайте оценку на 4..8.
Если вы опытный то умножайте на 2.
Меньше 2 кратной ошибки не бывает ))
10 мар 19, 13:45    [21828691]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
mayton
Member

Откуда: loopback
Сообщений: 39224
Програмёр
По самому коду обычно проблем особых нет. Скорее есть проблемы с тем, что для решения задачи нужна уйма вспомогательных телодвижений, которые не входят в изначальную оценку. В борьбе с этим последних несколько задач полностью проектировал в "event-driven process chain", но и тут вот с этой последней задачей провтыкнул, потому что выполнил всё больше на уровне взаимодействия пользователь-система (хотя в этом отношении помогло сильно, ни один момент клиентского интерфейса не остался без внимания, так что пользу принесло), и не влез вглубь системы, а там оказалось, что заказ создал - не просто услугу продли, а сначала её при создании заказа создай, при оплате заказа продли... потом с самим хранением услуги.. раньше в корзине идентификатором покупаемой позиции выступал ID товара, а теперь с появлением услуг, имеющих срок действия, уникальности посредством ID товара не добиться, нужна продолжительность (то есть нужно частично переписывать существующее решение, а это не было должным образом учтено)... Но и это решение было не лучшим, потому что при продлении услуг и это не даёт уникальности (я могу продлить 2 одинаковых услуги с одинаковым периодом действия) и нужно ещё и id продлеваемой услуги включать в идентификатор, чтобы он стал уникальным. Обновление заказа (добавление или удаление позиций) с учётом нововведений оказалось намного сложнее из-за тех самых скрытых телодвижений.

В общем там пол часа, тут час, там час... и так ещё на лишних часов 10 и набежало, а с учётом возросшей вдвое сложности задачи и отладка из планируемых часов 2 превратилась ещё часов в 6 устранения мелких багов, недочётов, просто опечаток и прочего :)

У меня такое было на заре карьеры кодера.

Я тогда решил записывать в блокнот по минутам (грубо с точностью до 5 минут) чем я занимался.
Эта инфа была не для публикаций. А лично для себя. Такой тонкий тайм-менеджмент подзволил
понять на чём я зависал в течение дня. И вобщем это был даже не кодинг. А вопросы коммуникаций.
Прочитать в confluence. Понять что-то. Отписать письма. Задать уточняющие вопросы. Кодинг
тоже был но не так много.

Вобщем займитесь тонким анализом потраченого времени. Может вы копаетесь в мелочах
и вам действительно нужно быть под лидером чтобы не зарываться слишком глубоко.
Грубо говоря понять где надо остановится.
10 мар 19, 15:02    [21828704]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6065
Anatoly Moskovsky
Програмёр
из планируемых часов 2 превратилась ещё часов в 6

Не волнуйтесь. Такое у всех.
Просто если вы неопытный умножайте оценку на 4..8.
Если вы опытный то умножайте на 2.
Меньше 2 кратной ошибки не бывает ))

Хотел посоветовать на 3.

Но похоже, я слишком оптимист =)
10 мар 19, 23:44    [21828821]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
Програмёр
Member

Откуда: Москва
Сообщений: 2995
Siemargl
Anatoly Moskovsky
пропущено...

Не волнуйтесь. Такое у всех.
Просто если вы неопытный умножайте оценку на 4..8.
Если вы опытный то умножайте на 2.
Меньше 2 кратной ошибки не бывает ))

Хотел посоветовать на 3.

Но похоже, я слишком оптимист =)


эмм.. ну я то вообще на 1.5 умножаю, потому взял на заметку, что надо больше коэффициент брать. Но очень бы хотелось разобраться с причинами, нельзя же просто умножать и всё, особенно если часть задач вполне получается решить в срок (а получится, что на них стоимость выйдет втрое завышена). Я в душе перфекционист и потому не смогу жить спокойно, пока не добьюсь того, чтобы я называл срок разработки 10 часов, выполнял задачу ровно за 9 и часок спокойно пил кофе :)) Это вот идеальный вариант, которого хотелось бы добиться, и мой уровень счастья измеряется в близости к этому варианту :))
11 мар 19, 15:36    [21829307]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7438
Баян:

+

Памятка по грамотной постановки сроков
выполнения задач для программистов

«Сегодня» — завтра.
«Завтра» — напомнить завтра, что уже сегодня (см. «сегодня»).
«В течение недели» — в следующую среду.
«В течение недели, но до выходных, пожалуйста» — в понедельник.
«Через две недели» — месяц.*
«Месяц» — неопределенная, очень большая величина времени.
«Три месяца» — три неопределенные, очень большие величины времени.
«К осени» — когда выпадет снег. Снег выпадает каждый год, поэтому «к осени» является наиболее благоприятным сроком, пропустить который практически невозможно.

«Через год» — не используется, ибо есть «к осени».

* — Популярно заблуждение, что две недели — это 14 дней. Это не так. Две недели — это 14 дней + «в течение недели» (ибо вторая неделя еще не кончилась) + завтра («один день погоды не сделает»). В особых случаях отсчет «двух недель» начинается со следующего понедельника, так выигрывается еще несколько дней. Если повезет, то в результате выходит месяц срока и опоздание всего на один день («завтра»).
11 мар 19, 15:41    [21829316]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
m7m
Member

Откуда: Украина, Мариуполь
Сообщений: 1302
Програмёр
Но очень бы хотелось разобраться с причинами

Да какие тут могут быть причины, окромя как
оптимизм и "подводные камни"
11 мар 19, 16:25    [21829392]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
Изопропил
Member

Откуда:
Сообщений: 30985
Leonid Kudryavtsev,

почему только для программистов?
11 мар 19, 16:31    [21829414]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
Anatoly Moskovsky
Member

Откуда: Odessa
Сообщений: 6340
Програмёр
Но очень бы хотелось разобраться с причинами


Причина - в отладке.
Дело в том что мозг программиста, когда делает оценку, рассматривает только затраты на кодирование, потому что программисты - оптимисты с манией величия, и подсознательно считают что будут писать программу без багов.

Но баги всегда есть, а значит всегда нужна отладка.
Для достаточно сложных программ время отладки стремится к времени кодирования. Поэтому - коэффициент 2.
Понятно что в разных задачах реальное время может варьироваться, но среднее время будет соответствовать такому коэффициенту.
11 мар 19, 23:06    [21829842]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1144
Это не всегда плохо. Я один проект планировал сделать за месяц, ну, максимум 2-3 месяца. В итоге ушло 1,5 года с перерывами и сделал только 1/10 от того, что хотел. Если бы я изначально знал, что так будет, то вряд ли за это взялся бы. Причем каждую неделю ты думаешь, что уже почти всё сделал и осталось поправить пару вещей, но оказывается, что нужно ещё что-то переделать и так бесконечно.
12 мар 19, 00:03    [21829867]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
mayton
Member

Откуда: loopback
Сообщений: 39224
Да о чем тут топик? Никто не попадает в эстимейшен. Особенно в оптимистичную оценку.
А если вы просидели на проекте 5 лет и уже всё знаете и эстимируете с точностью до часа
- тогда возникает вопрос а что вы так долго сидите? Может быть зона комфорта? Или остановилось
развитие?

Вобщем сложный это вопрос.

P.S. Кто не рискует - тот не пьёт шампаньское игристое вино. Риск - дело благородное ...
12 мар 19, 00:26    [21829877]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 1317
Програмёр
По самому коду обычно проблем особых нет. Скорее есть проблемы с тем, что для решения задачи нужна уйма вспомогательных телодвижений, которые не входят в изначальную оценку.

Я в таких случаях тупо создаю в Jira таску на исследовать, или обсудить с коллегами, или провести технический Spike.
И по результатам уже расписываю конкретные и ясные задачи.
12 мар 19, 10:21    [21829984]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 1317
Програмёр
а там оказалось, что заказ создал - не просто услугу продли, а сначала её при создании заказа создай, при оплате заказа продли... потом с самим хранением услуги.. раньше в корзине идентификатором покупаемой позиции выступал ID товара, а теперь с появлением услуг, имеющих срок действия, уникальности посредством ID товара не добиться, нужна продолжительность (то есть нужно частично переписывать существующее решение, а это не было должным образом учтено)...

Хм, user story mapping?
Потратить часок-другой с коллегами, да расписать на доске стикерами все эти ветки: создание, оплата...
12 мар 19, 10:23    [21829986]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 1317
Кстати вспомнил про Backlog Grooming.

Вполне валидно на нём завить, что вот тут потратил уже два дня и задача на самом деле представляет из себя 2-3-10 и надо её разбить.
Часть сделается в этом спринте, часть поедет обратно в беклог.
12 мар 19, 10:28    [21829988]     Ответить | Цитировать Сообщить модератору
 Re: Ищу литературу (надоело проваливать сроки)  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 1317
Програмёр,

а кто и как вам задачи ставит вообще? Кто формализует требования?
12 мар 19, 10:30    [21829991]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Программирование Ответить