Насчет категоричности — очень устаешь писать после каждой фразы ИМХО да и текст засоряет, по-моему это очевидно, что все, что здесь каждым написано — его личное мнение и серебряной пули не существует.
Насчет термина «начинающий». Статья несколько раз как бы намекает, что речь идет и о начинающем специалисте тоже, поскольку опытный специалист уже знает примерно цену своей работе и не боится просить за нее денег. В противном случае он, увы, начинающий, насмотря на годы за плечами. С умением давать оценку и брать на себя ответственность это как ни странно хорошо коррелирует.
Я никого лично обидеть не собиралась, но мне до сих пор попадались среди хороших только такие программисты, которые живо интересуются всем новым и редко готовы делать точно такой же проект второй раз. Хоть что-то да должно меняться, а значит, опыт прошлых оценок не помогает. Насмотрелась я в одной_большой_конторе на людей, которым «очень нравится монотонная и неизменная работа» — больше не хочу :-)
Иногда заказчику об этом знать и не обязательно :-) Я рекомендовала чисто для себя попробовать этот подход. Опробовано, что называется на себе. Когда пытаешься записать критерии приемки, сразу возникает куча вопросов заказчику и появляется ясность по многим пунктам. А заказчику потом можно просто готовые критерии предъявить и согласовать. Пусть подпишется, что это все будет именно так и никак иначе.
К сожалению, проекты, где присутствует полная детерминированность и отсутствует всякий риск безумно скучны :–) Поэтому я на таких не работаю. Если же есть хоть малейшая неопределенность или присутствует элемент исследования (для новичка это будет практически в 100% случаев) оценку дать крайне сложно. Возможно, где-то есть уникумы, которые умеют оценить с точность до часа абсолютно любую работу, но я таких не встречала. Как не встречала и заказчиков, которые абсолютно точно уверены в своих требованиях.
Это точно. Я вам больше скажу — дальше 2 недель никто оценивать не умеет :-) Это всегда пальцем в небо и умножено на «пи». Поэтому повторюсь — попробуйте сформулировать это в виде историй — поможет оценить вам и понять приоритеты заказчику. Когда вы сделали 4 приоритетных фичи и не успели одну низкоприоритетную, вы все равно нанесли заказчику непоправимую пользу и он будет счастлив.
Новички склонны закапываться в детали и браться за задачи не в порядке важности для заказчика, а в порядке легкости исполнения. Это причина многих факапов.
Основная ценность agile не в итерациях и не в митингах, как многие думают. А в том, что требования формулируются в виде историй с критериями приемки. Попробуйте — и вы увидите реальную пользу, когда заставите заказчика (с вашей помощью) их сформулировать. В этом вопросе размер проекта неважен.
Я, конечно, не имела в виду проекты с fixed price. Однако, есть и такой опыт. Вот прямо сейчас у нас идет проект, где бюджет ограничен. Мы идем по agile и вместе с заказчиком каждый раз заново согласуем приоритеты. Все понимают, что за N денег можно сделать работу не более, чем на M часов. Поэтому когда заказчик хочет что-то добавить, мы всегда говорим: «Мы согласны, решайте, что мы выбросим из уже запланированного». Это работает.
Вот здесь я бы поспорила. Многолетний опыт в разных конторах и фрилансе привел к agile. Если «ТЗ» — это общее понимание сути проекта с точки зрения бизнеса и задач, которые Вам нужно выполнить в ближайшие 2 недели, то да, соглашусь. Пользовательские истории с четкими критериями приемки весьма помогают.
Уже сильно не первый раз попадаю в ситуацию, когда заказчик изначально собирается писать ТЗ либо приносит готовое, а после 1-2 двухнедельных итераций оно идет в топку и его фантазия выходит из берегов. Фиксируем скоуп на 2 недели и после этого он волен менять все что хочет. Заказчики счастливы, мы творим.
Если не вдаваться в глубокую философскую дискуссию о добре и зле, которая развернулась выше, а вернуться к конкретной теме, поднятой автором, могу рассказать, как мы начали недавно решать озвученную проблему эффективности и простоя разработчиков.
Доска содержит несколько ячеек, которые представляют собой упорядоченные в потоки состояния. Часть состояний относится к этапу предварительной проработки проекта (продажи, переговоры и т.д.), часть — к текущей разработке, часть — к завершающему этапу (передача кода, обновление портфолио).
Прошу прощения за картинку, пишу сидя на хакатоне. Из картинки выше видно, что проекты приходят двумя путями — от внешних заказчиков и изнутри, свою идею может подать любой сотрудник компании. На этапе разработки и завершения проекты проходят в одном и том же потоке, независимо от источника. Ячейки с состояниями я не рисовала, только потоки.
Каждая ячейка маркирована числом, которое обозначает максимальное число проектов в данной ячейке. Эти ограничения задают пропускную способность потока состояний и определяются наличием ресурсов. Например, на этапе переговоров с потенциальными клиентами число может определяться количеством менеджеров по продажам в компании — у нас 2, на этапе разработки проектов не может быть больше, чем есть в компании полностью укомплектованных команд разработки — у нас сейчас это 5.
Как все это работает? Проекты перемещаются из ячейки в ячейку в соответствии с допустимой последовательностью состояний и ограничениями. Для того, чтобы переместить проект в следующую ячейку, необходимо удовлетворить два условия: выполнить все пункты из чеклиста, навешенного на каждую ячейку, и освободить место в следующей по порядку ячейке, чтобы не нарушать ограничений.
Такая доска позволяет наглядно видеть все узкие места и не пытаться объять необъятное. Кроме того, в процессе навешивания стикеров на доску и составления чеклистов нас посетило несколько полезных инсайтов.
На каждом проекте у нас тоже будут скоро такие доски. И часть задач, которые будут находиться в ячейках, могут быть сделаны любым освободившимся разработчиком, если он имеет нужные скиллы и желание. Т.о. можно будет на заботиться о том, чем бы таким полезным занять человека — фронт работ будет висеть у всех на виду и можно будет легко найти себе занятие по душе и при этом помочь другим командам или компании в-целом, поскольку часть проектов будут внутренними общественно-полезными.
Не могу сказать, что мы уже на 100% набили все шишки и придумали наилучший способ применения. Все еще впереди. Думаю, что со временем напишу статью по итогам использования.
Насчет термина «начинающий». Статья несколько раз как бы намекает, что речь идет и о начинающем специалисте тоже, поскольку опытный специалист уже знает примерно цену своей работе и не боится просить за нее денег. В противном случае он, увы, начинающий, насмотря на годы за плечами. С умением давать оценку и брать на себя ответственность это как ни странно хорошо коррелирует.
Я никого лично обидеть не собиралась, но мне до сих пор попадались среди хороших только такие программисты, которые живо интересуются всем новым и редко готовы делать точно такой же проект второй раз. Хоть что-то да должно меняться, а значит, опыт прошлых оценок не помогает. Насмотрелась я в одной_большой_конторе на людей, которым «очень нравится монотонная и неизменная работа» — больше не хочу :-)
Новички склонны закапываться в детали и браться за задачи не в порядке важности для заказчика, а в порядке легкости исполнения. Это причина многих факапов.
Я, конечно, не имела в виду проекты с fixed price. Однако, есть и такой опыт. Вот прямо сейчас у нас идет проект, где бюджет ограничен. Мы идем по agile и вместе с заказчиком каждый раз заново согласуем приоритеты. Все понимают, что за N денег можно сделать работу не более, чем на M часов. Поэтому когда заказчик хочет что-то добавить, мы всегда говорим: «Мы согласны, решайте, что мы выбросим из уже запланированного». Это работает.
Вот здесь я бы поспорила. Многолетний опыт в разных конторах и фрилансе привел к agile. Если «ТЗ» — это общее понимание сути проекта с точки зрения бизнеса и задач, которые Вам нужно выполнить в ближайшие 2 недели, то да, соглашусь. Пользовательские истории с четкими критериями приемки весьма помогают.
Уже сильно не первый раз попадаю в ситуацию, когда заказчик изначально собирается писать ТЗ либо приносит готовое, а после 1-2 двухнедельных итераций оно идет в топку и его фантазия выходит из берегов. Фиксируем скоуп на 2 недели и после этого он волен менять все что хочет. Заказчики счастливы, мы творим.
Разумеется, без санкции команды ничего не внедряется. Но у нас вроде бы с разумными доводами пока все соглашаются.
Канбан
Мы решили использовать<a href=«ru.wikipedia.org/wiki/%D0%9A%D0%B0%D0%BD%D0%B1%D0%B0%D0%BD»канбан-доски уровня компании и уровня проекта. Расскажу про первую.
Доска содержит несколько ячеек, которые представляют собой упорядоченные в потоки состояния. Часть состояний относится к этапу предварительной проработки проекта (продажи, переговоры и т.д.), часть — к текущей разработке, часть — к завершающему этапу (передача кода, обновление портфолио).
Прошу прощения за картинку, пишу сидя на хакатоне. Из картинки выше видно, что проекты приходят двумя путями — от внешних заказчиков и изнутри, свою идею может подать любой сотрудник компании. На этапе разработки и завершения проекты проходят в одном и том же потоке, независимо от источника. Ячейки с состояниями я не рисовала, только потоки.
Каждая ячейка маркирована числом, которое обозначает максимальное число проектов в данной ячейке. Эти ограничения задают пропускную способность потока состояний и определяются наличием ресурсов. Например, на этапе переговоров с потенциальными клиентами число может определяться количеством менеджеров по продажам в компании — у нас 2, на этапе разработки проектов не может быть больше, чем есть в компании полностью укомплектованных команд разработки — у нас сейчас это 5.
Как все это работает? Проекты перемещаются из ячейки в ячейку в соответствии с допустимой последовательностью состояний и ограничениями. Для того, чтобы переместить проект в следующую ячейку, необходимо удовлетворить два условия: выполнить все пункты из чеклиста, навешенного на каждую ячейку, и освободить место в следующей по порядку ячейке, чтобы не нарушать ограничений.
Такая доска позволяет наглядно видеть все узкие места и не пытаться объять необъятное. Кроме того, в процессе навешивания стикеров на доску и составления чеклистов нас посетило несколько полезных инсайтов.
На каждом проекте у нас тоже будут скоро такие доски. И часть задач, которые будут находиться в ячейках, могут быть сделаны любым освободившимся разработчиком, если он имеет нужные скиллы и желание. Т.о. можно будет на заботиться о том, чем бы таким полезным занять человека — фронт работ будет висеть у всех на виду и можно будет легко найти себе занятие по душе и при этом помочь другим командам или компании в-целом, поскольку часть проектов будут внутренними общественно-полезными.
Не могу сказать, что мы уже на 100% набили все шишки и придумали наилучший способ применения. Все еще впереди. Думаю, что со временем напишу статью по итогам использования.