Pull to refresh
31
0
Константин Быченков @vzzvzz

Пользователь

Send message
Я, честно говоря, не совсем понял — в чем тут «value»?
У меня никогда не было таких этапов в контрактах — Дизайн, Верстка, Кодинг. Как то мои клиенты предпочитают функциональные этапы, типа «создание каталога товаров», «процесс оформления покупки» и т.д. И тут ничего не сократишь, потому что этапы приводят к решению бизнес-задачи заказчика, за что они и платят. А вот я, да, плачу за дизайн, верстку, код, в рамках каждого отдельного этапа.
Я стараюсь соблюдать баланс. Если в контракте все сдается одним этапом — есть риск что в конце все равно не понравится результат, хоть мы все итерации пройдем гладко. Просто у заказчика к концу срока работ могут деньги кончится, или гендир поменяется. Это тоже риски :-) Если этапов будет слишком много — нас могут замордовать на соблюдении всех бюрократических процедур по многу раз, получаться слишком большие накладные расходы. Так и живу.

PS: О да, внутри этапа agile работает суперски
Для управления задачами сейчас Teamlab и Mantis. Не самые мощные инструменты, но нас устраивает, и бесплатно.
Для контроля версий — subversion
Для билдов — teamcity
Для контроля качества — селениум.
Немного архаично, но опять же, бесплатно и нас устраивает по соотношению цена\качество.

Просто инструменты для работы. Процессами вообще не надо управлять, их надо создавать :-) А управляю я коммуникациями, содержанием, ожиданиями, изменениями…
Контроль нужен за всеми, потому что это делается не для того чтоб халтуру найти, а для того, чтоб команда шла к бизнес-цели.
От параллельных задач твитер не спасет — параллельные задачи нисходят на голову сверху. Не вижу «валуе» в вашем контроле старта в твитере.

Пользоватись мы яммером когда то, тоже микроблог. Пустое. Вики-блоги-форумы-таскбагтаймтрекинги — все что надо. И это давно все есть, в том числе бесплатно.
оххо, и куда только Консультант смотрит… наверное у них все хорошо
про «сутки не притрагиваться» — ооочень правильное замечание.
я бы добавил
пункт 6 «Предупредите делегата об ответственности. Явно укажите, что его ждет в случае успеха или неудачи.»

А то знаете как бывает, «поди ка, дружок, реши там проблемку» а потом оказывается что это было ну такое важное задание и кара будет ну такая страшная. А человек решил просто сделать свою прямую работу и не разобрался в приоритетах.

Кстати приоритет делегированной проблемы тоже надо обговорить.
Это — правило 7
В вашем случае — только через общее вышестоящее руководство. Причем, не надо говорить, что «он ничего не делает». :-) Обоснуйте иначе:
1. Вам надо сосредоточиться на _приоритетной_ работе
2. Но _эта_ работа тоже важна
3. Есть кандидат, который отлично справился бы. Нет ли у него на это времени?
Чем «Распределять дополнительную трудоемкость » отличается от «распределять работы»?

Все что я нашел на стр 13 — предлагается планировать с запасом изза неидеальности оценки. Неоригинально, но бесспорно.

Ок, сместимся от оценок в сторону планирования…

То что на трудоемкость, следующую из рисков, надо откладывать запас по времени, и этот запас можно распределять в календарном плане проекта как минимум 3мя разными способами — это тривиально.

Вы и в прошлой статье и в этой сосредоточились на оценке трудоемкости, следом за Макконелом. Макконел и правда хоть и говорит о software estimation ( что существенно шире ) в своей презентации приводит примеры time estimation.

Но риски влияют не только на сроки выполнения работ, а и на стоимость (которая складывается не только из потраченных человекочасов) и на функциональность продукта. И в крупном проекте вы могли бы это почувствовать, но из статьи как то не видно. Впрочем, если вы разработчик, то что вам стоимость?
1. Так и не нашел в книге «Scrum and XP from the Trenches» тот самый подход по аналогии с которым вы предлагаете распределять работы, вызванные рисками, по другим работам. Подскажите номер страницы, чтоб я мог понять.

2. У вас статья названа «Управление рисками ПРИ ОЦЕНКЕ трудоемкости… » а по тексту вы к диаграммам ганта обращаетесь, которые обычно рисуют уже ПОСЛЕ оценки. Нестыковочка…

3. В начале статьи вы приводите примеры того, что такое риск а что не риск. А потом, в списке понятий вы не написали «что такое риск». Если есть трудности — предлагаю определение из книги Hall, Elaine. Managing Risk. Reading: Addison Wesley, 1997. «Risk is a consequence of the uncertainty in our work, not a reflection of our own ability.”
У меня есть опыт.
1) Выявляем всех заинтересованных в проекте. Встречаемся с ними. Собираем что можем от них получить
2) Пишем ТЗ где сами все формулируем.
3) Согласовываем — это самое интересное
4) Большой начальник утверждает ТЗ и ответственного со стороны заказчика

это такой чистоплюйский список шагов по сбору требований у госзаказчика

С учетом того, что вы делали программу, а не продукт ( так следует из вашей статьи ) — это настоящая success story. Когда не надо жертвовать никакими требованиями пользователя — работаешьь с заказчиком душа в душу
Как оценивали стоимость проекта? Просто торговались исходя из цены на рынке или как то измеряли и обосновывали?

Ваш рассказ — хороший пример того, как помогает проекту грамотный системный и бизнес-анализ.
Конечно «неподготовленный», потому что это точно. Далее там идет:

Use of guessing and intuition to create estimates is correlated with cost and schedule overruns (at the 0.05 level of
significance)
v Use of simple arithmetic formulas is negatively correlated with overruns (at the 0.01 level of significance)

и т.д… Тоесть, конкретные советы по подготовке.
Цитирую статью и ваш последний комментарий

3 — ранние оценки из-за отсутствия необходимой информации о предмете
6 — чтобы не производить оценок в «зоне невероятности»
10 — предостережении от использования поспешных, необоснованных оценок

Ну уж настолько тонкая граннь между этими пунктами что можно, можно объединить их в один. Вебинар от этого только выйграл бы.

9 — дааа, спасибо что даром. реклама бесплатных продуктов все равно реклама. в данном случае — реклама самого МакКоннела. И не заставляет, да, а что, мог бы и заставить?

2 — все решения «продавливают» те, кто уверенно говорит и убеждает. лучше бы упомянули цитату Брукса из презентации «It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers.» Интровертные неубедительные юные разработчики не вызывают во мне сочувствия. Они просто некомпетентны в проведении оценок.

5 — просто красивая фраза, которая не содержит в себе никакой специфики оценивания трудоемкости. Суть та же что в п.2 — некомпетентность.

Риски кстати в презентации макКонела упомянуты грехом № 9, посмотрел по вашей же ссылке.
А пункт 10 в оригинале «Providing Off-The-Cuff Estimates» Это никак не «поспешная оценка», ай-яй.

Чтож вы как неаккуратны в переводе?
Резюме: презентация МакКонела не фонтан, но перевод просто мрак. Читайте оригинал!

Грехи 3,6 и 10 суть одно и то же.
Грех 9 — плохо скрытая реклама сайта и продуктов автора.
Грех 2 — тема не раскрыта. Там автор что имел ввиду? Что программисты не умеют делать оценки? Что нет менеджера проекта, который должен сидеть на переговорах вместо них?
Грех 5 — просто пустой звук. Если вам не хватает «искусства» в вашей работе — не беритесь.

Автор так же ни слова не сказал о рисках. Вот уж что точно несет смерть оценкам.
Другой грех — делать оценки только раз на проект.

Коллеги, эти тезисы вас не спасут от ошибок в оценках, не очень полагайтесь на советы МакКоннела.
когда напишут браузер с HAL, который встанет на почти любое железо, тогда и будем десктопный софт хоронить
Прочитал, рецепты из книжки не подходят.
все 100 на русском? :-) а картинки перевести забыли, без картинок неподготовленным читателям тяжко разобраться

Фокус-фактор — во многих случаях весьма приблизительный инструмент. Есть много факторов посерьезнее болезней и отгулов, которые не позволят оценить эффективность комманды с помощью этого инструмента. Наверное, есть такие проекты, где ситуация остаается предсказуемой достаточно долгое время, чтобы можно было стабилизировать фокус-фактор. Но точно есть и другие проекты.
Я вам больше скажу, Таичи Оно придумал канбан для тойоты, когда посетил американский супермаркет.
Еще в канбан можно отдельно ввести ограничение на количество высокоприоритетных задач, такой «блэклог высокоприоритетных задач».Тут конечно могут быть трудности с такими product owner, которые считают все свои задачи приоритетными. Но штука полезная, препятствует бардаку в приоритетах, который может взорвать канбан

Information

Rating
Does not participate
Location
Россия
Registered
Activity