Учимся оценивать проекты

Здесь мы обсуждаем вопросы совместной работы в команде и с командами (Scrum, Kanban, TOC и прочий Lean)
Аватара пользователя
virusde
Сообщения: 13
Зарегистрирован: Ср июл 01, 2015 11:21 pm

Учимся оценивать проекты

Сообщение virusde »

Друзья,

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

Итак, поехали.
Безотносительно используемых в компании подходов к планированию имеем следующий диалог:

ПМ: Насть, ты когда закончишь обновление (слияние с новой стандартной 1С конфигурацией)?
Н: Блин, теперь уже не знаю, думала, что за две недели управлюсь, теперь уже сложно оценить. Чем глубже копаю, тем больше обнаруживаю того, что нужно что-то рефакторить или при обновлении что-то перестаёт работать...
ПМ: Нууу, давай уже как-то определим срок завершения, потому как указано 2 недели, выполнено на 56%, выходит неделя осталась?
Н: Не знаю, может и неделя, но если опять во что-то упрусь или что-то новое прилетит, может и три...

Хочу обратить внимание знатоков на следующие ограничения:
  • Проект - это не классический проект, а просто большая пользовательская история, которую наверное стоит декомпозировать только на таски, но не стоит делить на несколько отдельных историй.
  • Настя – ответственный, вполне квалифицированный работник, успешно использующий практики GTD. Это я к тому, что не нужно пенять на прокрастинацию.
  • У Насти, как и любого разработчика, есть несколько параллельных проектов, в которых также есть задачи.
  • Насте хорошо удаётся планировать небольшие по объему задачи, особенно те, в которых владение кодом близко к 100%
Мои предложения Насте:
  1. Прочесть и попробовать на себе EBDC (http://mnogosdelal.ru/slidecasts/project-estimation/)
  2. Прослушать вебинар про оценку сроков, проводимый http://it-boost.com/, пароль, увы, скажу только Насте (https://vimeo.com/83733627)
  3. Ежедневно (еже-[выбрать своё]) пересматривать свою оценку, отсекая все необязательные задачи в рамках конкретной пользовательской истории
  4. Чаще практиковать "обновления" (набить руку, так сказать) и составлять чек-листы обновления (с 1С видимо так и никак иначе).
А чтобы вы порекомендовали делать Насте, чтобы улучшить качество и прогнозы планирования?

Аватара пользователя
Максим Дорофеев
Site Admin
Сообщения: 1980
Зарегистрирован: Вс июн 28, 2015 1:56 pm
Контактная информация:

Re: Учимся оценивать проекты

Сообщение Максим Дорофеев »

Правильные предложения. Пока больше бы ничего не рекомендовал, а то перегрузить так можно.

Правильно я понимаю, что обновление 1С - это типовая задача и когда-то в прошлом уже приходилось это делать?
Это к вопросу:
virusde писал(а):Чаще практиковать "обновления" (набить руку, так сказать) и составлять чек-листы обновления (с 1С видимо так и никак иначе).
С предыдущих раз ничего такого не осталось?
И неужели 1С не может просто так взять и легко обновиться?
virusde писал(а):Проект - это не классический проект, а просто большая пользовательская история, которую наверное стоит декомпозировать только на таски, но не стоит делить на несколько отдельных историй.
Это еще почему? Мне кажется, что как раз стоит.

Stac
Сообщения: 81
Зарегистрирован: Чт авг 06, 2015 9:11 pm

Re: Учимся оценивать проекты

Сообщение Stac »

Оценка (с позиции Насти) это стресс. Поэтому пункты 1-4, хотя и полезны сами по себе, но могут не помочь. Потому что стресс никак не снижают.

Давать оценку, особенно, когда ПМ давит, как в примере, тяжело: скажешь мало - не успеешь, будет чувство вины, скажешь много - ПМ будет бурчать.

Настя будет спокойнее давать оценки, если будет знать, что она ни на что серьезно не влияет - просто для ориентира ПМ.

Может избавить Настю от лишних забот? Если ПМ сам по 56% вычислил новую оценку срока, зачем он ходил и Настю расстраивал?

Я, в основном, разработчик, поэтому мой взгляд на вопрос предвзят и однобок :)

Аватара пользователя
virusde
Сообщения: 13
Зарегистрирован: Ср июл 01, 2015 11:21 pm

Re: Учимся оценивать проекты

Сообщение virusde »

cartmendum писал(а):Правильно я понимаю, что обновление 1С - это типовая задача и когда-то в прошлом уже приходилось это делать?
Это к вопросу:
Чаще практиковать "обновления" (набить руку, так сказать) и составлять чек-листы обновления (с 1С видимо так и никак иначе).
Да, верно, но типовой лишь в ней алгоритм проведения обновления, представь себе две команды, обе делают два бранча от транка и через 3-4 месяца пытаются мёржиться. Вот только одна команда (1С в данном случае) постоянно мержит в транк, а вторая только комитит в свой бранч, и вот в час х (когда выходит новая версия конфигурации) вторая команда забирает себе из транка обновления и пытается смёржить их к себе в бранч.
И как ты понимаешь оценить сколько времени уйдёт на мёрдж, практически нереально, потому что ты заранее не можешь знать а чего там наменяли то (ведь и общие библиотеки меняют, переписывают), так что ещё и тестировать нужно, а на 1С платформе с автотестами, да и юнит тестами всё грустно, но я не эксперт, увы тут. :)
cartmendum писал(а):С предыдущих раз ничего такого не осталось?
И неужели 1С не может просто так взять и легко обновиться?
Осталось конечно, но читай выше почему это слабо помогает с оценкой сроков.
cartmendum писал(а):
virusde писал(а):Проект - это не классический проект, а просто большая пользовательская история, которую наверное стоит декомпозировать только на таски, но не стоит делить на несколько отдельных историй.
Это еще почему? Мне кажется, что как раз стоит.
Ну может, только пожалуй, чтобы разработчик чувствовал себя комфортнее, чтобы задачи на доске выполнялись и вправо уезжали, но моё мнение – обновление это неделимая US, как мёрдж, можно подробить на таски, но не более, но это имхо.

Аватара пользователя
virusde
Сообщения: 13
Зарегистрирован: Ср июл 01, 2015 11:21 pm

Re: Учимся оценивать проекты

Сообщение virusde »

Stac писал(а):Оценка (с позиции Насти) это стресс. Поэтому пункты 1-4, хотя и полезны сами по себе, но могут не помочь. Потому что стресс никак не снижают.
Давать оценку, особенно, когда ПМ давит, как в примере, тяжело: скажешь мало - не успеешь, будет чувство вины, скажешь много - ПМ будет бурчать.
Да ну, бросьте, для меня оценивание это как challenge и чем больше (длиннее и сложнее) проект, тем выше адреналин, стараюсь потом свои оценки ретроспективно проверять.
Бывает конечно, что пугает неизвестность/неопределённость, а если часто промахиваешься, то растёт и уровень стресса, понижается самооценка, для этого как раз и рекомендуется использоваться EBDC + эмоциональный скрам для увеличения вероятности попадания в сроки.
Ещё нужно принять как аксиому - ПМ-ам всегда нужны сроки, потому что у ПМ-ов есть ПМ-ы, которым нужны сроки, и т.д., иначе будет как в известном видео http://www.youtube.com/watch?v=4u5N00ApR_k :)
Stac писал(а): Настя будет спокойнее давать оценки, если будет знать, что она ни на что серьезно не влияет - просто для ориентира ПМ.
Может избавить Настю от лишних забот? Если ПМ сам по 56% вычислил новую оценку срока, зачем он ходил и Настю расстраивал?
Я, в основном, разработчик, поэтому мой взгляд на вопрос предвзят и однобок :)
Настя будет спокойнее давать оценки, на мой взгляд, если а) будет чаще давать оценки, набьёт шишек и наберётся нужного опыта б) будет работать на опережение, информировать о текущих (и новых) сроках до того момента, когда ПМ её об этом спросит.

Аватара пользователя
virusde
Сообщения: 13
Зарегистрирован: Ср июл 01, 2015 11:21 pm

Re: Учимся оценивать проекты

Сообщение virusde »

А одинэсники матёрые тут есть? :) Что можете сказать по теме обновлений/слияний со стандартными конфигурациями и оценки сроков таких работ?
Нужно помочь Насте.

Аватара пользователя
Максим Дорофеев
Site Admin
Сообщения: 1980
Зарегистрирован: Вс июн 28, 2015 1:56 pm
Контактная информация:

Re: Учимся оценивать проекты

Сообщение Максим Дорофеев »

Stac писал(а):Давать оценку, особенно, когда ПМ давит, как в примере, тяжело: скажешь мало - не успеешь, будет чувство вины, скажешь много - ПМ будет бурчать.

Настя будет спокойнее давать оценки, если будет знать, что она ни на что серьезно не влияет - просто для ориентира ПМ.
Кстати, искренне согласен!

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

То есть, человек сказал оценку (что по своей природе содержит определенную долю ошибки), а руководство воспринимает это за клятву.

Аватара пользователя
Максим Дорофеев
Site Admin
Сообщения: 1980
Зарегистрирован: Вс июн 28, 2015 1:56 pm
Контактная информация:

Re: Учимся оценивать проекты

Сообщение Максим Дорофеев »

virusde писал(а):И как ты понимаешь оценить сколько времени уйдёт на мёрдж, практически нереально, потому что ты заранее не можешь знать а чего там наменяли то (ведь и общие библиотеки меняют, переписывают), так что ещё и тестировать нужно...
Возвращаясь к исходному посту - как помочь Насте совершить нереальное? :)

, а на 1С платформе с автотестами, да и юнит тестами всё грустно, но я не эксперт, увы тут. :)
cartmendum писал(а):С предыдущих раз ничего такого не осталось?
И неужели 1С не может просто так взять и легко обновиться?
Осталось конечно, но читай выше почему это слабо помогает с оценкой сроков.
virusde писал(а):
cartmendum писал(а):
virusde писал(а):Проект - это не классический проект, а просто большая пользовательская история, которую наверное стоит декомпозировать только на таски, но не стоит делить на несколько отдельных историй.
Это еще почему? Мне кажется, что как раз стоит.
Ну может, только пожалуй, чтобы разработчик чувствовал себя комфортнее, чтобы задачи на доске выполнялись и вправо уезжали, но моё мнение – обновление это неделимая US, как мёрдж, можно подробить на таски, но не более, но это имхо.
Вот мне кажется, что в этом имхе и есть половина ответа ;) Вот к примеру, если мы разработали систему один раз и тут внезапно нам нужно еще раз написать такую же (путь на другом, но очень похожем языке). Как бы мы смогли использовать знание из первого проекта для более точной оценки второго?

Stac
Сообщения: 81
Зарегистрирован: Чт авг 06, 2015 9:11 pm

Re: Учимся оценивать проекты

Сообщение Stac »

virusde писал(а):
Stac писал(а):Оценка (с позиции Насти) это стресс.
Да ну, бросьте, для меня оценивание это как challenge и чем больше (длиннее и сложнее) проект, тем выше адреналин, стараюсь потом свои оценки ретроспективно проверять.
Секундочку, это вы Настя? :) Челлендж это здорово, но не вариант - не масштабируется. И самая распространенная причина смерти это косвенно подтверждает.
virusde писал(а):Ещё нужно принять как аксиому - ПМ-ам всегда нужны сроки, потому что у ПМ-ов есть ПМ-ы, которым нужны сроки, и т.д., иначе будет как в известном видео http://www.youtube.com/watch?v=4u5N00ApR_k :)
Забавный ролик :)

А можно ли уточнить аксиому до "ТОЛЬКО ПМ-ам всегда нужны сроки, потому что у ПМ-ов есть ПМ-ы, которым нужны сроки, и т.д."?

Потому что я не вижу тут, зачем бы оценка была нужна Насте. Тем более регулярная (частая) и опережающая, как вы предлагаете.

Почему ПМ сам не дает своему руководству оценки, тем более, что он подкован в разных специальных методах для этого?

Возможно, у ПМ нет каких-то четких критериев для оценки. Но... их нет и у исполнителя.

Интересно, устроила бы ПМ автоматическая оценка (рассчитанная программой или взятая с потолка), если бы она удовлетворяла требованиям - была частой и опережающей?

Лично я собираюсь проверить это на своих проектах в ближайшее время.

Но интереснее, что вы скажете по этому поводу.

Аватара пользователя
virusde
Сообщения: 13
Зарегистрирован: Ср июл 01, 2015 11:21 pm

Re: Учимся оценивать проекты

Сообщение virusde »

cartmendum писал(а):
virusde писал(а):И как ты понимаешь оценить сколько времени уйдёт на мёрдж, практически нереально, потому что ты заранее не можешь знать а чего там наменяли то (ведь и общие библиотеки меняют, переписывают), так что ещё и тестировать нужно...
Возвращаясь к исходному посту - как помочь Насте совершить нереальное? :)
Скорее так, помочь Насте совершать нереальное.
cartmendum писал(а):
virusde писал(а):Ну может, только пожалуй, чтобы разработчик чувствовал себя комфортнее, чтобы задачи на доске выполнялись и вправо уезжали, но моё мнение – обновление это неделимая US, как мёрдж, можно подробить на таски, но не более, но это имхо.
Вот мне кажется, что в этом имхе и есть половина ответа ;) Вот к примеру, если мы разработали систему один раз и тут внезапно нам нужно еще раз написать такую же (пуcть на другом, но очень похожем языке). Как бы мы смогли использовать знание из первого проекта для более точной оценки второго?
Это вы мне скажите, вы же эксперт! © :)
Скорее всего мы бы знали, что нам точно не нужно делать, а это сводится к составлению чек-листа, каждый пункт из которого худо-бедно можно оценить, но твой пример не содержит столько "неизвестности", какую порой несут нам обновления 1С.

Ответить