Комментарии 263
Такая методика называется «Мы делаем всё возможное, чтобы максимально усложнить проекты».
Поправлю: усложнить работу программистам(((
Позвольте не согласиться.
На все что тут написано программисту придется потратить не более часа, зато у него появится некая ответственность за сроки (он сам их назвал и подписал), а менеджер сможет нормально контролить работу и реагировать на отставания от графика (сможет попытаться помочь программисту).
Вообще разработку надо разбивать на итерации. Каждая итерация должна начинаться с шагов представленных в топике и заканчиваться сборкой.
Это не усложняет работу, а нацеливает на результат.
На все что тут написано программисту придется потратить не более часа, зато у него появится некая ответственность за сроки (он сам их назвал и подписал), а менеджер сможет нормально контролить работу и реагировать на отставания от графика (сможет попытаться помочь программисту).
Вообще разработку надо разбивать на итерации. Каждая итерация должна начинаться с шагов представленных в топике и заканчиваться сборкой.
Это не усложняет работу, а нацеливает на результат.
НЛО прилетело и опубликовало эту надпись здесь
программист очень часто хочет сделать «лучший» универсальный вариант. а «лучшее» как известно — враг хорошего. в результате срыв сроков.
если менеджер толковый, то он поможет программисту принять ПРАВИЛЬНОЕ решение об отказе от каких то наворотов, с целью соблюдения сроков. я не говорю о ситуации «сделай, как угодно — лишь бы в срок», это уже крайность.
если менеджер толковый, то он поможет программисту принять ПРАВИЛЬНОЕ решение об отказе от каких то наворотов, с целью соблюдения сроков. я не говорю о ситуации «сделай, как угодно — лишь бы в срок», это уже крайность.
Ну если менеджер может помочь программисту только криками «ооооооо, нам всем песдетц» то гнать такого менеджера в шею!
А по поводу данных пунктов, менеджер может проконтролировать где были допущены просчеты, что бы не наступить на теже грабли в последующих задачах.
Оценка времени выполнения самим девелопером очень помогает в будущем знать на какие задачи придется потратить времени больше, на какие меньше, выполнить задачи в срок и не подвести своих колег, так как они могут ожидать окончания вашей задачи.
А по поводу данных пунктов, менеджер может проконтролировать где были допущены просчеты, что бы не наступить на теже грабли в последующих задачах.
Оценка времени выполнения самим девелопером очень помогает в будущем знать на какие задачи придется потратить времени больше, на какие меньше, выполнить задачи в срок и не подвести своих колег, так как они могут ожидать окончания вашей задачи.
Как-то раз шёл снег, и я, переборов своё болезненное состояние, притащился на работу, чтобы собрать нашу шаткую систему воедино – в демонстрационную версию для пользователей. Шерон зашла и обнаружила меня за консолью. Она исчезла и вернулась через несколько минут с миской супа. Когда она влила в меня этот суп, я почувствовал прилив бодрости и спросил, как она умудряется находить время на такие вещи, ведь ей ещё нужно решать столько вопросов, связанных с руководством проектом. Она улыбнулась своей неповторимой улыбкой и сказала: «Том, это и есть руководство».
Демарко, Листер «Человеский фактор: успешные проекты и команды»
Демарко, Листер «Человеский фактор: успешные проекты и команды»
Нормальный процесс, в серьёзных конторах примерно так и делается. Основная идея, как я думаю, не в том, чтобы затруднить кому-то работу, а чтобы поставить планирование и аналитику на реальные рельсы (оценки трудозатрат на задачи, статистику сбора билдов и т.п).
Такой подход применяется не только в разработке, есть множество вариаций для специфичных отраслей.
Считается одной из самых эффективных моделей проджект менеджмента.
Считается одной из самых эффективных моделей проджект менеджмента.
Вы не открыли Америку и не изобрели велосипед :) Сам по такой схеме работаю — такой вот у нас workflow.
Все верно. Единственное, в чем бы я поправил тех.дира, так это в пп.2,3
Ответственным за сроки должен быть ПМ, но сроки и реперные точки должны быть согласованы с девелопером (командой).
Ответственным за сроки должен быть ПМ, но сроки и реперные точки должны быть согласованы с девелопером (командой).
Согласен с вами, самого на последней работе всегда напрягали постоянные торги «а за сколько сделаешь?», как на базаре. За сколько надо — за столько и сделаю, если зараннее видно что срок недостаточен — это уже можно обсудить.
это нормальный вопрос. правда ответ напрашивается $99.90 — рождественская скидка. Но суть не меняется, разработчик должен представлять объем поставленной задачи. Да, потом указанное число может корректироваться в очень широких пределах, это жизнь :)
Если разработчик не в состоянии предоставить более-менее реальные сроки, то грош ему цена. Надо четко понимать, что тимлида/ПМа теми же вопросами «донимают» заказчики/техдир. И он ровно так же не может не ответить.
И в чем-же тогда заключается задача тимлида/ПМа? Бегать мальчиком на побегушках между заказчиком и разработчиками? На кой черт тогда он вообще сдался? Если руководитель не понимает суть процесса которым он руководит — то какова ему цена? Тоесть назовет ему разработчик срок в неделю — он будет радостно скакать по офису с воплями «укладываемся», назовет два месяца — скажет «это слишком долго, незнаю почему, но долго», так?
Незнаю, может я морально устарел, но руководить группой разработчиков должен тоже разработчик, с огромным стажем, способный определить сроки разработки засчет того что он уже имел опыт разработки таких-же или аналогичных вещей, и имея четкое представление о том какой квалификации у него в подчинении находится персонал — уже расчитывать конкретные сроки. А левый дядя с бубном бегающий между разработчиками с вопросами а-ля «Вася, а за сколько ты сделаешь то?», «Петя, а за сколько это сделает Вася?» — это профанация.
Незнаю, может я морально устарел, но руководить группой разработчиков должен тоже разработчик, с огромным стажем, способный определить сроки разработки засчет того что он уже имел опыт разработки таких-же или аналогичных вещей, и имея четкое представление о том какой квалификации у него в подчинении находится персонал — уже расчитывать конкретные сроки. А левый дядя с бубном бегающий между разработчиками с вопросами а-ля «Вася, а за сколько ты сделаешь то?», «Петя, а за сколько это сделает Вася?» — это профанация.
Руководитель должен быть разработчиков — согласен.
Руководитель нужен, чтобы с каждым разработчиком переговорить, утвердить сроки, отследить выполнение задач. Директор этого не может сделать, так как у него зачастую нет знаний «разработчика», но есть деньги, организационные и маркетинговые навыки, а также умение выбирать грамотного руководителя проекта. В идеале так должно быть!
Руководитель нужен, чтобы с каждым разработчиком переговорить, утвердить сроки, отследить выполнение задач. Директор этого не может сделать, так как у него зачастую нет знаний «разработчика», но есть деньги, организационные и маркетинговые навыки, а также умение выбирать грамотного руководителя проекта. В идеале так должно быть!
Неделя и два месяца это вообще нереальные сроки для одной задачи. Если задача занимает больше двух дней — она должна быть разбита на подзадачи.
В пределах 16-ти рабочих часов вполне реально обойтись без «незнаю почему, но много». Хотя, тут цифра сугубо индивидуальна — для кого-то это 3 часа, а для кого-то — 48. Но суть остается одна.
И, кстати, ПМу абсолютно не обязательно быть разработчиком.
В пределах 16-ти рабочих часов вполне реально обойтись без «незнаю почему, но много». Хотя, тут цифра сугубо индивидуальна — для кого-то это 3 часа, а для кого-то — 48. Но суть остается одна.
И, кстати, ПМу абсолютно не обязательно быть разработчиком.
Практика показывает что необходимо.
Не путайте «хрошо бы» и «необходимо». У меня есть знакомые неплохие ПМы, которые из программирования знают только то, чего нахватались от программеров, с которыми работают.
Так что практика(моя, да) все-таки показывает, что не обязательно.
Так что практика(моя, да) все-таки показывает, что не обязательно.
именно необходимо. всегда есть исключения, но редко. И те кого вы считаете неплохими ПМ-ами не факт что таковыми действительно являются.
Почему, обоснуйте? Т.е. ПМ совмещает разработку? Если ПМ был разработчиком 10 лет назад, это хороший ПМ?
Конечно не совмещает. И когда он был разработчиком не важно, важно что бы он не просто писал говнокод а именно перерос кодинг, когда дальше программировать уже неинтересно, все уже написано по сто раз, все паттерны изучены, все рефакторинги проведены. Когда человек стал ПМ-ом не потому что посчитал что это проще а денег больше, а потому что вырос просто из программистов, потому что интересно шакать дальше, интересно развиваться, учится новому, попробовать себя в этой области. Но не находясь долгое время в тесном коллективе программистов, не испытывая на себе влияние других ПМ-ов, сложно понять самое важное, то как каждое действие влияет на программиста. ПМ должен быть таким же технарем как и программер, понимать все особенности работы программиста, говорить с ними на одном языке. Но главное понять что менеджмент это прежде всего вещь социальная, и максимальный эффект получится только если поставить во главу угла человека, а все остальное должно ему помогать.
А люди не поработавшие долгое время в этой индустрии, они расценивают программистов как винтики, а себя как оператора пульта управления. Они думают что если просто дергать за такие вот рычажки механизм будет работать. Они так думают потому что небыли никогда внутри этого механизма.
А люди не поработавшие долгое время в этой индустрии, они расценивают программистов как винтики, а себя как оператора пульта управления. Они думают что если просто дергать за такие вот рычажки механизм будет работать. Они так думают потому что небыли никогда внутри этого механизма.
Почему нереальные, если менеджер доверяет разработчику, а тот готов брать на себя ответственность? Все случаи индивидуальны, я б сказал, что необходимо отсутствие догм у менеджера.
Ну, тут все просто — именно потому, что все люди. И в большинстве случаев — ошибаются. Ошибиться с прогнозом на 3 недели ГОРАЗДО(читай — в разы) проще, чем с прогнозом на 2-3-5-10-15 часов. Доверие тут ни при чем — человеку свойственно ошибаться.
Простой пример — программист говорит, что задача займет 3 недели. И ошибается в 2 раза(всякое бывает — не всегда и постоянно, но все же). Эти три недели покрыть нереально и по ушам получает менеджер.
Второй пример — программист говорит, что задача займет день. Ошибается в те же 2 раза. В крайнем случае — поработает на выходных, но сделает. И репутация фирмы не пострадает.
Простой пример — программист говорит, что задача займет 3 недели. И ошибается в 2 раза(всякое бывает — не всегда и постоянно, но все же). Эти три недели покрыть нереально и по ушам получает менеджер.
Второй пример — программист говорит, что задача займет день. Ошибается в те же 2 раза. В крайнем случае — поработает на выходных, но сделает. И репутация фирмы не пострадает.
ПМ всегда ошибается больше, потому что он меньше понимает собственно что это за работа. При нормальных отношениях программисты готовы работать много, чтобы снивелировать свои ошибки.
Любое разбиение задачи неравномерно, т.к. риски могут появиться на любой стадии. Поэтому оно помогает лишь оценить, работает человек или нет. Не более того.
Я не спорю, что на заводе нужна жесткая дисциплина, предсказуемое производство оно и здесь такое же. Вопрос в другом — как подтолкнуть человека сделать максимум того на что он способен на промышленной основе. К сожалению, очень мало менеджеров этим занимается.
Менеджерам: когда вы последний раз спрашивали разработчиков — все ли их устраивает в работе? или например — не хотели бы они заняться соседней проблемой в том же проекте?
Любое разбиение задачи неравномерно, т.к. риски могут появиться на любой стадии. Поэтому оно помогает лишь оценить, работает человек или нет. Не более того.
Я не спорю, что на заводе нужна жесткая дисциплина, предсказуемое производство оно и здесь такое же. Вопрос в другом — как подтолкнуть человека сделать максимум того на что он способен на промышленной основе. К сожалению, очень мало менеджеров этим занимается.
Менеджерам: когда вы последний раз спрашивали разработчиков — все ли их устраивает в работе? или например — не хотели бы они заняться соседней проблемой в том же проекте?
Последнее — на мозоль наступаете. Почему то это такая долгоиграющая болезнь российского софтостроения, когда к разработчику относятся как к производственному материалу. Он производит код, критерии к этому коду с точки зрения отечественного софтопроизводителя — максимально простой, максимально быстро, максимально одноразово.
Это уж разработчик сам старается себе работу облегчить и накопить себе инструментарий. Почему-то (точнее, понятно, почему) самые лучшие фирмы (для разработчика), это те, где менеджмент каким-то образом связан с западом.
Это уж разработчик сам старается себе работу облегчить и накопить себе инструментарий. Почему-то (точнее, понятно, почему) самые лучшие фирмы (для разработчика), это те, где менеджмент каким-то образом связан с западом.
Это симптом того, что в команде не поставлен процесс разработки, а не потому, что все люди.
Что подразумевается под «поставлен процесс разработки»? То, что описано в топике является процессом?
То, что описано в топике, это часть процесса, связанная непосредственно с разработкой конечного функционала. Еще взаимодействие с заказчиком, аналитика, и т.п.
Все верно, согласен.
Проблема в том, что плохо понятно как процесс может помочь в недооценке задачи. Кто должен оценивать? Должен ли кто-то вообще?
Проблема в том, что плохо понятно как процесс может помочь в недооценке задачи. Кто должен оценивать? Должен ли кто-то вообще?
Зависит от того, каким образом процесс описывает взаимодействие между разработчиками и как он предусматривает разделение обязанностей. Но имхо, как бы я постарался минимизировать временные убытки — задачи бьются на оптимальные для исполнения куски (с точки зрения алгоритмики и взаимодействия программных компонент), разделяются между разработчиками, разработчики выдают примерные сроки (заодно решаем проблемы с имплементацией). Путем скрама лид или ПМ каждый день актуализируют прогресс и опять же направляют в нужное русло. Обязательным условием является техническое превосходство или как минимум равенство лида над другими разработчиками. Жира не нужна, достаточно Microsoft Project.
То есть это необходимые условия для того, чтобы программист не ошибался в оценке своих задач?
Нет:) Это условия, при которых программист не будет ставить сроков 3 недели и потом ошибатся в два раза.
:))) Непонятно в чем тогда Вы со мной несогласны.
Я про то и говорил — надо изначально установить максимальный срок задачи. Так ошибку легче нивелировать.
Опять же, мне кажется, что Вам очень везет, если процесс на работе у Вас поставлен так, что вокруг никто не ошибается в сроках ;)
Я про то и говорил — надо изначально установить максимальный срок задачи. Так ошибку легче нивелировать.
Опять же, мне кажется, что Вам очень везет, если процесс на работе у Вас поставлен так, что вокруг никто не ошибается в сроках ;)
даже Проджект нужен лишь для красоты. Достаточно простой wiki
В этом случае, когда задачи большие и их несколько сложно разбить (например, пишем здоровенный веб-метод для портала), помогают scrum-митинги. Это так, к слову. Менеджер или лид прибегает, слушает что сделано, помечает прогресс. Заодно можно друг другу помочь трудности обходить.
У нас ПМ такой:) Почему это долго делать? Потому что сложно. Что, сложно одно поле в базу добавить? Вот я когда работал на дельфях в 95-м году… блаблабла.
Или — вот, почему так много ошибок в программе? Почему не тестируете? Потому что требования каждый раз меняются, а если не меняются то приходят новые. Не успеваем. Ну, не понимает человек что такое качество ПО.
Так и живем:) В результате разработчиков выгоняют работать в выходные, потому что управление накосячило. Но с точки зрения управления, все верно, оно думает что это мы такие дебилы:) Бесконечная война.
Или — вот, почему так много ошибок в программе? Почему не тестируете? Потому что требования каждый раз меняются, а если не меняются то приходят новые. Не успеваем. Ну, не понимает человек что такое качество ПО.
Так и живем:) В результате разработчиков выгоняют работать в выходные, потому что управление накосячило. Но с точки зрения управления, все верно, оно думает что это мы такие дебилы:) Бесконечная война.
А то что нужно ПМ заказчику сказать когда будет готово (да так, чтобы не через семь лет, да и так, чтобы успеть) вас не напрягает?
Это аналитика, RVK. Так как в 90% случаев, если программист сказал — «неделя», можно смело умножать на три и еще добавлять треть на риски.
А так будет видно — кто факапит, кто очень оптимистичен, а кто просто невменяемый.
А так будет видно — кто факапит, кто очень оптимистичен, а кто просто невменяемый.
Известный факт:
Если спросить у программиста сколько потребуется времени на создание нового справочника, скажем, для редактирования клиентов — он ответит неделя, а уйдет три.
Если спросить его сколько потребуется времени на создание новой формы диалога About — он скажет 2 часа, а справиться за 10 минут.
Большие задачи обычно недооцениваются, а маленькие напротив переоцениваются.
Именно по этому рекомендуют разбивать большие задачи на поменьше, а потом суммировать.
Так реалистичнее можно оценить масштаб трагедии. :)
Если спросить у программиста сколько потребуется времени на создание нового справочника, скажем, для редактирования клиентов — он ответит неделя, а уйдет три.
Если спросить его сколько потребуется времени на создание новой формы диалога About — он скажет 2 часа, а справиться за 10 минут.
Большие задачи обычно недооцениваются, а маленькие напротив переоцениваются.
Именно по этому рекомендуют разбивать большие задачи на поменьше, а потом суммировать.
Так реалистичнее можно оценить масштаб трагедии. :)
Не ужели для всего этого нужно вводить все эти правила?
к огромному сожалению…
А как без этого обходятся Agile-методики?
В моей практике не было «чистой» Agile разработки.
А то что было похоже, было со стопроцентным пролетанием всех DeadLine'ов.
И, к сожалению, в основном из-за программистов.
В самой Agile-методике, по-моему, конечный срок разработки не провозглашают фактором рабочего процесса вовсе.
А то что было похоже, было со стопроцентным пролетанием всех DeadLine'ов.
И, к сожалению, в основном из-за программистов.
В самой Agile-методике, по-моему, конечный срок разработки не провозглашают фактором рабочего процесса вовсе.
вот поэтому и пролетали дедлайны потому что не применяли все практики, наверное потому что просто не сумели понять их суть.
Agile-методика максимальна индифферентна к заказчику (Этим она вам и нравится)
В своей же практике, мы спользовали схему, что если программист успел вложится в сроки, которые сам назвал, то +40% к оплате этого куска работы.
В своей же практике, мы спользовали схему, что если программист успел вложится в сроки, которые сам назвал, то +40% к оплате этого куска работы.
и табличку «ударник программисткого труда»)))
Я про табличку не просто так написал. Прочтите книгу «Рабы майкрософт», и посмотрите как нормальные программисты относятся к подобного рода подачкам. За что премия, если программист может сделать что, то то он сделает. Если нет, то нет. Если ему не хочется работать потому что ПМ мудак, то проще сменить ПМ-а, и программист будет больше доволен и ПМ на долго а 40% один раз. Проще всего купить программиста деньгами, чем понять почему он не может работать так же хорошо и без денежной стимуляции. Ведь получается если ему денег не предлагать, он будет халявить? А если нет, то значит за эти 40% он работает на износ, значит будут у него проблемы в семье, недосып, что в итоге приведет к падению мотивации. Но да, проще не думать а дать человеку эти 40%, как в топку уголька подкинуть.
+40% — это аналог -28% в случае дефолта по времени и качеству.
А вы, на моё мнение, слишком эгоцентричны. ПМ не менее проффессионал, чем программист. И не факт, что менее нужный.
Да и если ПМ работает с большинством программистов успешно…
А вы, на моё мнение, слишком эгоцентричны. ПМ не менее проффессионал, чем программист. И не факт, что менее нужный.
Да и если ПМ работает с большинством программистов успешно…
ИМХО, Agile-методики (тот же Скрам) применять есть смысл только в хорошо сработанных командах опытных разработчиков, которые реально представляют себе, сколько они могут сделать за очередной спринт, и не навалят в TODO кучу тасков.
поверте у нас в команде не ламеры собраны
Одна из целей Agile — сделать из коллектива комманду за относительно небольшое время.
Одна из целей Agile — сделать из коллектива комманду за относительно небольшое время.
Одна из целей Agile — сделать из коллектива комманду за относительно небольшое время.
По крайней мере, в XP есть тоже предварительная оценка задачи и планирование. Причем, в XP как раз есть принцип, что трудоемкость оценивает программист, который делает задачу.
xprogramming.com.ua/planning.php
xprogramming.com.ua/planning.php
Ага. Только он это делает на в JIRA а во время игры в планирование
То есть если бы вас попросили писать трудоемкость на бумажных карточках, вы бы это приняли?
Я так не раз делал. Очень удобно.
я не очень понимаю в чем проблема: в перечне нововведений я вижу только 2 пункта, которые возлагают на девелопера две обязанности:
1. Ввести оценку времени выполнения
2. Ввести предполагаемый срок выполнения
Почему эти две вещи вызывают такое неприятие по сравнению с написанием их же на карточке?
Джира настолько неудобно, что заполнить там два поля очень сложно?
1. Ввести оценку времени выполнения
2. Ввести предполагаемый срок выполнения
Почему эти две вещи вызывают такое неприятие по сравнению с написанием их же на карточке?
Джира настолько неудобно, что заполнить там два поля очень сложно?
Потому что эти 2 пункта ИСКЛЮЧАЮТ игру в планирование, или скрам-митинги. Это означает, что мы меняем все приемущества практик коллективного планирования, на удобство менеджера, который не вставая с места будет получать сроки по задачам. Дело не в том что мне сложно проставить эти строки, а в том что соглашаясь на это, мы теряем кучу приемуществ практик планирования Scrum и XP
А что у вас уже внедрено, игра в планирование или скрам митинги? Почему занесение в джиру исключает перечисленные игры? Оно не может их дополнять?
У нас этого не внедрено. Было но похерили. Теперь новый техдир пытается внедрить свои методы.
Почему исключает объясняю. Дело в том что если есть скрам-митинги то не нужно то что предлагает техдир. В этом просто нет никакого смысла. Так что дополнять оно их не может. Оно может только дублировать.
Почему исключает объясняю. Дело в том что если есть скрам-митинги то не нужно то что предлагает техдир. В этом просто нет никакого смысла. Так что дополнять оно их не может. Оно может только дублировать.
А что именно было — скрам или XP?
Похерил новый техдир или до него? Почему похерили? Не могли бы вы порекомендовать что-то про планирование в скраме типа книжки «Экстремальное программирование: планирование»?
(Там есть аналог team velocity?)
Новый техдир в курсе, что есть скрам и XP, вы говорили с ним про это?
Почему нельзя агильно попланировав анести циферки в трекер для истории и техдира?
Похерил новый техдир или до него? Почему похерили? Не могли бы вы порекомендовать что-то про планирование в скраме типа книжки «Экстремальное программирование: планирование»?
(Там есть аналог team velocity?)
Новый техдир в курсе, что есть скрам и XP, вы говорили с ним про это?
Почему нельзя агильно попланировав анести циферки в трекер для истории и техдира?
1. Было XP. Но не полностью, а то что позволяют мои полномочия. Игра в планирование проводилась без участия заказчика. Но все равно это эффективнее чем обычное последовательное выполнение задач без итераций и контрольных точек.
2. Похерил ПМ. Я распланировал, и уехал в отпуск, передав расписанные планы ему. Когда вернулся увидел что за 5 дней из плана не сделано ничего, а люди занимались рефакторингом. Пришлось за последнюю неделю вкалывать полной что бы успеть к концу итерации сделать хотя бы основные задачи. На мои вопросы почему похерили план ПМ невнятно промычал что итак все нормально. Ну раз нормально, давай работать без плана сравним эффективность. После этого все пошло через жопу.
3. По Скраму не знаю. В принципе XP включает почти все техники скрама, разница в деталях.
4. Можно, ктож против. Вот пусть сам и вносит если это ему надо. Но я бы ему не советовал так как по хорошему план надо бы показывать заказчику и вешать на стену что бы он всегда мог посмотреть, а каждый день обновлять и JIRA и план это двойная работа. Тем более мне непонятно как в JIRA удобно отмечать прогресс по задаче. Но это уже не мои проблемы, если ПМ мазахист, это его проблемы.
2. Похерил ПМ. Я распланировал, и уехал в отпуск, передав расписанные планы ему. Когда вернулся увидел что за 5 дней из плана не сделано ничего, а люди занимались рефакторингом. Пришлось за последнюю неделю вкалывать полной что бы успеть к концу итерации сделать хотя бы основные задачи. На мои вопросы почему похерили план ПМ невнятно промычал что итак все нормально. Ну раз нормально, давай работать без плана сравним эффективность. После этого все пошло через жопу.
3. По Скраму не знаю. В принципе XP включает почти все техники скрама, разница в деталях.
4. Можно, ктож против. Вот пусть сам и вносит если это ему надо. Но я бы ему не советовал так как по хорошему план надо бы показывать заказчику и вешать на стену что бы он всегда мог посмотреть, а каждый день обновлять и JIRA и план это двойная работа. Тем более мне непонятно как в JIRA удобно отмечать прогресс по задаче. Но это уже не мои проблемы, если ПМ мазахист, это его проблемы.
А где вы накапливали статистику, чтобы скорость команды считать?
Эту практику внедрить не успели, пока итераций мало, можно просто вводить поправочный коэфициент для каждого программиста на основе результатов последней итерации. Получилось, кстати, очень интересно. По итогам первой итерации, из 4-х, на тот момент программистов, 2 уложились в сроки, что называется, на флажке, один отстал, и один сделал все быстрее. Это четко было видно по плану. Но так как один человек из команды справился раньше, он помог тому кто не уложился. При анализе стало понятно причины такого расклада. Опоздавший просто последние года два программировал на C++, и подзабыл Java, а тот кто сделал быстрее лучше всех нас знает те фреймворки что мы применяем. Поэтому решил на следующую итерацию не вводить коэфициентов. Тот кто опоздал уже Java вспомнил, значит сделает быстрее. А наш гуру пусть будет как подстраховка, если опять сделает раньше, поможет другим. На следующую итерацию мы все опять успели в сроки к презентации, правда пришлось покоцать задачи из за 5-и дневного рефакторинга непонятно с какого перепугу проведенного.
Потом отдал процесс в руки ПМ-а и все. С тех пор никто не видел ни одного плана.
Но если бы понадобилась точная статистика, а она бы понадобилась со временем, то получить её всегда несложно из старых планов, хранящихся в свн. Так же можно удобно использовать wiki для хранения планов по итерациям и статистики.
Потом отдал процесс в руки ПМ-а и все. С тех пор никто не видел ни одного плана.
Но если бы понадобилась точная статистика, а она бы понадобилась со временем, то получить её всегда несложно из старых планов, хранящихся в свн. Так же можно удобно использовать wiki для хранения планов по итерациям и статистики.
я правильно понял, что все было так:
1. вы внедрили частично XP (кстати, какая у вас роль — ведущий программист?)
2. ПМ его похерил
3. Новый техдир пытается наладить хоть какое-то планирование
Новый техдир не знает или не считает XP целесообразным. Вы говорили с ним по этому поводу?
1. вы внедрили частично XP (кстати, какая у вас роль — ведущий программист?)
2. ПМ его похерил
3. Новый техдир пытается наладить хоть какое-то планирование
Новый техдир не знает или не считает XP целесообразным. Вы говорили с ним по этому поводу?
Вы поняли правильно. Роль да, ведущий программист, но это название ничего не значит, никаких отличий или полномочий нет.
я не хочу пока общаться с новым техдиром. Я думаю что первая задача техдира познакомится с разработчиками. Каюсь, он раз меня позвал познакомится, точнее для того что бы я объяснил ему архитектуру. Меня и одмина. Я сказхал что не плохо бы было пригласить и других программистов. Пригласили, ребята хотя бы познакомились.
Но что-то он внедрить пытается. Хотя что я понятия не имею. ОН с нами не общается и даже не здоровается пока сам руку не протянешь.
я не хочу пока общаться с новым техдиром. Я думаю что первая задача техдира познакомится с разработчиками. Каюсь, он раз меня позвал познакомится, точнее для того что бы я объяснил ему архитектуру. Меня и одмина. Я сказхал что не плохо бы было пригласить и других программистов. Пригласили, ребята хотя бы познакомились.
Но что-то он внедрить пытается. Хотя что я понятия не имею. ОН с нами не общается и даже не здоровается пока сам руку не протянешь.
Я то понял для чего все это. Мне непонятно причем тут JIRA. Аналитика нужна и полезна, но почему нельзя руководствоватся данными планов? В начале итерации распределены задачи, оценены. Прогресс смотрим ежидненвно. По итогам итерации анализируем. Мне непонятно зачем в JIRA версии если версии должны определятся по набору запланированных фич в начале итерации и по количеству их реально выполненных вконце. Для чего здесь понятие компонент? Подзадач? Эти вещи вообще каккой имеют практический смысл?
почему нельзя руководствоватся данными планов?
потому что есть планы, а есть реально потраченное время.
В начале итерации распределены задачи, оценены. Прогресс смотрим ежидненвно. По итогам итерации анализируем.
А вы уверены, что через месяц вы вспомните подробности итерации? Какие задачи были недооценены, а какие наоборот — переоценены?
Для чего здесь понятие компонент? Подзадач?
На это уже ответил выше suglosta
Эти вещи вообще каккой имеют практический смысл?
Имхо, да
потому что есть планы, а есть реально потраченное время.
В начале итерации распределены задачи, оценены. Прогресс смотрим ежидненвно. По итогам итерации анализируем.
А вы уверены, что через месяц вы вспомните подробности итерации? Какие задачи были недооценены, а какие наоборот — переоценены?
Для чего здесь понятие компонент? Подзадач?
На это уже ответил выше suglosta
Эти вещи вообще каккой имеют практический смысл?
Имхо, да
1. Планы ДОЛЖНЫ отражать реальную ситуацию в каждый момент времени.
2. А какая разница какие задачи сколько времени делались? Главное сколько было потрачено времени на всю итерацию. Этих данных достаточно для оценки эффективности работы программиста. Но в любом случае ПМ или там Тимлид должны ежедневно контроллировать процесс, таким образом у них эта информация все равно будет, так как они корректируют план ежедневно, и если им интересна история, можно например загнать планы в svn
3. Опять же информация по подзадачам должна быть у тимлида на карте(в екселе где угодно). Программер итак знает как он будет делать задачу, и тимлид просто интересуется каждый день какие из подзадачь в каком состоянии. Так он будет еще и контроллировать, кроме общего хода работ, любые изменения в процессе и влиять на него (часто некоторые подзадачи можно отложить, если не укладываемся в сроки, но делать это надо своевременно).
Мое мнение что
1. JIRA не для этого мусора интересного только ПМ-у и тимлиду
2. Это попытка облегчить себе работу.
3. Такой подход расслабляет, можно не общаться каждый день с программерами, можно не контроллировать процесс, все есть в JIRA
4. Это может побудить к перекладыванию некоторой отвественности на плечи программистов
5. Это использование сложного инструмента взамен простого
6. Процесс либо будет дублироваться либо будет недоступен для заказчика, который не хочет ничего знать о JIRA и это его право.
2. А какая разница какие задачи сколько времени делались? Главное сколько было потрачено времени на всю итерацию. Этих данных достаточно для оценки эффективности работы программиста. Но в любом случае ПМ или там Тимлид должны ежедневно контроллировать процесс, таким образом у них эта информация все равно будет, так как они корректируют план ежедневно, и если им интересна история, можно например загнать планы в svn
3. Опять же информация по подзадачам должна быть у тимлида на карте(в екселе где угодно). Программер итак знает как он будет делать задачу, и тимлид просто интересуется каждый день какие из подзадачь в каком состоянии. Так он будет еще и контроллировать, кроме общего хода работ, любые изменения в процессе и влиять на него (часто некоторые подзадачи можно отложить, если не укладываемся в сроки, но делать это надо своевременно).
Мое мнение что
1. JIRA не для этого мусора интересного только ПМ-у и тимлиду
2. Это попытка облегчить себе работу.
3. Такой подход расслабляет, можно не общаться каждый день с программерами, можно не контроллировать процесс, все есть в JIRA
4. Это может побудить к перекладыванию некоторой отвественности на плечи программистов
5. Это использование сложного инструмента взамен простого
6. Процесс либо будет дублироваться либо будет недоступен для заказчика, который не хочет ничего знать о JIRA и это его право.
Вы идеалист.
1 — х*й. планы с реальностью совпадают на очень недолгом промежутке времени.
2 — итерация состоит из задач, на которые уходит время. Времени на задачу уходит примерно в 1.5-3 раза больше чем сказано изначально.
по мнению:
1 — jira — это инструмент учета задач и подсчета статистики. Заниматься этим в экселе имеет смысл, когда команда не более 2-5 человек, иначе неудобно.
2. и это правильно, чем больше за меня делает компьютер, тем больше я успеваю сделать
3. не сказал бы, в jira все-равно есть не все. jira — не «42»
4. программисту желательно быть ответственным за то время, которое он объявляет на задачу. Да, бывает, что вроде и сделал в срок, но вылазят какие-то мелкие недоработки которые надо править или мелкие фичи без которых не труЪ потому и множитель от 1.5 до 3 а то и поболее на время которое говорит программист.
5. хз. jira реально нужна, когда ПМ перестает успевать держать в голове или в экселе все сроки, розданные и запланированные задачи и прочее.
6. Заказчика стоит держать в курсе событий. Хотя бы по еженедельным версиям. При выписанном выше подходе, это сделать проще, нежели когда есть стопицот задач из которых 70% уже сделаны, 10% делаются уже полгода, остальное типа в процессе. Работал с таким подходом, спасибо.
Мое мнение, что это нормальный, рабочий workflow agile-like разработки. Может кое-что перекручено, но нормально. Главное — это заставить рзработчиков-раздолбаев заносить все правильно и в срок.
З.Ы. извините за не самую цензурную лексику
1 — х*й. планы с реальностью совпадают на очень недолгом промежутке времени.
2 — итерация состоит из задач, на которые уходит время. Времени на задачу уходит примерно в 1.5-3 раза больше чем сказано изначально.
по мнению:
1 — jira — это инструмент учета задач и подсчета статистики. Заниматься этим в экселе имеет смысл, когда команда не более 2-5 человек, иначе неудобно.
2. и это правильно, чем больше за меня делает компьютер, тем больше я успеваю сделать
3. не сказал бы, в jira все-равно есть не все. jira — не «42»
4. программисту желательно быть ответственным за то время, которое он объявляет на задачу. Да, бывает, что вроде и сделал в срок, но вылазят какие-то мелкие недоработки которые надо править или мелкие фичи без которых не труЪ потому и множитель от 1.5 до 3 а то и поболее на время которое говорит программист.
5. хз. jira реально нужна, когда ПМ перестает успевать держать в голове или в экселе все сроки, розданные и запланированные задачи и прочее.
6. Заказчика стоит держать в курсе событий. Хотя бы по еженедельным версиям. При выписанном выше подходе, это сделать проще, нежели когда есть стопицот задач из которых 70% уже сделаны, 10% делаются уже полгода, остальное типа в процессе. Работал с таким подходом, спасибо.
Мое мнение, что это нормальный, рабочий workflow agile-like разработки. Может кое-что перекручено, но нормально. Главное — это заставить рзработчиков-раздолбаев заносить все правильно и в срок.
З.Ы. извините за не самую цензурную лексику
Вы не поняли наверное
>1 — х*й. планы с реальностью совпадают на очень недолгом промежутке времени.
Я не горю что они сами по себе будут совпадать. Их надо поддерживать, и корректировать ежедневно.
2. Это время необходимо учитывать. Есть идиальная оценка а есть реальная, которая строится с учетом рисков. Сначало можно просто умножать на 2-3, потом, когда соберется статистика, можно вычислить и более точный коэфициент. Почитайте XP там об этом сказано.
>1 — х*й. планы с реальностью совпадают на очень недолгом промежутке времени.
Я не горю что они сами по себе будут совпадать. Их надо поддерживать, и корректировать ежедневно.
2. Это время необходимо учитывать. Есть идиальная оценка а есть реальная, которая строится с учетом рисков. Сначало можно просто умножать на 2-3, потом, когда соберется статистика, можно вычислить и более точный коэфициент. Почитайте XP там об этом сказано.
ИМХО — то что вы имеете в виду — это как раз отчет по версии это и будет тем самым планом. Есть estimate, есть n разрабов, есть m незакрытых тасков. Есть estimat'ы на текущие таски.
я скорее не догоняю, что не нравится в схеме, я не вижу сильно излишней формализации, кроме может еженедельного релиза версии и 3 пункта.
я скорее не догоняю, что не нравится в схеме, я не вижу сильно излишней формализации, кроме может еженедельного релиза версии и 3 пункта.
Хм. Посмотрите с точки зрения разработчика на 2 и 3ий пункт.
Вот к примеру я, разработчик-раздолбай. У меня есть 5 незакрытых задач, по которым мне надо произвести работы. Приходит ПМ, весь такой модненький, говорит — чувак, гляди. У нас есть новая задачка. Сделай ее по workflow. Окей. Я смотрю — ха, ну, задачка то дерьмо, сделаю быстро. Но я ведь хитрый, я не люблю большого брата. Срок поставлю больше, чтобы прикрыть свою задницу и успеть сделать какую-нибудь ту из пяти задач.
Я к тому, что разработчики будут врать в свою пользу, какими бы прилежными они не были. Поэтому я согласен, что здесь имеет место быть перевод ответственности с ПМа на разработчиков. Причем, сам же ПМ подставляется. В худшем случае он разработчиков уволит, он и новую работу найдут, потому что они производят код, а ПМ будет с пробитым проектом.
Вот к примеру я, разработчик-раздолбай. У меня есть 5 незакрытых задач, по которым мне надо произвести работы. Приходит ПМ, весь такой модненький, говорит — чувак, гляди. У нас есть новая задачка. Сделай ее по workflow. Окей. Я смотрю — ха, ну, задачка то дерьмо, сделаю быстро. Но я ведь хитрый, я не люблю большого брата. Срок поставлю больше, чтобы прикрыть свою задницу и успеть сделать какую-нибудь ту из пяти задач.
Я к тому, что разработчики будут врать в свою пользу, какими бы прилежными они не были. Поэтому я согласен, что здесь имеет место быть перевод ответственности с ПМа на разработчиков. Причем, сам же ПМ подставляется. В худшем случае он разработчиков уволит, он и новую работу найдут, потому что они производят код, а ПМ будет с пробитым проектом.
1. 7 +- 2 если следовать Скраму. Если почитаете Джоэл о программировании то увидите что и там советуют эксель. Если разработчиков больше, стоит подумать о разделении на отделы, как поступают многие крупные компании, в том числе и майкрософт.
2. Конечно правильно. Только мне честно плевать на проблемы ПМ-а, и я не готов облегчать ему работу за свой счет. В итоге продукт производим мы.
3. Так и будет. Если раньше и без жиры я мог месяц делать вид что работаю и это оставалось незамеченным, потому что даже никто не спрашивал а что я вообще делаю, и сколько времени осталось. А я мог позволить, так как никому никаких сроков не называл. Когда будет все на блюдичке, ПМ вообще из своего угла будет выходить только в туалет.
4. Я не про эту отвественность. Я про другую, такую как следить за изменением подзадач, и вовремя ставить на себя же новые, следить за переключением с одной задачи на другую, отмечая увеличение общего времени по каждой, следить за проблемами, отражая все в жире, и т.д.
5. Нужна, согласен. Хотя я бы использовал бы eTraxis.Но она нежна нам, программистам. И как ПМ будет неуспевать если он даже не начинал. Вот пусть начнет а потом придет и скажет я не успеваю, наймут еще одного. А сейчас он вообще ничего в голове не держит, и даже не пытается.
6. Опять вы меня не поняли. Для заказчика должен висеть план на стене, и презентация раз в месяц. Жира ему не нужна. Поэтому если ПМ будет вести все дела в Жире, ему придется переносить всю информацию отдельно в тот же эксель или мс проджект, для того что бы показать заказчику, и поддерживать оба варианта.
agile-like разработкой тут и не пахнет. А разработчики — раздолбаи все равно ничего заносить не будут. Я иак и сказал что менять ничего в своей работе с жирой не буду. По крайней мере пока не уижу других, шагов по улучшению процесса.
2. Конечно правильно. Только мне честно плевать на проблемы ПМ-а, и я не готов облегчать ему работу за свой счет. В итоге продукт производим мы.
3. Так и будет. Если раньше и без жиры я мог месяц делать вид что работаю и это оставалось незамеченным, потому что даже никто не спрашивал а что я вообще делаю, и сколько времени осталось. А я мог позволить, так как никому никаких сроков не называл. Когда будет все на блюдичке, ПМ вообще из своего угла будет выходить только в туалет.
4. Я не про эту отвественность. Я про другую, такую как следить за изменением подзадач, и вовремя ставить на себя же новые, следить за переключением с одной задачи на другую, отмечая увеличение общего времени по каждой, следить за проблемами, отражая все в жире, и т.д.
5. Нужна, согласен. Хотя я бы использовал бы eTraxis.Но она нежна нам, программистам. И как ПМ будет неуспевать если он даже не начинал. Вот пусть начнет а потом придет и скажет я не успеваю, наймут еще одного. А сейчас он вообще ничего в голове не держит, и даже не пытается.
6. Опять вы меня не поняли. Для заказчика должен висеть план на стене, и презентация раз в месяц. Жира ему не нужна. Поэтому если ПМ будет вести все дела в Жире, ему придется переносить всю информацию отдельно в тот же эксель или мс проджект, для того что бы показать заказчику, и поддерживать оба варианта.
agile-like разработкой тут и не пахнет. А разработчики — раздолбаи все равно ничего заносить не будут. Я иак и сказал что менять ничего в своей работе с жирой не буду. По крайней мере пока не уижу других, шагов по улучшению процесса.
версия — это та-же итерация. так что все к месту. на версию намечаются некий набор фичей. они реализуются. По релизу версии раздаются люля тем, кто профакапил поставленные задачи, оставшееся переносится на след. итерацию.
Вот как раз читаю славного дядьку Стива Макконнелла и его руководство по выживанию. Он предупреждал, что формализация процесса разработки будет вызывать сопротивление людей, с ней не сталкивавшихся. Я ему в принципе верил, но теперь вижу воочию.
Имхо, классный мужик — этот ваш техдир. И продуктивносьт команды увеличится. Если, конечно, все будет применено на практике так, как описано.
Имхо, классный мужик — этот ваш техдир. И продуктивносьт команды увеличится. Если, конечно, все будет применено на практике так, как описано.
Я не против формализации, и мало того я каждый день горяю что у нас нет процесса, и первый выступаю за его наладку. Мало того в начале проекта я сам занимался этими вещами, планированием, распределением задач, контролем, и мы четко укладывались в сроки, и процесс был налажен. Потом задачи разработки и уход в отпуск вынудили переложить эту ответственность на неумеху ПМ-а. После этого все пошло крахом. Но опыт наладки процесса у меня есть и я только за формализацию обоими руками.
НО формализация ради формализации — зло. А здесь, возникает ощущение что хотят все сделать правильно, но не знают как, или не могут избавится от стереотипов.
НО формализация ради формализации — зло. А здесь, возникает ощущение что хотят все сделать правильно, но не знают как, или не могут избавится от стереотипов.
Лично я не вижу тут излишней формализации.
Имхо, это просто подход отличный от вашего, о котором вы знаете, что он эффективен. Что и вызывает у вас неприятие. И я вас прекрасно понимаю. Может, стоить обсудить с техдиром? Иди это невозможно?
Имхо, это просто подход отличный от вашего, о котором вы знаете, что он эффективен. Что и вызывает у вас неприятие. И я вас прекрасно понимаю. Может, стоить обсудить с техдиром? Иди это невозможно?
Обсудим. Сейчас обсудили с ПМ-ом. Он не отрицает что это все нужно лично ему, и типа от программеров не потребуется ничего делать. Но тут же в разговоре выясняется что делать таки придется, «ну этож мелочи» как он говорит. Вообщем, я ему сказал делай с JIRA что хочешь, только, что бы нас это не касалось. Он просто не понимает что пытается подменить Жирой личное общение и не понимает чем это грозит. И есть у меня чувство что хорошим это не кончится. Будут вопросы потом к программистам: почему не отметил время, почему не закрыл подзадачу, почему не отметил изменения в подзадачах и т.д.
Пока я ему предложил встречный вариант — ежедневная отчетность. У нас даже есть инструмент для этого, только им никто не пользуется. Он согласен, что отчетность нужна (типа что сегодня делал и сколько времени ушло), но пока недопонимает, что это полностью удовлетворяет его потребностям в аналитике и при этом занимает у программистов максимум 15 мин времени причем в конце дня когда вся работа закончена, не отвлекая. Теперь решение за техдиром.
Пока я ему предложил встречный вариант — ежедневная отчетность. У нас даже есть инструмент для этого, только им никто не пользуется. Он согласен, что отчетность нужна (типа что сегодня делал и сколько времени ушло), но пока недопонимает, что это полностью удовлетворяет его потребностям в аналитике и при этом занимает у программистов максимум 15 мин времени причем в конце дня когда вся работа закончена, не отвлекая. Теперь решение за техдиром.
осторожнее :) у меня уже есть личный пример нескольких компаний, где введение ежедневной отчетности привело к развалу компании не больше чем через 2 месяца. исключений пока не было
У меня есть пример когда отчетность в которой норма, и компания жива до сих пор)) Это РБК
не упоминая о том, что эта компания имеет сейчас серьезные проблемы с финансами и не упоминая того, что помимо IT холдинг имеет активы в других областях хочется спросить — вы уверены, что ежедневная (!) отчетность внедрена во всем холдинге без исключений?
Не во всем. Интернет проекты не отчитываются, например.
Как раз интернет проекты отчитываются это точно. Про остальные отделы точно не знаю.
сейчас все имеют проблемы с финансами, и не потому что пишут отчеты а потому что кризис
все имеют проблемы на уровне банкротства? :)
впрочем я согласен с тем, что отчеты на это не влияют. скорее политика компании влияет и на отчеты и на состояние самой компании…
впрочем я согласен с тем, что отчеты на это не влияют. скорее политика компании влияет и на отчеты и на состояние самой компании…
верно я понял что компании требующие отчетов имеют меньше шансов стать банкротом в условиях кризиса?
*требующие = не требующие
формально — нет конечно :) что с поправкой что нет. я не думаю, что тут есть прямая связь
если же подходить менее формально, то мое мнение такое, что как правило в компаниях, которые минимизируют в кризис свою внутреннюю бюрократию имеют существенно больше шансов на выживание.
ps естественно, речь идет о минимизации именно бюрократии в плохом смысле слова, а не необходимой документации.
если же подходить менее формально, то мое мнение такое, что как правило в компаниях, которые минимизируют в кризис свою внутреннюю бюрократию имеют существенно больше шансов на выживание.
ps естественно, речь идет о минимизации именно бюрократии в плохом смысле слова, а не необходимой документации.
то есть надо свернуть так же и бухгалтерскую отчетность, не просить заявлений на отпуск, увольнение, забить на больничные, командировочные талоны? Это ведь тоже бюрократия. Тогда точно шансы выжить в кризис повысятся.
я же написал — «кроме необходимой документации»
все бумаги бухгалтерии, а также заявления на увольнение, например, проверяются налоговой
а вот зачем писать бумаги, без которых можно обойтись...?
все бумаги бухгалтерии, а также заявления на увольнение, например, проверяются налоговой
а вот зачем писать бумаги, без которых можно обойтись...?
я же писал выше что конкретно в РБК эти отчеты нужны для аудита
расскажите тогда подробнее как и куда уходят и обрабатываются эти отчеты?
мне как-то совсем не представляется какой аудит (который вообще-то делается, как я понимаю, только по финансовым показателям) можно построить по ежедневным отчетам программистов и что из этого аудита можно получить в результате
и причину почему эти отчеты нельзя собирать из других источников
мне как-то совсем не представляется какой аудит (который вообще-то делается, как я понимаю, только по финансовым показателям) можно построить по ежедневным отчетам программистов и что из этого аудита можно получить в результате
и причину почему эти отчеты нельзя собирать из других источников
да откуда я знаю. нам было сказанно что отчеты нужны для оцкенки капитализации компании которая нужна для аудита. я не экономист и в детали не вникал. аудит не внутренний а внешний.
я не могу представить других источников кроме как генератора случайных отчетов.
я не могу представить других источников кроме как генератора случайных отчетов.
«Рыночная капитализация (англ. market capitalization) акционерной компании — это стоимость всех её акций, то есть цена, которую необходимо было бы заплатить в случае её покупки (если не учитывать изменение цен акций в процессе их скупки). Вычисляется данная величина как произведение цен акций на количество выпущенных акций.»
«Аудит (аудиторская проверка) — независимая проверка бухгалтерской отчётности с целью выражения мнения о её достоверности.»
отчеты программистов тут не при чем, боюсь, что вам ляпнули первое что пришло в голову или что пришло в голову начальству когда менеджеры спросили «а как это людям-то объяснять?». я бы при этом подумал бы что в такой компании работать не стоит.
источников полно: SVN (коммиты), багтрекер, план работ вместе с отчетами тестировщиков, сводная статистика по покрытию кода, метрики по коду, отчеты о релизах в том числе внутренних, отчеты ночного билда итп…
«Аудит (аудиторская проверка) — независимая проверка бухгалтерской отчётности с целью выражения мнения о её достоверности.»
отчеты программистов тут не при чем, боюсь, что вам ляпнули первое что пришло в голову или что пришло в голову начальству когда менеджеры спросили «а как это людям-то объяснять?». я бы при этом подумал бы что в такой компании работать не стоит.
источников полно: SVN (коммиты), багтрекер, план работ вместе с отчетами тестировщиков, сводная статистика по покрытию кода, метрики по коду, отчеты о релизах в том числе внутренних, отчеты ночного билда итп…
но в принципе я понял, что отчеты если и виноваты в проблемах РБК то это очень малюсенький процент в общих причинах кризиса.
так я и не говорю, что виноваты :)
наоборот, отчетность это как правило последствия других, менее приятных действий (или бездействия, а также некомпетентности) руководства.
было бы странно думать, что в моем изначально высказывании была мысль о том, что именно каждодневные отчеты являются причиной кризиса компании :)
наоборот, отчетность это как правило последствия других, менее приятных действий (или бездействия, а также некомпетентности) руководства.
было бы странно думать, что в моем изначально высказывании была мысль о том, что именно каждодневные отчеты являются причиной кризиса компании :)
Какаяж там отчетность? Там просто мыло для начальства, что ты не прогуливаешь.
Ну, я щас живу с ежедневной отчетностью. Но там отчетности список сделанного + время в офисе. Это — нормально, хоть поначалу непривычно и лениво.
большего и не надо
чтож, у меня другое мнение и я не считаю это нормальным
мне кажется, что такая отчетность не имеет права на существования в любой организации не только по причине того, что на нее тратится время рядовых и не только сотрудников (можно в каждом случае подсчитать сколько времени и денег уходит на заполнение + «перестройку» на эту задачу, плюс время на обработку в месяц в компании), но и по причине того, что в случае когда менеджеры среднего звена без такой отчетности не знают что творится у них в отделе\проекте — таких менеджеров надо увольнять.
другая сторона проблемы ежедневной отчетности в том, что она бывает вводится людьми, которые сильно формализуют процесс при этом на корню убивая любые человеческие отношения. а хороший менеджер это ни в коем случае не машина, также как и работники. в этом случае идет как правило сильная демотивация коллектива.
зы я конечно не имею ввиду автоматические средства сбора информации типа баг-трекеров если мы говорим об IT. точнее, статистику, на них построенную.
мне кажется, что такая отчетность не имеет права на существования в любой организации не только по причине того, что на нее тратится время рядовых и не только сотрудников (можно в каждом случае подсчитать сколько времени и денег уходит на заполнение + «перестройку» на эту задачу, плюс время на обработку в месяц в компании), но и по причине того, что в случае когда менеджеры среднего звена без такой отчетности не знают что творится у них в отделе\проекте — таких менеджеров надо увольнять.
другая сторона проблемы ежедневной отчетности в том, что она бывает вводится людьми, которые сильно формализуют процесс при этом на корню убивая любые человеческие отношения. а хороший менеджер это ни в коем случае не машина, также как и работники. в этом случае идет как правило сильная демотивация коллектива.
зы я конечно не имею ввиду автоматические средства сбора информации типа баг-трекеров если мы говорим об IT. точнее, статистику, на них построенную.
просто неп надо впадать в крайности. Отчет должен заполняться минут 15 максимум в максимально свободной форме. Да и нужен он скорее для самоконтроля, и для самоотмазки типа «что я делал все это время? так вот посмотрите»
не, крайность — это ежедневный отчет :) еще раз скажу, что вы учитываете в такой формулировке только себя и свое отношение. и это хоть и правильно для вас, но в целом такое решение неэффективно.
поясню:
всю информацию о моей деятельности как программиста можно собрать в трекере и «свн» в конце недели менеджеру в сводном отчете одной кнопкой. а в случае 15и минут для заполнения получается еще скажем 15 минут на «переключение» в среднем, те полчаса в день. для компании из 16и человек, включая всех кто связан с этими отчетами, можно уже нанять еще человека вместо написания отчетов.
это еще не учитывая то, что сбор, обработка и перенос в цифровой вид (если отчет на бумаге) ежедневной (!) информации в свободной форме занимает времени больше 15и минут…
а для самоконтроля лучше подходят тайм-трекеры если очень уж хочется себя контролировать или недельный список задач на бумажке с написанными рукой за 5 минут временными рамками, если контролировать себя надо меньше. и такое решение позволяет всем (!!! а не только тем, кому нравится самоконтроль) сотрудникам не чуствовать себя механизмами, а также позволяет не задумываться о том, что все эти отчеты никто и никогда не читает (дада!) и нужны только для поддержания видимости трудовой дисциплины.
те с моей стороны крайности может быть две — ежедневные отчеты и отсутствие какого-либо контроля вообще. все остальное зависит от кучи факторов, как то: задачи, коллектива, количества людей в команде итп…
поясню:
всю информацию о моей деятельности как программиста можно собрать в трекере и «свн» в конце недели менеджеру в сводном отчете одной кнопкой. а в случае 15и минут для заполнения получается еще скажем 15 минут на «переключение» в среднем, те полчаса в день. для компании из 16и человек, включая всех кто связан с этими отчетами, можно уже нанять еще человека вместо написания отчетов.
это еще не учитывая то, что сбор, обработка и перенос в цифровой вид (если отчет на бумаге) ежедневной (!) информации в свободной форме занимает времени больше 15и минут…
а для самоконтроля лучше подходят тайм-трекеры если очень уж хочется себя контролировать или недельный список задач на бумажке с написанными рукой за 5 минут временными рамками, если контролировать себя надо меньше. и такое решение позволяет всем (!!! а не только тем, кому нравится самоконтроль) сотрудникам не чуствовать себя механизмами, а также позволяет не задумываться о том, что все эти отчеты никто и никогда не читает (дада!) и нужны только для поддержания видимости трудовой дисциплины.
те с моей стороны крайности может быть две — ежедневные отчеты и отсутствие какого-либо контроля вообще. все остальное зависит от кучи факторов, как то: задачи, коллектива, количества людей в команде итп…
Ежедневная отчётность? Нет.
Знаю по себе и тем, кем довелось руководить. Бывает у человека весь день голова болит и он толком ничего не делает, а бывает как на крыльях за день делает то, что требовалось за неделю.
А при ежедневной отчётности неуспевающие стараются создать иллюзию деятельности.
Уж лучше чёткий набор задач на неделю давать.
Что касается проблем с внедрением… да я когда внедрял SVN и Мантису на меня долго все матерились, включая начальство, которому видите ли «некогда создавать там тикеты и вообще проще сказать словами»
Ничего, привыкли.
Знаю по себе и тем, кем довелось руководить. Бывает у человека весь день голова болит и он толком ничего не делает, а бывает как на крыльях за день делает то, что требовалось за неделю.
А при ежедневной отчётности неуспевающие стараются создать иллюзию деятельности.
Уж лучше чёткий набор задач на неделю давать.
Что касается проблем с внедрением… да я когда внедрял SVN и Мантису на меня долго все матерились, включая начальство, которому видите ли «некогда создавать там тикеты и вообще проще сказать словами»
Ничего, привыкли.
если у вас такой стиль разработки и вы укладываетесь в сроки, то так и пишите «болела голова ничего не делал». Если в итоге вы удовлетворяете всех, то никто и слова не скажет. В отчетах главное честность.
Человек такое существо, скажу я вам, склонное ко всяким нехорошим поступкам. У меня всё проще сделано — SVN логи. По ним всё прекрасно видно, не только комментарии программиста но и список того что он делал.
Сделать срез по отдельному дню проще простого. Хочется правда к этому и веб-интерфейс и багтрекинг, а Trac правда мне как-то не приглянулся, у него всё плохо, когда есть много мелких проектов. Придётся либо искать что-либо готовое, либо писать своё.
Сделать срез по отдельному дню проще простого. Хочется правда к этому и веб-интерфейс и багтрекинг, а Trac правда мне как-то не приглянулся, у него всё плохо, когда есть много мелких проектов. Придётся либо искать что-либо готовое, либо писать своё.
Отлично. Просто отлично! Вы выступаете против какой-то там излишней бюрократии, но за какой-то там левый инструмент, которым никто не пользуется (и никто не будет) — вы двумя руками за! Инструмент отчётности лично для менеджера, оторванный от workflow — это и есть большое зло, против которого вы так рьяно тут выступаете.
JIRA же худо-бедно уже встроена в ваш процесс, так я не вижу причин почему бы не расширить её функционал — пускай она выступает инструментом отчётности для менеджера, а не только issue-трекером.
Теперь по пунктам:
1. Версии — это вообще основа основ итерационного метода разработки. Благодаря версии становится понятно, а что же мы такого релизнули в пятницу (тестировщики видят, что тестить). Благодаря версии становится понятно в какой версии тестировщики нашли баг. Благодаря версии менеджер ставит приоритеты — в какой версии, что нужно делать (это нужно срочно, это подождёт пару недель, этим вообще надо заниматься только когда багов не будет). И всё это вы получаете ровно за 1 клик (!) при создании и закрытии тикета.
2. Сабтаски нужны затем, что не всегда менеджер и тестировщик могут определить границы ответственности. Но задача есть и её нужно решить. Разработчик, которому назначен таск, видит несправедливость — в задаче есть пункты, которые вообще не в его компетенции — так он создаёт сабтаск и назначает его на нужного человека.
3. Компоненты нужны для быстрого ориентирования в проблемах. Тестировщик указывает в задаче компонент, в котором он нашёл баг (ровно 1 клик). Программист с одного взгляда на список тикетов понимает про что этот баг, потому что там указан компонент. Менеджер знает приоритеты по компонентам, а также может определить проблемные компоненты (в каком-то слишком много багов — может стоит поручить техлиду сделать ревью, вместо того чтобы программисты делали локальные фиксы? а какой-то компонент может недостаточно широко тестируется (слишком мало заведено тикетов)).
4. Estimated time каждой задачи нужен для общей оценки проекта. Пускай каждый проставит время (пусть и оторванное от реальности) для своих задач, но у менеджера появится инструмент: для отслеживания общего срока проекта, для выбивания больших ресурсов из директора (оперируем в понятных директору человекочасах), для оценки количества работ по компонентам, для оценки количества работ по версиям (ежу понятно, что если на текущую версию требуется 100 человекочасов, у меня 5 человек, а релиз версии — послезавтра, то всё мы не успеем, что-то (что не было обещано заказчику к этой пятнице) надо перенести на следующую версию)
Единственное, что мне не нравится в письме вашего ПМ, так это «Срок исполнения». По-моему, он действительно лишает команду (в том числе и самого ПМ гибкости). Вот я приступил к задаче, проставил срок исполнения, в процессе появились более приоритетные задачи, я отвлёкся на них, соответственно срок исполнения первой задачи съехал, надо исправить. В итоге можно закопаться в этих сроках (при этом особых задач они не решают, к тому же могут ещё и навредить, как менеджеру, так и разработчику)
PS — А инструмент отчётности, про который вы говорите — он лишний. Что я сделал и сколько было потрачено — всё это программист «пишет» автоматически в процессе работы — делая коммиты в SVN, указывая в комментах id тикета в JIRA). Вы научите менеджера «читать» такие отчёты — ему 100% понравится :)
JIRA же худо-бедно уже встроена в ваш процесс, так я не вижу причин почему бы не расширить её функционал — пускай она выступает инструментом отчётности для менеджера, а не только issue-трекером.
Теперь по пунктам:
1. Версии — это вообще основа основ итерационного метода разработки. Благодаря версии становится понятно, а что же мы такого релизнули в пятницу (тестировщики видят, что тестить). Благодаря версии становится понятно в какой версии тестировщики нашли баг. Благодаря версии менеджер ставит приоритеты — в какой версии, что нужно делать (это нужно срочно, это подождёт пару недель, этим вообще надо заниматься только когда багов не будет). И всё это вы получаете ровно за 1 клик (!) при создании и закрытии тикета.
2. Сабтаски нужны затем, что не всегда менеджер и тестировщик могут определить границы ответственности. Но задача есть и её нужно решить. Разработчик, которому назначен таск, видит несправедливость — в задаче есть пункты, которые вообще не в его компетенции — так он создаёт сабтаск и назначает его на нужного человека.
3. Компоненты нужны для быстрого ориентирования в проблемах. Тестировщик указывает в задаче компонент, в котором он нашёл баг (ровно 1 клик). Программист с одного взгляда на список тикетов понимает про что этот баг, потому что там указан компонент. Менеджер знает приоритеты по компонентам, а также может определить проблемные компоненты (в каком-то слишком много багов — может стоит поручить техлиду сделать ревью, вместо того чтобы программисты делали локальные фиксы? а какой-то компонент может недостаточно широко тестируется (слишком мало заведено тикетов)).
4. Estimated time каждой задачи нужен для общей оценки проекта. Пускай каждый проставит время (пусть и оторванное от реальности) для своих задач, но у менеджера появится инструмент: для отслеживания общего срока проекта, для выбивания больших ресурсов из директора (оперируем в понятных директору человекочасах), для оценки количества работ по компонентам, для оценки количества работ по версиям (ежу понятно, что если на текущую версию требуется 100 человекочасов, у меня 5 человек, а релиз версии — послезавтра, то всё мы не успеем, что-то (что не было обещано заказчику к этой пятнице) надо перенести на следующую версию)
Единственное, что мне не нравится в письме вашего ПМ, так это «Срок исполнения». По-моему, он действительно лишает команду (в том числе и самого ПМ гибкости). Вот я приступил к задаче, проставил срок исполнения, в процессе появились более приоритетные задачи, я отвлёкся на них, соответственно срок исполнения первой задачи съехал, надо исправить. В итоге можно закопаться в этих сроках (при этом особых задач они не решают, к тому же могут ещё и навредить, как менеджеру, так и разработчику)
PS — А инструмент отчётности, про который вы говорите — он лишний. Что я сделал и сколько было потрачено — всё это программист «пишет» автоматически в процессе работы — делая коммиты в SVN, указывая в комментах id тикета в JIRA). Вы научите менеджера «читать» такие отчёты — ему 100% понравится :)
Про свн насамо деле верно, но многие программеры не пишут внятных комментов. Многие комитятся раз в неделю. Это неправильно, но кто должен решать эти вопросы? Я. Хрен там, у меня других задач погорло. ПМ? Да он в этом не разбирается, а любое преложение откладывается в долгий ящик. Может вот техдир таки введет такую практику.
По поводу отчетности. Например в РБК она используется для оценки капитализации компании для аудиторов. Без них никак. Но я совсем не настаиваю на такой системе. Она предложена лишь как некий компромис. Гораздо проще потратить 10-15 мин в конце дня, чем отвлекаться 10 раз за день на минутные вопросы. И чтоб не засерали JIRA.
В целом то что вы написали, это верно и я не спорю. И про версии и про сабтаски. Но все это должно быть не так как. Все это должно автоматически выходить из процесса а не навязываться свыше в отрыве от других практик. И я ппротив что бы этим засерали JIRA
По поводу отчетности. Например в РБК она используется для оценки капитализации компании для аудиторов. Без них никак. Но я совсем не настаиваю на такой системе. Она предложена лишь как некий компромис. Гораздо проще потратить 10-15 мин в конце дня, чем отвлекаться 10 раз за день на минутные вопросы. И чтоб не засерали JIRA.
В целом то что вы написали, это верно и я не спорю. И про версии и про сабтаски. Но все это должно быть не так как. Все это должно автоматически выходить из процесса а не навязываться свыше в отрыве от других практик. И я ппротив что бы этим засерали JIRA
Описываю отлаженный процесс:
1. разработчик пришёл на работу (предположим, что задач в прогрессе у него нет)
2. открыл JIRA — список заданий «что делать сейчас» (фильтр задач, у которых fix version стоит — «ближайший релиз»
3. выбрал по приоритету первейший таск. нажал галочку: in progress
4. локализовал баг
5. исправил
6. сделал первичные тесты
7. закоммитил (страница в jira с текущим багом открыта — в ней много полезной сопутствующей информации по задаче) — соответственно посмотреть id таска не составляет труда. в коммент вместо «я пофиксил валидацию формы Б, теперь, если пользователь оставит поле А пустым, ему выдадут ошибку В», он пишет: «PRJ-1537» (этот PRJ-1537 в просмотрщике логов автоматически линкуется на страницу в JIRA)
8. зарезолвил таск в JIRA (кликает на fixed и проверяет, что fix version действительно стоит на текущем релизе)
9. переходит в список задач и выбирает следующий таск по приоритету
Если задачи занимают значительное время и их нельзя закоммитить в тот же день, то во-первых, стоит подумать — а не завести ли ветку в svn и разбить эту задачу на несколько подзадач? Если ответ — нет. То задача просто остаётся In progress на следующий день работы. Программист приходит на следующий день и выбирает её. (страница опять оказывается открытой и забить айди в комментарий не составляет труда).
Если у вас нет культуры таких коммитов — «сделал/пофиксил единицу смысла — сделай коммит», то это плохая практика. В итоге никто ничего реально не контролирует и разобраться «а что вообще происходит и кто чем занимается?» — малореально.
PS — «потратить 10-15 мин в конце дня» — это только на словах легко. А когда просидел над проектом 8-10 часов и мысли уже дома на диване поедают китайскую лапшу и смотрят свежескачанный торрент, то на всю эту «непринуждённую» процедуру мысли забьют, а мозгу на вопрос «какого х?» ответят: «да завтра с утра первым делом отпишем, ничё страшного».
1. разработчик пришёл на работу (предположим, что задач в прогрессе у него нет)
2. открыл JIRA — список заданий «что делать сейчас» (фильтр задач, у которых fix version стоит — «ближайший релиз»
3. выбрал по приоритету первейший таск. нажал галочку: in progress
4. локализовал баг
5. исправил
6. сделал первичные тесты
7. закоммитил (страница в jira с текущим багом открыта — в ней много полезной сопутствующей информации по задаче) — соответственно посмотреть id таска не составляет труда. в коммент вместо «я пофиксил валидацию формы Б, теперь, если пользователь оставит поле А пустым, ему выдадут ошибку В», он пишет: «PRJ-1537» (этот PRJ-1537 в просмотрщике логов автоматически линкуется на страницу в JIRA)
8. зарезолвил таск в JIRA (кликает на fixed и проверяет, что fix version действительно стоит на текущем релизе)
9. переходит в список задач и выбирает следующий таск по приоритету
Если задачи занимают значительное время и их нельзя закоммитить в тот же день, то во-первых, стоит подумать — а не завести ли ветку в svn и разбить эту задачу на несколько подзадач? Если ответ — нет. То задача просто остаётся In progress на следующий день работы. Программист приходит на следующий день и выбирает её. (страница опять оказывается открытой и забить айди в комментарий не составляет труда).
Если у вас нет культуры таких коммитов — «сделал/пофиксил единицу смысла — сделай коммит», то это плохая практика. В итоге никто ничего реально не контролирует и разобраться «а что вообще происходит и кто чем занимается?» — малореально.
PS — «потратить 10-15 мин в конце дня» — это только на словах легко. А когда просидел над проектом 8-10 часов и мысли уже дома на диване поедают китайскую лапшу и смотрят свежескачанный торрент, то на всю эту «непринуждённую» процедуру мысли забьют, а мозгу на вопрос «какого х?» ответят: «да завтра с утра первым делом отпишем, ничё страшного».
Можно и с утра.
Можно и с вечера, и с утра, и каждый час, и после обеда, и каждую пятницу. Разумеется, можно. Только зачем?
Ваша процедура «оформления отчётности» — оторвана от рабочего процесса. В моём варианте — она вшита в процесс.
Сразу скажу, что процедура «что делал — сколько времени» — есть и в фирме, где я работаю. Но нужна она не ПМ, а бухгалтерам — для расчёта переработок и отгулов (как вы знаете, эта информация влияет на размер заработной платы, а с деньгами никто шутить не будет — поэтому процедура «навязана сверху»). Но «отчёт» выглядит так: «эту неделю я работал 40 часов в проекте X» или «30 часов в проекте X, 5 часов в проекте Y, ещё 5 часов — обучение». Менеджеры проектов кивают бухгалтерам — да действительно столько часов. А бухгалтерам нужно только кол-во часов, какие задачи ты выполнял — им параллельно.
Ваша процедура «оформления отчётности» — оторвана от рабочего процесса. В моём варианте — она вшита в процесс.
Сразу скажу, что процедура «что делал — сколько времени» — есть и в фирме, где я работаю. Но нужна она не ПМ, а бухгалтерам — для расчёта переработок и отгулов (как вы знаете, эта информация влияет на размер заработной платы, а с деньгами никто шутить не будет — поэтому процедура «навязана сверху»). Но «отчёт» выглядит так: «эту неделю я работал 40 часов в проекте X» или «30 часов в проекте X, 5 часов в проекте Y, ещё 5 часов — обучение». Менеджеры проектов кивают бухгалтерам — да действительно столько часов. А бухгалтерам нужно только кол-во часов, какие задачи ты выполнял — им параллельно.
Я уже сказал что отчеты не насущная необходимость но варианты с JIRA и SVN ще хуже. В принципе можно легко обойтись и без всех трех, но отчеты это как компромисс, не более.
JIRA у меня не открыта постоянно, я прекрасно знаю что от меня требуют, потому что всегда обсуждаю задачу с ПМ-ом, читать мне её нет смысла. JIRA только как напоминалка, что бы не забыть список своих задач.
JIRA у меня не открыта постоянно, я прекрасно знаю что от меня требуют, потому что всегда обсуждаю задачу с ПМ-ом, читать мне её нет смысла. JIRA только как напоминалка, что бы не забыть список своих задач.
Значит вы используете инструмент не по назначению, только и всего.
Если я всю жизнь забиваю гвозди топором, а потом мне говорят — теперь им ещё и дрова надо рубить, то это вызовет справедливое возмущение с моей стороны (потому что мне покажется, что на меня вешают лишнюю работу).
Если я всю жизнь забиваю гвозди топором, а потом мне говорят — теперь им ещё и дрова надо рубить, то это вызовет справедливое возмущение с моей стороны (потому что мне покажется, что на меня вешают лишнюю работу).
А вы MS Office используете на всю катушку?
Я использую его по назначению. Оформляю документы (оочень редко) и читаю корпоративную почту.
Использовать по назначению и использовать на полную катушку — разные вещи, согласитесь.
Использовать по назначению и использовать на полную катушку — разные вещи, согласитесь.
Разные, согласен, а я что через JIRA в интернет хожу или почту проверяю? Нет, она используется для постановке задач, как нормальный трекер. То для чего она предназначена как раз. Между прочим думаю со временем мы перейдем на другой трекер, возможно Track или eTraxis и что делать?
> JIRA только как напоминалка, что бы не забыть список своих задач.
это ваши слова.
> она используется для постановке задач, как нормальный трекер
Так почему в вашем трекере нельзя отследить версии, компоненты, сабтаски и estimated time? нормальный ли это трекер? нет.
это ваши слова.
> она используется для постановке задач, как нормальный трекер
Так почему в вашем трекере нельзя отследить версии, компоненты, сабтаски и estimated time? нормальный ли это трекер? нет.
наверное можно. Но в нормальном процессе версия планируется зарание как набор фич которые нужно реализовать в определенную дату. Дата пришла, сделали билд, в свне поставили метку с номером версии. Причем тут JIRA?
Есть major релизы, есть minor релизы.
Major — это то, что вы описали.
Minor — это снэпшоты на какую-то дату.
Есть хорошая практика — каждую пятницу релизить minor (например, чтобы заказчику показать, что процесс идёт, и то, что он сказал срочно пофиксить в понедельник было исправлено. Даже если конкретного заказчика нет — то всё равно введите такую практику — это дисциплинирует команду). JIRA помогает отследить какие таски были сделаны в каком minor-е.
Также есть ситуации, когда версии делаются параллельно — например, мы зарелизили 3.0, продолжаем поддерживать 2.0.x и уже разрабатываем 3.1.x. JIRA помогает отслеживать какие задачи к какой версии относятся. У ПМ повляется возможность распределения ресурсов — например, сказать разработчику: «закрой всё что есть по 2.0.х и приступай к 3.1.x). А также возможность приоритетов задач — был обнаружен баг в 2.0.x, он не очень серьёзный (но неприятный), но займёт много времени — менеджер может перевести его сразу в 3.1.x, + задача копируется в known issues для 2.0.x
Major — это то, что вы описали.
Minor — это снэпшоты на какую-то дату.
Есть хорошая практика — каждую пятницу релизить minor (например, чтобы заказчику показать, что процесс идёт, и то, что он сказал срочно пофиксить в понедельник было исправлено. Даже если конкретного заказчика нет — то всё равно введите такую практику — это дисциплинирует команду). JIRA помогает отследить какие таски были сделаны в каком minor-е.
Также есть ситуации, когда версии делаются параллельно — например, мы зарелизили 3.0, продолжаем поддерживать 2.0.x и уже разрабатываем 3.1.x. JIRA помогает отслеживать какие задачи к какой версии относятся. У ПМ повляется возможность распределения ресурсов — например, сказать разработчику: «закрой всё что есть по 2.0.х и приступай к 3.1.x). А также возможность приоритетов задач — был обнаружен баг в 2.0.x, он не очень серьёзный (но неприятный), но займёт много времени — менеджер может перевести его сразу в 3.1.x, + задача копируется в known issues для 2.0.x
Кстати, вот вы написали в исходном посте, что когда фиксите баг, то «переводите его в проверку» JIRA, а значит сейчас говорите неправду, что очень трудно лезть в JIRA и смотреть айдишник.
И ещё одна заметку походу: правильное использование JIRA избавляет от необходимости обсуждать каждую задачу с ПМ-ом. Экономит кучу времени — проверено. С ПМ-ом надо обсуждать фичи, которые имплементятся задачами, но не сами задачи. А новые фичи возникают в проекте гораздо реже задач.
И ещё одна заметку походу: правильное использование JIRA избавляет от необходимости обсуждать каждую задачу с ПМ-ом. Экономит кучу времени — проверено. С ПМ-ом надо обсуждать фичи, которые имплементятся задачами, но не сами задачи. А новые фичи возникают в проекте гораздо реже задач.
конечно же открываю что бы перевести задачу. Но делаю это после комита. Консоль всегда открыта, закомитил, потом потестил, потом открыл JIRA и перевел задачу.
Да, использование JIRA избавляет от необходимости общения, но именно с этим я и борюсь. Общение необходимо. Все задачи все сроки должны назначаться в ходе личного общения а не через JIRA
Да, использование JIRA избавляет от необходимости общения, но именно с этим я и борюсь. Общение необходимо. Все задачи все сроки должны назначаться в ходе личного общения а не через JIRA
1) Представьте, что ПМ уехал в заграничную командировку — встречаться с клиентом — работа разработчиков встанет, общаться-то не с кем.
2) Хороший ПМ ведёт сразу несколько проектов — во всех них общаться по срокам и задачам — да вы что. У него мозг взорвётся от такого общения.
3) Все эти общения-собрания-совещания — это как раз никому не нужная бюрократия. У вас процесс превратится в общение. За это боретесь?
2) Хороший ПМ ведёт сразу несколько проектов — во всех них общаться по срокам и задачам — да вы что. У него мозг взорвётся от такого общения.
3) Все эти общения-собрания-совещания — это как раз никому не нужная бюрократия. У вас процесс превратится в общение. За это боретесь?
1. Кто его туда отпусти. В любом случае будет заместитель
2. А надо! Впрочем у нас проект пока один. Видимо мы о раазных маштабах речь ведем. У нас не маштаб сайта визитки когда один ПМ может таких 10 вести.
3. Ну это ваше мнение. Возможно оно от недостатка знаний и опыта. Не буду вас переубеждать, не получится.
2. А надо! Впрочем у нас проект пока один. Видимо мы о раазных маштабах речь ведем. У нас не маштаб сайта визитки когда один ПМ может таких 10 вести.
3. Ну это ваше мнение. Возможно оно от недостатка знаний и опыта. Не буду вас переубеждать, не получится.
1. Как вы себе представляете — вот приходит заместитель — ему надо войти в курс дела, а у вас в трекере — ноль информации? Общаться будете?
2. Я тоже не говорю о сайтах-визитках. Какого масштаба у вас проект? Хотя бы сколько человек в нём трудятся? Вы же понимаете, что чем больше человек, тем труднее менеджеру проговаривать задачи и ставить сроки КАЖДОМУ сотруднику?
3. Это у вас недостаток совещаний сейчас. Очень вам хочется пообщаться. Когда всё плохо — «первое желание собраться всем вместе и поговорить». Не спорю, что вашей фирме сейчас совещания необходимы — чтобы наладить процесс (потому что, то что вы сейчас описываете иначе как полной ж* не назовёшь). Но совещания на тему, сколько времени займёт выполнить задачу — это бюрократия, лишняя болтовня. Зачем вообще нужны сроки? По-моему вы так и не поняли из моего первого коммента.
2. Я тоже не говорю о сайтах-визитках. Какого масштаба у вас проект? Хотя бы сколько человек в нём трудятся? Вы же понимаете, что чем больше человек, тем труднее менеджеру проговаривать задачи и ставить сроки КАЖДОМУ сотруднику?
3. Это у вас недостаток совещаний сейчас. Очень вам хочется пообщаться. Когда всё плохо — «первое желание собраться всем вместе и поговорить». Не спорю, что вашей фирме сейчас совещания необходимы — чтобы наладить процесс (потому что, то что вы сейчас описываете иначе как полной ж* не назовёшь). Но совещания на тему, сколько времени займёт выполнить задачу — это бюрократия, лишняя болтовня. Зачем вообще нужны сроки? По-моему вы так и не поняли из моего первого коммента.
1. Ведущий программист или техдир, которые в курсе всего полюбому. Потом никто не отрицает что у ПМ-а должна быть своя документация по проекту, например в wiki. А вот в JIRA точно разобраться толком не сможешь. Лучше глянуть в общий план где есть вся нужная информация, кто-что и сколько должен делать и на какой стадии находится.
2. Проект уровня ну скажем однокласников. В проекте 9 человек. Но вы наверное опять не поняли. Может вам все таки почитать соответствующую литературу что бы быть в теме, а том мы горим об одном а представляем себе все поразомну. Честное слово такое чувство что вы просто думаете что разбираетесь в вопросе а на самом деле нет. Ничего личного.
3. см. выше. Прочтите про Скрам, XP, Agile, и книги «Мифический человеко/месяц», «Человеческий фактор», «Джоел о программировании», Раздел посвященный планированию в книге Роберта Мартина «Быстрая разработка программ» и особенно пример игры в планирование в конце книги. Ну это для начала. Тогда сможем пообщаться более предметно.
2. Проект уровня ну скажем однокласников. В проекте 9 человек. Но вы наверное опять не поняли. Может вам все таки почитать соответствующую литературу что бы быть в теме, а том мы горим об одном а представляем себе все поразомну. Честное слово такое чувство что вы просто думаете что разбираетесь в вопросе а на самом деле нет. Ничего личного.
3. см. выше. Прочтите про Скрам, XP, Agile, и книги «Мифический человеко/месяц», «Человеческий фактор», «Джоел о программировании», Раздел посвященный планированию в книге Роберта Мартина «Быстрая разработка программ» и особенно пример игры в планирование в конце книги. Ну это для начала. Тогда сможем пообщаться более предметно.
1. Я про любую систему могу сказать, что в ней толком разобраться не сможешь. Придёт новый менеджер и скажет: «WIKI — фигня, я буду юзать блокнот. Он меня никогда не подводил». Что ему скажете?
2. А вы к чему вообще этот пост написали? Вы спросили — «а зачем всю эту фигню менеджер придумал? кто-нибудть это успешно применяет? не хочет ли он нас всех в кювет отправить?». Я ответил — «да применяем, очень успешно». А теперь вы пытаетесь меня убедить, что я не прав? Я работаю в большом проекте (разработка — больше года), команда — 15 человек. Мы укладываемся в сроки, разработчики довольны менеджером, менеджер доволен командой. У вас — всё в точности наоборот. И теперь вы заявляете, что я ничего не понимаю? )) просто смешно звучит.
3. Зачем мне это читать? Вы вот прочли, а проект у вас разваливается. Мало читать — надо ещё делать. Менеджер ваш написал умные вещи (и хотя бы пытается что-то исправить) — вы в ответ: «я вот в книжках читал, это всё фигня, давайте общаться». Что конкретного предложите-то?
2. А вы к чему вообще этот пост написали? Вы спросили — «а зачем всю эту фигню менеджер придумал? кто-нибудть это успешно применяет? не хочет ли он нас всех в кювет отправить?». Я ответил — «да применяем, очень успешно». А теперь вы пытаетесь меня убедить, что я не прав? Я работаю в большом проекте (разработка — больше года), команда — 15 человек. Мы укладываемся в сроки, разработчики довольны менеджером, менеджер доволен командой. У вас — всё в точности наоборот. И теперь вы заявляете, что я ничего не понимаю? )) просто смешно звучит.
3. Зачем мне это читать? Вы вот прочли, а проект у вас разваливается. Мало читать — надо ещё делать. Менеджер ваш написал умные вещи (и хотя бы пытается что-то исправить) — вы в ответ: «я вот в книжках читал, это всё фигня, давайте общаться». Что конкретного предложите-то?
>Зачем мне это читать?
Ну после такого ответа больше вопросов не имеется)))
Ну после такого ответа больше вопросов не имеется)))
Эх, кончились аргументы у вас. А жаль — действительно интересная дискуссия за долгое время на хабре.
То что вы прочли эти книги — ещё не значит, что вы не стали умнее человека, который прочёл другие книги.
То что вы прочли эти книги — ещё не значит, что вы не стали умнее человека, который прочёл другие книги.
Дело не в этом. Аргументов полно но для того что бы был хотя бы мизерный шанс что вы их поймете и примете мне придется вам прочитать лекции часов на 10, вводный курс. Если бы аргументами было бы так просто убедить человека в правильности той или иной методики, никто бы книги не писал. Согласны? Так какой смысл мне продолжать дискуссию, если шансов вас убедить у меня нет. Это все равно что повар ресторана будет убеждать человека никогда не ходившего в рестораны в том, что он готовит вкуснее чем повар в его заводской столовой. Пока не попробует убедить невозможно.
Ну так сначала напишите ваши аргументы. Потом разберёмся — пойму или нет. Если что-то зацепит в вашей концепции — то разберусь и почитаю. Пока что у вас сплошное отрицание. А сплошному отрицанию сложно поверить.
А смысл есть хотя бы в том — что вам ещё вашего ПМ надо убеждать в своей правоте. И директора. Вы же их не пошлёте книжки читать? Даже если пошлёте — они просто посмеются так, по-доброму. Так что придётся обойтись без лекций на 10 часов.
А смысл есть хотя бы в том — что вам ещё вашего ПМ надо убеждать в своей правоте. И директора. Вы же их не пошлёте книжки читать? Даже если пошлёте — они просто посмеются так, по-доброму. Так что придётся обойтись без лекций на 10 часов.
Ну если техдир не читал книг по этой теме и не разбирается в вопросе то наверное и убеждать не буду. Какого черта он тогда пытается ввести методику, даже не имея понятия о других альтернативах. К сожалению мои аргументы не помогут. ПМ-а тоже убеждать не буду, так как даже если он прочтет книги он ничего не поймет. Аргументы пытался приводить но он не понимает их.
Поверьте, я бы с радостью попытался вас убедить, но тема и правда настолько сложная что в одном комменте не охватишь, надо ну хотя бы страничек 10 это что бы описать в крации все практики, и проанализировать все аспекты их применения. Некоторые из них касаются непосредственно психологии разработчиков. Ну никак я в двух слова не расскажу.
Поверьте, я бы с радостью попытался вас убедить, но тема и правда настолько сложная что в одном комменте не охватишь, надо ну хотя бы страничек 10 это что бы описать в крации все практики, и проанализировать все аспекты их применения. Некоторые из них касаются непосредственно психологии разработчиков. Ну никак я в двух слова не расскажу.
А что такого сакрального происходит между коммитом и открытием JIRA, что нельзя поменять эти две атомарные задачи местами? На пустом месте проблемы выдумываете. Только потому что вы так привыкли — никак не должно заботить менеджера.
Вы как часто делаете комиты? 1 раз в конце задачи? А я за задачу могу сделать их много, и часто даже понятия не имею какой из них является последним по задаче.
1. сабтаски (нелюбимые вами)
2. ключевые слова (сделал коммит, но нет резолва тикета — напиши «partial PRJ-1235» (да-да, Jira открыть придётся — иначе как понять, решает ли коммит таск полностью или нет?)
3. неимение понятия — это как раз от неверного использования инструментов
2. ключевые слова (сделал коммит, но нет резолва тикета — напиши «partial PRJ-1235» (да-да, Jira открыть придётся — иначе как понять, решает ли коммит таск полностью или нет?)
3. неимение понятия — это как раз от неверного использования инструментов
1. А я не делю никак. Хочу комичу хочу нет. Даже после реинтегрейта в транк могу еще несколько раз комитить если вдруг есть рефакторинг, или баги нашел.
2. Ключевое слово здесь я не хочу думать ни о чем кроме задачи.
3. это от того что я и не хочу знать когда задача будет завершена. я комичусть инстинктивно, например перед тем как пойти курить или перед уходом домой или просто потому что мне кажется что давно не комитился. Это просто часть рабочего процесса.
2. Ключевое слово здесь я не хочу думать ни о чем кроме задачи.
3. это от того что я и не хочу знать когда задача будет завершена. я комичусть инстинктивно, например перед тем как пойти курить или перед уходом домой или просто потому что мне кажется что давно не комитился. Это просто часть рабочего процесса.
Т.е. то что ваш коммит может поломать транк и пока вы там курите или дома сидите, все должны курить — вас не должно заботить?
может, но если тесты прошли значит шансы поломать небольшие, тем более у меня и своя голова есть, я знаю что можно комитит а что пока не стоит.
Что-то я читаю-читаю… и мне за вашу фирму всё беспокойнее и беспокойнее…
Честно скажу, будт я вашим лидом, руки бы оторвал затакие «инстинктивные» коммиты.
Просто нет слов на самом деле. Так нельзя.
Ну что это за «я и не хочу знать когда задача будет завершена»? Это превращаете SVN в помойкукакую то. Вот 7 человек работают над проектом… и каждый и них делает коммит и идёт отлить. При этом никто апдейт не делает и не видит что уже навалилось в транк. Идут часто все человека по 3, покурить поговорить.
За разговором выясняется что работали с одними и теми же файлами и конфликт не избежен. Возвращаются, а там ещё несколько чеовек что-то закоммитили, причём комментариев никто естественно не пишет.
Скажите сколько вы будете разрешать коллизии? Неделю? Месяц? Полгода? Отложите на потом.
Что в результате? У каждого будет какая-то сборная локальная версия, да, возможно рабочая. Но взять это потом и смержить… 7 веток, причём с кучами мелких ответвлений?
Честно скажу, будт я вашим лидом, руки бы оторвал затакие «инстинктивные» коммиты.
Просто нет слов на самом деле. Так нельзя.
Ну что это за «я и не хочу знать когда задача будет завершена»? Это превращаете SVN в помойкукакую то. Вот 7 человек работают над проектом… и каждый и них делает коммит и идёт отлить. При этом никто апдейт не делает и не видит что уже навалилось в транк. Идут часто все человека по 3, покурить поговорить.
За разговором выясняется что работали с одними и теми же файлами и конфликт не избежен. Возвращаются, а там ещё несколько чеовек что-то закоммитили, причём комментариев никто естественно не пишет.
Скажите сколько вы будете разрешать коллизии? Неделю? Месяц? Полгода? Отложите на потом.
Что в результате? У каждого будет какая-то сборная локальная версия, да, возможно рабочая. Но взять это потом и смержить… 7 веток, причём с кучами мелких ответвлений?
Не переживайте. Апдейтится тожа надо часто, а кто не апдейтится сам дурак. У нас все нормально, и такой стиль разработки работает отлично, конфликты редкость, и проблемы не создают. Комменты я пишу, а за другими следить не моя задача. Хотя конечно стараюсь внушение делать. За ветки тоже не волнуйтесь. Всем объяснено что мержить себе в ветку надо почаще, а кто опять таки не мержит тот сам дурак.
Да у вас всё просто отлично. Сроки сорваны правда к чертям.
причем тут svn, можно подробнее?
Неправильное использование инструментов, отсутствие понимания того что вообще происходит с проектом. Каждый из вас судя по всему живёт в своей «ветке» и нифига не хочет думать об остальных
речь вроде об одном инструменте — svn. Уточните как конкретно неправильное по вашему мнению использование этого конкретного инструмента влияет на сроки.
Насчет догадок вы не правы. У нас ветки создаются на большие задачи длительностью более 1 дня и удаляются сразу по завершении. На данный момент в хеаде две ветки.
Насчет догадок вы не правы. У нас ветки создаются на большие задачи длительностью более 1 дня и удаляются сразу по завершении. На данный момент в хеаде две ветки.
Больше коммитов, больше апдейтов, отсутствует контроль за версиями, не понимание что сделано и что надо делать, что сделано за неделю и кем.
Всего этого вам не хватает и вы хотите «общаться». В результате этого постоянного общения и пролетаете по срокам.
Всего этого вам не хватает и вы хотите «общаться». В результате этого постоянного общения и пролетаете по срокам.
Если вы не знает то есть такой принцип работы с svn при котором комитятся и апдейтятся часто. Это позволяет как раз таки избегать конфликтов. Это очень распространенная а не мной придуманная практика. Если вы о ней не знаете, то учитесь лучше, потому что ваше замечание выглядит очень странно. Все что ниже я не понял как относится к svn
уважаемый, вы наркоман штоле?
как это относится к нашей дисскуссии?
Безответственность перед собой и окружающими объединяет таких людей как вы и наркоманов… и часто превращает первых во вторых, к сожалению.
вы просто ничего не поняли. обьясняю вам подробно. если есть желание понять, то подумайте над этим. если нет, то дальше не читайте, все равно не поймете.
Итак. В чем приемущество частых апдэйтов и комитов. В том что локальные копии остаются примерно одинаковыми и далеко не расходятся. Таким образом шанс конфликтов снижается. И конфликты разруливать гораздо проще.
Кстати, если вы не знаете то конфликт, это не ошибка, это нормальное явление для svn. Потому что svn это система основанная на конфликтах, и конфликт это то что является неотемлимой частью свн.
Но если локальные версии слишком сильно разойдутся, то часто конфликты разрулить будет сложно а иногда практически невозможно. Поэтому для того что бы не создавать проблем другим, комитя результаты недельной работы, комитить нужно чаще, несколько раз в день, что бы они вовремя могли получить ваши изменения.
Простой пример:
Вася и Петя работают над одним проектом. Допутим они комитятся редко. Итак Вася правит некий файл, но не комитит. Петя апдейтится, но не получает правок Васи. На следующий день Петя правит тот же файл в том же месте. Теперь можно принимать ставки кто из них получит конфликт. В любом случае тот кто первый проапдейтится.
А теперь допустим что они комитятся часто. Вася правит файл и сразу его комитит. Петя апдейтится часто, поэтому сразу получает изменения Васи. На следующий день он правит тот же файл и тут же его комитит. Никто конфликт не получит.
Конечно не надо доводить до фанатизма, и не комитить каждые 5 минут. Нормально комитить более или мение завершенные части системы, конечно если это не нарушает работоспособности кода. Обычно комититится нужно 2-5 раз за день в зависимости от задачи. Это на порядок снижает вероятность конфликтов. У нас они редкость.
А вы называетете меня безответвенным.
Итак. В чем приемущество частых апдэйтов и комитов. В том что локальные копии остаются примерно одинаковыми и далеко не расходятся. Таким образом шанс конфликтов снижается. И конфликты разруливать гораздо проще.
Кстати, если вы не знаете то конфликт, это не ошибка, это нормальное явление для svn. Потому что svn это система основанная на конфликтах, и конфликт это то что является неотемлимой частью свн.
Но если локальные версии слишком сильно разойдутся, то часто конфликты разрулить будет сложно а иногда практически невозможно. Поэтому для того что бы не создавать проблем другим, комитя результаты недельной работы, комитить нужно чаще, несколько раз в день, что бы они вовремя могли получить ваши изменения.
Простой пример:
Вася и Петя работают над одним проектом. Допутим они комитятся редко. Итак Вася правит некий файл, но не комитит. Петя апдейтится, но не получает правок Васи. На следующий день Петя правит тот же файл в том же месте. Теперь можно принимать ставки кто из них получит конфликт. В любом случае тот кто первый проапдейтится.
А теперь допустим что они комитятся часто. Вася правит файл и сразу его комитит. Петя апдейтится часто, поэтому сразу получает изменения Васи. На следующий день он правит тот же файл и тут же его комитит. Никто конфликт не получит.
Конечно не надо доводить до фанатизма, и не комитить каждые 5 минут. Нормально комитить более или мение завершенные части системы, конечно если это не нарушает работоспособности кода. Обычно комититится нужно 2-5 раз за день в зависимости от задачи. Это на порядок снижает вероятность конфликтов. У нас они редкость.
А вы называетете меня безответвенным.
А вы хорошо научились трепаться языком, я даже понимаю с какой целью вам это на работе надо.
Про Петю и Васю напрасно вы, я прекрасно понимаю какие преимущества вам это даёт, уже не говоря о том, что я понимаю и что такое конфликт.
На вашу историю имею ответ следующего содержания:
Ребята из Вилларибо апдейтятся каждые полчаса, и коммитятся когда организм не выдержит, а ребята из Виллабаджо грамотно распределяют файлы по версиям и трогают только свою часть транка и ветки, используя svn как систему контроля за версиями, а не как файлообменник.
Про Петю и Васю напрасно вы, я прекрасно понимаю какие преимущества вам это даёт, уже не говоря о том, что я понимаю и что такое конфликт.
На вашу историю имею ответ следующего содержания:
Ребята из Вилларибо апдейтятся каждые полчаса, и коммитятся когда организм не выдержит, а ребята из Виллабаджо грамотно распределяют файлы по версиям и трогают только свою часть транка и ветки, используя svn как систему контроля за версиями, а не как файлообменник.
но не стоит принимать мои слова как полное неприятие этой практики. надо с этим подробнее разобраться. мне просто кажется что при политике частых комитов это применть сложно, в отличии от случаев когда в транк попадают только проверенные вещи, и есть человек за всем этим следящий. как в различных опенсорс проектах. Воопщем допускаю что я не прав, но пока не убежден, хотя заинтересован. Я, будет время, проанализирую преимущества такой практики.
«Консоль всегда открыта, закомитил, потом потестил»
А что разрешается непротестированный код комитить???! Как же команда работает? Кто-то комитнул кривой код, другие апдейтнулись и начали дружно кричать матом с утричка=)
А что разрешается непротестированный код комитить???! Как же команда работает? Кто-то комитнул кривой код, другие апдейтнулись и начали дружно кричать матом с утричка=)
Если это новый класс или новый раздел сервиса, то почему бы и нет? Я комичу на основе тестов. Сработали, значит все ок и можно комитить. Что в этом такого плохого?
забаная ситуация, подавлющее число людей вам говорят ваши ошибки, а вы все пытаетесь отмазаться. дело ваше.
только что была ситуация. вроде бы проверил, работает. закомитил код. выгрузили на тестовый сервер, ошибка. Посмотрел логи, нашел ошибку, исправил, проверил что исправлено — закомитил. Нашел еще одну, пришлось менять логику, добавлять поле в БД… И теперь вопрос, как же так я такой падлец комитил 3 раза нерабочий код! Не надо было?
НЛО прилетело и опубликовало эту надпись здесь
а третьего не дано?
наверное сообщение стоило бы построить немного подругому, с использованием слова «может» вместо «либо»
можно вопрос, вы тесты пишете?
наверное сообщение стоило бы построить немного подругому, с использованием слова «может» вместо «либо»
можно вопрос, вы тесты пишете?
НЛО прилетело и опубликовало эту надпись здесь
Не в обиду но если вы оправдываете то что не пишете тесты ДО кода потому что не удается спроектировать то вы не понимаете для чего нужны тесты. Полное покрытие это только 1 причина из трех основных.
А баги возникать могут еще по причине
1. Недопонял задачу
2. Тестовая структура БД отличается от реальной
3. Ошибка в интерфейсе
4. Ошибка в функциональной логике а не программной
5. Не полное покрытие тестами
6. Несоответствие реального окружения тестовому
В моем случае была банальная невнимательность, неверно сформированный URL, что относится к причине #3, а второй раз из за того что тесты невзаимосвязанны (это так и должно быть), поэтому ошибка не всплыла, Я просто случайно записывал данные в поле, необходимое для другого. Мой код херил данные другого модуля.
А баги возникать могут еще по причине
1. Недопонял задачу
2. Тестовая структура БД отличается от реальной
3. Ошибка в интерфейсе
4. Ошибка в функциональной логике а не программной
5. Не полное покрытие тестами
6. Несоответствие реального окружения тестовому
В моем случае была банальная невнимательность, неверно сформированный URL, что относится к причине #3, а второй раз из за того что тесты невзаимосвязанны (это так и должно быть), поэтому ошибка не всплыла, Я просто случайно записывал данные в поле, необходимое для другого. Мой код херил данные другого модуля.
НЛО прилетело и опубликовало эту надпись здесь
ну изолировать то модули можно а вот как изолировать от них базу? все таки БД это общий ресурс, и любому классу позволенно юзать любую таблицу. вот и получилось по невнимательности, что я писал в поле, которое предназначенно для другого. но это все рабочие моменты, ничего страшного.
кстати подобных ошибок помогают избежать функциональные тесты, которые по хорошему должны писаться тестерами или заказчиком. но у нас даже тестеров нет какие уж тут тесты.
кстати подобных ошибок помогают избежать функциональные тесты, которые по хорошему должны писаться тестерами или заказчиком. но у нас даже тестеров нет какие уж тут тесты.
Пр свн немного не согласен. Никто не будет проставлять ID тикета в комменте. Это еще одно навязывание лишнего артефакта, лишней мелочной обязанности.
НЛО прилетело и опубликовало эту надпись здесь
Ну указывайте в тикете ID ревизии.
Зачем?
Вам — не за чем. Вы не понимаете просто что важно знать какие файлы кем, когда и зачем изменены, вы считаете что сами лучше всех всё знаете.
Это всё растёт из не умения программировать. Кодить, получать работоспособный какой-то продукт — это одно.
А программировать — совсем другое. Если у вас общий стиль в именовании переменных? Написание комментариев, документации? Если нет — то вам и СВН особо не нужен.
Это всё растёт из не умения программировать. Кодить, получать работоспособный какой-то продукт — это одно.
А программировать — совсем другое. Если у вас общий стиль в именовании переменных? Написание комментариев, документации? Если нет — то вам и СВН особо не нужен.
сударь, вы меня обидеть хотите?)))
я знаю команду svn log и svn blame. Я могу увидеть кто когда и что менял. Зачем меняли — указанно в комменте. Они не настолько подробны насколько хотелось но во всех ситуациях когда я хотел узнать зачем и кто менял код я это выяснял.
Насчет именования переменных, это вы тут зачем приплели? Но если интересно отвечу. Да. И не только переменных но и классов и функций. Как и вообщем есть и стандарты кодирования.
Документация тоже есть, но основная документация это наши тесты, и имена классов, методов и переменных.
Еще вопросы есть?
я знаю команду svn log и svn blame. Я могу увидеть кто когда и что менял. Зачем меняли — указанно в комменте. Они не настолько подробны насколько хотелось но во всех ситуациях когда я хотел узнать зачем и кто менял код я это выяснял.
Насчет именования переменных, это вы тут зачем приплели? Но если интересно отвечу. Да. И не только переменных но и классов и функций. Как и вообщем есть и стандарты кодирования.
Документация тоже есть, но основная документация это наши тесты, и имена классов, методов и переменных.
Еще вопросы есть?
Нет, вопросов нет, если вы себе противоречите, какие могут быть вопросы.
каким образом я себе противоречу?
Вот вы говорите:
«у нас очень сложная и непонятная ситуация. ведь просрочки были как раз из-за отсутвия процесса, поэтому страдать должны те кто этот процесс должен был налаживать. ведь так?»
А мне говорите, мол нет, у нас процесс самый зашибательский, это такие есть методы работы, а вы просто глупы и ничего не понимаете.
Виноваты те, которые не смогл организовать процесс, а программисты, не при чём. Пришёл новый человек, увидел это всё, офонарел и попытался хоть как то всё исправить.
А вы говорите, мол нет, фигня все ваши методы, мы привыкли без всякой ответственности тутхер знает что делать заниматься высокотехнологичной разработкой своими супер методами.
«у нас очень сложная и непонятная ситуация. ведь просрочки были как раз из-за отсутвия процесса, поэтому страдать должны те кто этот процесс должен был налаживать. ведь так?»
А мне говорите, мол нет, у нас процесс самый зашибательский, это такие есть методы работы, а вы просто глупы и ничего не понимаете.
Виноваты те, которые не смогл организовать процесс, а программисты, не при чём. Пришёл новый человек, увидел это всё, офонарел и попытался хоть как то всё исправить.
А вы говорите, мол нет, фигня все ваши методы, мы привыкли без всякой ответственности тут
просто вы путаете организацию планирования, которыми занимаются менеджеры, и организацию разработки, которой занимаются программисты. так вот в организации разработки у нас все нормально. у нас собраны грамотные программисты которые могут сами для себя выбрать эффективные методы разработки такие как разработка через тестирование, рефакторинг. применить нужные паттерны проектирования, разработать архитектуру, выбрать правильные эффективные инструменты. если у вас этого нет, я вам сочувствую. А вот организовать грамотное планирование не в наших силах, тут нужна воля менеджмента. Я пытался оргнаизовать сам, и до тех пор пока я этим занимался все шло хорошо. Но это требует большого времени, а на мне еще задачи разработки висят. Пришлось повесить все на ПМ-а который на уже внедренные процессы забил. Так все и развалилось.
Итак, повторяю. Разработка у нас налажена более или мение. Конечно некоторые забивают на тесты, не создают вовремя веток, не любят писать внятные комменты, я пытаюсь влиять как могу, но опять же я не уполномочен настаивать. Но я лично разрабатываю так и как могу обьясняю приемущества своих подходов другим.
А вот планирования у нас нет никакого вообще. Так что никаких противоречий в моих словах нет.
Итак, повторяю. Разработка у нас налажена более или мение. Конечно некоторые забивают на тесты, не создают вовремя веток, не любят писать внятные комменты, я пытаюсь влиять как могу, но опять же я не уполномочен настаивать. Но я лично разрабатываю так и как могу обьясняю приемущества своих подходов другим.
А вот планирования у нас нет никакого вообще. Так что никаких противоречий в моих словах нет.
Да ничего я не путаю.
Эффективные методы, тестирование, рефакторинг… бла бла бла.
Задача есть конкретная? Есть.
Программисты могут постороить процесс написания кода? Могут.
Методы разработки эффективные? Само собой.
Держался весь процесс на вас? Это вообще прекрасно.
Код не написан, задача не решена и проект в жопе? А вот это неожиданно…
Вывод очевиден: Манагеры, суки такие, всё взяли и испортили. Как же иначе, а тут ещё этот новенький не в тему… раньше то хоть можно было отмазаться, мол «мая — невиновная, мая писала писала, а нинаписала. Плана та не была!». А теперь — херушки, отчётность надо осмысленную предоставлять.
Я вот ещё понять не могу, собственно а что вы такое пишете, что без менеджеров (именно в вашем понимании) написать не можете?
Эффективные методы, тестирование, рефакторинг… бла бла бла.
Задача есть конкретная? Есть.
Программисты могут постороить процесс написания кода? Могут.
Методы разработки эффективные? Само собой.
Держался весь процесс на вас? Это вообще прекрасно.
Код не написан, задача не решена и проект в жопе? А вот это неожиданно…
Вывод очевиден: Манагеры, суки такие, всё взяли и испортили. Как же иначе, а тут ещё этот новенький не в тему… раньше то хоть можно было отмазаться, мол «мая — невиновная, мая писала писала, а нинаписала. Плана та не была!». А теперь — херушки, отчётность надо осмысленную предоставлять.
Я вот ещё понять не могу, собственно а что вы такое пишете, что без менеджеров (именно в вашем понимании) написать не можете?
то что мы пишем вкрации это социальная сеть
вопщем вы вывод сделали правильный. даже лучше меня все знаете.
а вообще мне этот диалог несколько поднадоел. вы просто напросто не понимаете многих вещей, но уверенны что вы крутой программист. но вы правильно скзали что кодить это не одно итоже что программировать
вопщем вы вывод сделали правильный. даже лучше меня все знаете.
а вообще мне этот диалог несколько поднадоел. вы просто напросто не понимаете многих вещей, но уверенны что вы крутой программист. но вы правильно скзали что кодить это не одно итоже что программировать
Как же приятно такие вот фразы говорить: «вы уверены что вы крутой, но вы просто не понимаете многих вещей»
Социальная сеть? Опять? Ну что же, крутые и понимающие, — передаю обратно флаг в руки вам. А я, глупый, пойду писать очередной лист нахер ни кому не нужного и глупого технического задания.
Всего вам доброго, диалог хоть и не без мелких пакостей, но полезный получился, по крайней мере для меня точно. За что вам большое спасибо!
Социальная сеть? Опять? Ну что же, крутые и понимающие, — передаю обратно флаг в руки вам. А я, глупый, пойду писать очередной лист нахер ни кому не нужного и глупого технического задания.
Всего вам доброго, диалог хоть и не без мелких пакостей, но полезный получился, по крайней мере для меня точно. За что вам большое спасибо!
НЛО прилетело и опубликовало эту надпись здесь
Кстати, в одной прошлой компании у нас уже была такая история. Один из наших отделов разработал инструмент для отчетности, взамен устаревшего. Крутой такой, красивый. Много фишек. Но им никто не пользовался. Наш отдел официально отказался им пользоваться, с поддержки начальника отдела. Другие просто забивали. Разработчики тулзы сильно обиделись, ведь такая крутая штука, столько фич, столько любви вложено в неё. Я поговрил с начальником того отдела, и выяснилось что он пытался сделать инструмент удобный для ПМ-ов, что бы можно было смотреть прогресс по задачам, строить графики и тд. А то что программерам это все нафиг не нужно, они хотят заниматься интересным кодингом а не тыканьем кнопок, об этом не подумали.
В итоге проблему решили так, сделали кнопочку, по нажатию на которую появлялось окошко в котором было просто поле ввода, селект со списком задач и кнопочка «отправить отчет». С этого момента все стали тулзой пользоваться, ибо избавились от излишних формальностей.
В итоге проблему решили так, сделали кнопочку, по нажатию на которую появлялось окошко в котором было просто поле ввода, селект со списком задач и кнопочка «отправить отчет». С этого момента все стали тулзой пользоваться, ибо избавились от излишних формальностей.
В нашей компании процесс разработки выглядит так:
— есть список историй;
— команда с ним знакомится, разбивает на атомарные подзадачи, эстимейтит (в нашей компании оценка ставится в perfect hours — реально потраченных на задачу часах, т.е. время, когда человек непосредственно решает задачу (пишет код, проектирует) без учёта времени на другие задачи, например запустить все тесты, выложить новые изменения в систему версионинга и т.д., кто-то из отцов посчитал, что в среднем 1 pf = 2.66 реальных часов);
— после этого истории образуют спринт (что-то выкидывается в зависимости от его длины);
— каждый день люди оценивают свой прогресс, сколько им ещё осталось времени на решение задач (манагер или тим лид это вносит в учётную систему);
— в случае проблем в эстимейт вносятся коррективы.
Это позволяет манагеру трекать почти в реальном времени как движется команда, оценить текущую скорость и получить ещё много полезной информации.
Никакой бюрократии, для девелоперов это занимает 5 минут в день, зато у руководства голова не болит)
— есть список историй;
— команда с ним знакомится, разбивает на атомарные подзадачи, эстимейтит (в нашей компании оценка ставится в perfect hours — реально потраченных на задачу часах, т.е. время, когда человек непосредственно решает задачу (пишет код, проектирует) без учёта времени на другие задачи, например запустить все тесты, выложить новые изменения в систему версионинга и т.д., кто-то из отцов посчитал, что в среднем 1 pf = 2.66 реальных часов);
— после этого истории образуют спринт (что-то выкидывается в зависимости от его длины);
— каждый день люди оценивают свой прогресс, сколько им ещё осталось времени на решение задач (манагер или тим лид это вносит в учётную систему);
— в случае проблем в эстимейт вносятся коррективы.
Это позволяет манагеру трекать почти в реальном времени как движется команда, оценить текущую скорость и получить ещё много полезной информации.
Никакой бюрократии, для девелоперов это занимает 5 минут в день, зато у руководства голова не болит)
А как у вас до этого составлялся план работ? Насколько он выполнялся?
Он никак не составлялся и соответвенно невыполнялся. Лимиты времени по проекту привышены уже в 2 раза.
Смею предположить, что если бы не было этой просрочки в 2 раза, то руководство бы даже не думало о ужесточении тайминга.
совершенно верно. у нас очень сложная и непонятная ситуация. ведь просрочки были как раз из-за отсутвия процесса, поэтому страдать должны те кто этот процесс должен был налаживать. ведь так? а получается что опять крайние программисты.
Меня почему-то всегда умиляли попытки программистов отгородиться от всего. Попытки переложить всю вину на ПМа ни к чему хорошему не приведут.
Одного такого мы уже уволили.
Просрочил на 150-200% время розработки (при этом за него всё дописали другие), и потом утверждал, что во всём виноват ПМ. А то что он просто не работал — его не тревожило.
Просрочил на 150-200% время розработки (при этом за него всё дописали другие), и потом утверждал, что во всём виноват ПМ. А то что он просто не работал — его не тревожило.
А почему ПМ может неработать а программист нет?
НЛО прилетело и опубликовало эту надпись здесь
ПМ в этом случае потратил в четыре раза больше времени, чем программист!!!
Было всё: и полное ТЗ, и обсудждение сроков с программистом, и постановка задач по приоритетам (раз 3-4 в неделю), и задушевные телефонные беседы, и пиво, и прочее-прочее-прочее…
Было всё: и полное ТЗ, и обсудждение сроков с программистом, и постановка задач по приоритетам (раз 3-4 в неделю), и задушевные телефонные беседы, и пиво, и прочее-прочее-прочее…
Ну значит у нас разные случаи. У нас нет ни того ни другого ни третьего ни даже пива он не пьет.
У меня складывается впечатление, что вся ваша проблема ограничивается нелюбовью к текущему PM'у.
Вы правы. Он мужчина, а у меня нормальная ориентация)))
Но если серьезно то я могу говорить несколько часов перечисляя его косяки за те больше года что с ним работаю. Притом что со мной все согласны, от прогов до высшего начальства. И одним им известно почему он до сих пор не уволен. Этот человек за всю свою практику не довел до ума ни одного проекта, все до единого завалены. Текущий стоит на грани развала, нас терпят только потому что жаль уже потраченных денег, наверное.
Его директор на протяжении полугода просит «Юра, сделай план». За это время план у нас был лишь однажды, и то его сделал я с остальными программистами. Вот представьте что вы директор, и ваш подчиненный не выполняет просьбу повторенную 3 раза? Наверное вы будете в бешенстве? А у нас ПМ игнорит просьбу уже в течении полугода которая озвучивается на каждом совещании в среднем раз в 2 недели. При этом он кивает головой, стыдливо смотрит, повторяет «Да сделаю» и все повторяется снова.
Но зато он совсем не виноват в задержке проекта. Нам он говрит что виноваты заказчики, а им говорит что виноваты раздолбаи-программисты которые опаздывают.
Похоже на фантастику. Но у нас так.
Но если серьезно то я могу говорить несколько часов перечисляя его косяки за те больше года что с ним работаю. Притом что со мной все согласны, от прогов до высшего начальства. И одним им известно почему он до сих пор не уволен. Этот человек за всю свою практику не довел до ума ни одного проекта, все до единого завалены. Текущий стоит на грани развала, нас терпят только потому что жаль уже потраченных денег, наверное.
Его директор на протяжении полугода просит «Юра, сделай план». За это время план у нас был лишь однажды, и то его сделал я с остальными программистами. Вот представьте что вы директор, и ваш подчиненный не выполняет просьбу повторенную 3 раза? Наверное вы будете в бешенстве? А у нас ПМ игнорит просьбу уже в течении полугода которая озвучивается на каждом совещании в среднем раз в 2 недели. При этом он кивает головой, стыдливо смотрит, повторяет «Да сделаю» и все повторяется снова.
Но зато он совсем не виноват в задержке проекта. Нам он говрит что виноваты заказчики, а им говорит что виноваты раздолбаи-программисты которые опаздывают.
Похоже на фантастику. Но у нас так.
Я сейчас впрямую говорю начальству в присутствии ПМ-а, что он не выполняет своих обязанностей. Прямые обвинения. Скажите, если бы я был не прав, меня бы наверное бы уже уволили? А мне как с гуся вода, потому что ПМ-у возразить нечего, а шеф прекрасно понимает кто виноват.
> ведь просрочки были как раз из-за отсутвия процесса, поэтому страдать должны те кто этот процесс должен был налаживать
они и стали его налаживать.
они и стали его налаживать.
Тогда вот это:
> 4. Ничем не обоснованное завинчивание гаек
не совсем верно. :) Видимо, обоснование всё-таки есть. :)
> 4. Ничем не обоснованное завинчивание гаек
не совсем верно. :) Видимо, обоснование всё-таки есть. :)
>Как назвать такую методологию разработки?
Напоминает TQM (http://ru.wikipedia.org/wiki/TQM), применительно же к программированию team programming (http://en.wikipedia.org/wiki/Team_programming). Это системный анализ, контроль качества и так далее. По идее при таком подходе у программного продукта должен быть главный архитектор и он этим сможет узнать сколько времени уйдёт на осуществление проекта, а так же поможет снизить риски срыва по срокам.
Напоминает TQM (http://ru.wikipedia.org/wiki/TQM), применительно же к программированию team programming (http://en.wikipedia.org/wiki/Team_programming). Это системный анализ, контроль качества и так далее. По идее при таком подходе у программного продукта должен быть главный архитектор и он этим сможет узнать сколько времени уйдёт на осуществление проекта, а так же поможет снизить риски срыва по срокам.
Выполнение оценочных сроков не требуется, значит это прогнозирование, оценивание (estimation). Я почти всегда для себя оцениваю все задачи из JIRA, хотя требование такое редко возникает.
Составление прогнозов отдельных задач и их анализ позволит точнее прогнозировать фазы разработки, релизы например. А так же позволит оценить свою произодительность. Чтобы упростить себе задачу, пока я вникал в эту идею, я предварительную оценку умножал на три. Такая оценка обычно получалась всего на немного больше реальной, потому что при изначальной оценке я забывал учесть тестирование, документирование, рефакторинг существующего кода, время на анализ существующей архитектуры, выход fallout 3 и сон.
Кроме общей оценки я часто веду отдельную статистику с прогнозом для более мелких задач типа «чистка кода, чистка javadoc, рефакторинг чего-нибудь».
Пункт 3 можно сделать автоматическим, если использовать Status: In progress.
Составление прогнозов отдельных задач и их анализ позволит точнее прогнозировать фазы разработки, релизы например. А так же позволит оценить свою произодительность. Чтобы упростить себе задачу, пока я вникал в эту идею, я предварительную оценку умножал на три. Такая оценка обычно получалась всего на немного больше реальной, потому что при изначальной оценке я забывал учесть тестирование, документирование, рефакторинг существующего кода, время на анализ существующей архитектуры, выход fallout 3 и сон.
Кроме общей оценки я часто веду отдельную статистику с прогнозом для более мелких задач типа «чистка кода, чистка javadoc, рефакторинг чего-нибудь».
Пункт 3 можно сделать автоматическим, если использовать Status: In progress.
1. Излишняя бюрократия
2. Излишний геморой
3. Не способствует живому общению
4. Ничем не обоснованное завинчивание гаек
Вы с вашим тех.диром не разговариваете?
Позвоните ему, выясните причины, выслушайте доводы. Думаю, он все это не ради формализмов делает…
2. Излишний геморой
3. Не способствует живому общению
4. Ничем не обоснованное завинчивание гаек
Вы с вашим тех.диром не разговариваете?
Позвоните ему, выясните причины, выслушайте доводы. Думаю, он все это не ради формализмов делает…
Он новенький, пока как то сторонится нас. В пятницу бедет предметная беседа, вот и задам вопрос обязательно.
Вот в чём ваша правда — так это в том, что не следовало ему прямо с места в карьер так… Надо было сесть обсудить всё, понять причины срыва сроков… а он свои порядки кинулся наводить…
По мойму у вас в команде «коммуникационная проблема» (я правда без малейшего понятия, как ваша организация выглядит и какие отношения там «правят»). Мне не понятно, зачем ждать пятницы, выставлять вами описанные требования на всеобщее обозрение, если можно просто позвонить человеку и нормально эту тему обговорить. Если есть вопросы, то желательно решать их напрямую с человеком, который может дать на них нормальный и исчерпывающий ответ — а это ваш тех.дир.
Выглядит, как будто это не он вас сторонится, а вы сторонитесь его, так как не вступаете в открытый диалог. А без него у вас работа будет сплошной непродуктивной мукой.
Выглядит, как будто это не он вас сторонится, а вы сторонитесь его, так как не вступаете в открытый диалог. А без него у вас работа будет сплошной непродуктивной мукой.
Да ладно, где бюрократия?? В способах работы с системой контроля выполнения задач? Просто элементарная организованность, вот и все. Странно, что в компании это принято как будто это в диковинку. Уж давно должно быть организовано схожим образом.
P.S. А программисты, кстати, я заметил всегда считают излишним геморроем многие необходимые организационные моменты, ограничивающие по времени выполнение ими задач.
P.S. А программисты, кстати, я заметил всегда считают излишним геморроем многие необходимые организационные моменты, ограничивающие по времени выполнение ими задач.
Читаю и узнаю все те типичные ошибки и проблемы, через которые прошла моя компания внедрив Scrum года два с половиной назад еще… Только вместо JIRA мы используем Mantis — bug tracking system. Опыт одного проекта, который изначально планировался месяцев на 6-8, а вылилось все в почти что двухлетнюю доводку до ума (большая GIS информационная система для государственной организации, занимающейся управлением лесной гос. и частной собственностью) показал, что надо что то срочно делать. Пришел менеджер, принес распечатку статьи страниц на 5 про Scrum: «Будем внедрять».
Во что все вылилось? Спринты двухнедельные. Каждая задача в Мантисе получала предварительную оценку по-времени. Сидели на митинге часа по два-три, обсуждали задачи в порядке очередности, на ходу планировали, изменяли, дизайнили, каждый разработчик оценивал свои задачи. На следующем митинге задачи, которые не успели сделать перекидывали в новый спринт и так далее. Иногда читалось какое-то молчаливое недоумение в глазах девелоперов… Редко когда удавалось уложиться в расписание. Потому что на коленке нельзя проводить даже грубую оценку — it just fails. Как показывает опыт, время на изучение — initial research, анализ и планирование реализации задачи, тестирование, ну вообщем многие аспекты, напрямую не связанные с написанием кода, не учитываются при оценке, данной разработчиком. Для этого нужен опыт, а также соответствующее звено между менеджментом (по работе с заказчиками) и инженерами — технический менеджмент — который в нашей небольшой компании (lack of resources — typical problem) заменялось общими усилиями всех и вся: и ПМ, работающих с заказчиками, и девелоперами. А также знания, хотя бы теоретические (с тех пор прочитал много полезных и интересных книг по Скраму), а не статья на пять страниц.
Короче менеджеры уходят, приходят, а мы на ошибках учимся. Один из выводов, к которому я пришел уже очень давно по поводу описанного проекта и подохода к управлению — неправильное использование «тулзов» — в нашем случае Mantis — что есть изначально и прежде всего всего лишь bug tracking system. Помню — сидишь и напрягаешься, а сколько же в этот раз дней поставить — time estimation. А сроки поджимают — дела надо делать: разрабтаывать, тестировать, баги править…
Вообщем кратко: компания небольшая, все сами себе и архитекторы, и разработчики, и тестеры, и планировщики (в последнее время порядок кое как наводится в этом отношении). Недостаток ресурсов (human resources) привел к тому, что менеджер по работе с заказчиками, взялся за управление процессом разработки с точки зрения трудозатрат и так далее. От этого — неправильное использование «тулзов», расточительное изпользование времени на митинги перед спринтами для обсуждения и оценки времени. А отсюда внутреннее непонимание у разработчиков, которое очень мешало сосредоточиться на полезной работе. И как итог, я считаю, что мы могли потратить намного меньше времени на проект, если бы… ну а это уже совсем другая история, возможно даже статью напишу, где проанализирую наши ошибки. Благо опыт самый разнообразный, с разными менеджерами и разными проектами.
Оценку надо проводить безусловно. Прежде всего даже — для себя. Это мобилизует, стимулирует к улучшению различных профессиональных навыков. Самоорганизует. Хочется совершенствоваться, расширять знания, умения. В том числе и в области управления чем-то большим, чем разработка yet another cool widget. Это ведь целая проблемная область, над которой бьются во многих больших IT корпорациях. И считаю — что начинать нужно с себя. Тогда никакие менеджеры не страшны.
Сорри, что много, наверное лучше будет статейку даже накатать.
Во что все вылилось? Спринты двухнедельные. Каждая задача в Мантисе получала предварительную оценку по-времени. Сидели на митинге часа по два-три, обсуждали задачи в порядке очередности, на ходу планировали, изменяли, дизайнили, каждый разработчик оценивал свои задачи. На следующем митинге задачи, которые не успели сделать перекидывали в новый спринт и так далее. Иногда читалось какое-то молчаливое недоумение в глазах девелоперов… Редко когда удавалось уложиться в расписание. Потому что на коленке нельзя проводить даже грубую оценку — it just fails. Как показывает опыт, время на изучение — initial research, анализ и планирование реализации задачи, тестирование, ну вообщем многие аспекты, напрямую не связанные с написанием кода, не учитываются при оценке, данной разработчиком. Для этого нужен опыт, а также соответствующее звено между менеджментом (по работе с заказчиками) и инженерами — технический менеджмент — который в нашей небольшой компании (lack of resources — typical problem) заменялось общими усилиями всех и вся: и ПМ, работающих с заказчиками, и девелоперами. А также знания, хотя бы теоретические (с тех пор прочитал много полезных и интересных книг по Скраму), а не статья на пять страниц.
Короче менеджеры уходят, приходят, а мы на ошибках учимся. Один из выводов, к которому я пришел уже очень давно по поводу описанного проекта и подохода к управлению — неправильное использование «тулзов» — в нашем случае Mantis — что есть изначально и прежде всего всего лишь bug tracking system. Помню — сидишь и напрягаешься, а сколько же в этот раз дней поставить — time estimation. А сроки поджимают — дела надо делать: разрабтаывать, тестировать, баги править…
Вообщем кратко: компания небольшая, все сами себе и архитекторы, и разработчики, и тестеры, и планировщики (в последнее время порядок кое как наводится в этом отношении). Недостаток ресурсов (human resources) привел к тому, что менеджер по работе с заказчиками, взялся за управление процессом разработки с точки зрения трудозатрат и так далее. От этого — неправильное использование «тулзов», расточительное изпользование времени на митинги перед спринтами для обсуждения и оценки времени. А отсюда внутреннее непонимание у разработчиков, которое очень мешало сосредоточиться на полезной работе. И как итог, я считаю, что мы могли потратить намного меньше времени на проект, если бы… ну а это уже совсем другая история, возможно даже статью напишу, где проанализирую наши ошибки. Благо опыт самый разнообразный, с разными менеджерами и разными проектами.
Оценку надо проводить безусловно. Прежде всего даже — для себя. Это мобилизует, стимулирует к улучшению различных профессиональных навыков. Самоорганизует. Хочется совершенствоваться, расширять знания, умения. В том числе и в области управления чем-то большим, чем разработка yet another cool widget. Это ведь целая проблемная область, над которой бьются во многих больших IT корпорациях. И считаю — что начинать нужно с себя. Тогда никакие менеджеры не страшны.
Сорри, что много, наверное лучше будет статейку даже накатать.
Из поста так сути и не уловил. Наверное и правда лучше статейку. Глаавное что понял это то, что прежде чем браться за постановку процесса, нужно его понимать, каждую мелочь, для чего все это, какие плюсы и минусы, чем грозит, какую пользу дает. Нужно не только знать что делать, но и понимать для чего это все нужно, на какие такие точки мы надавливаем той или иной практикой, какие рычажки дергаем. Не поверхностное зазубренное, а глубокое понимание методики необходимо.
Честно говоря, я так же прочел много книг, много применял сам, когда была возможность. много убеждал применять ПМ-ов, и смотрел на результат. Каждую практику обдумал и переварил не раз. Мне это интересно. Но читая многих здесь отписавшихся, прихожу у выводу что многие слишком поверхностно понимают этот вопрос. Видят лишь общие аспекты, лежащие на поверхности. Но эффективность Agile-методик как раз и происходит от того что они, немотря на кажущуюся простоту, очень тонкие и многогранные. Их применение дергает понемножку за множество ниточек, незамтно превращая все в живой механизм. Тут и техпроцессы, тут и психология, тут и невидимые вроде бы рамки, за которые просто не получится выйти. И главное, конечно это человеческий фактор. Часто как раз вопрос человеческого фактора упускается из виду, как в приведенном здесь случае. Что кстати меня сразу и насторожило.
Честно говоря, я так же прочел много книг, много применял сам, когда была возможность. много убеждал применять ПМ-ов, и смотрел на результат. Каждую практику обдумал и переварил не раз. Мне это интересно. Но читая многих здесь отписавшихся, прихожу у выводу что многие слишком поверхностно понимают этот вопрос. Видят лишь общие аспекты, лежащие на поверхности. Но эффективность Agile-методик как раз и происходит от того что они, немотря на кажущуюся простоту, очень тонкие и многогранные. Их применение дергает понемножку за множество ниточек, незамтно превращая все в живой механизм. Тут и техпроцессы, тут и психология, тут и невидимые вроде бы рамки, за которые просто не получится выйти. И главное, конечно это человеческий фактор. Часто как раз вопрос человеческого фактора упускается из виду, как в приведенном здесь случае. Что кстати меня сразу и насторожило.
Вы совершенно правы. Согласен со всем сказанным.
А мой пост немного скомкан. Просто захотелось отписаться по такой животрепещущей теме, где столько копий сломано было, а когда начал писать, понял, что в двух словах пятилетний опыт не отразить.
Нюансов очень много и человеческий фактор безусловно важен. Попытки сконцентрироваться лишь на одном или нескольких аспектах той или иной методологии — часто не только не достигают поставленных целей, но могут перечеркнуть вообще все вообщем-то хорошие начинания. В нашем случае — слишком сильная зацикленность на time estimation, schedule tracking. Это тоже важно, безусловно. Но опять же, то, как все было организовано — в том числе и из-за недостатка опыта, нехватки времени изучить вопрос и получить этот самый опыт — привело к непониманию среди разработчиков. Процесс (Scrum) в таком виде просто не сработал у нас и бы на время предан забвению даже.
А когда вообще без какого-либо обсуждения пытаются внедрять что то сверху (как видимо в вашем случае) — это не способствует пониманию в команде. Я думаю любая методология следующая каким-угодно state-of-the-art принципам в условиях небольшой компании или команды нуждается в притирке к нуждам этой компании и с учетом человеческого фактора. В каждой компании есть свои устоявшиеся правила (будь то форматирование кода или использование каких-то «тулзов»). Приходит новый менеджер из другой маленькой компании и пытается насадить свой «опыт». Этот опыт не обязательно приживется в вашей компании и не обязательно подходит именно для «вас». Вообщем с такими «разнарядками» я был бы осторожен. Сначала нужно все обсудить и вместе искать нове решения.
А мой пост немного скомкан. Просто захотелось отписаться по такой животрепещущей теме, где столько копий сломано было, а когда начал писать, понял, что в двух словах пятилетний опыт не отразить.
Нюансов очень много и человеческий фактор безусловно важен. Попытки сконцентрироваться лишь на одном или нескольких аспектах той или иной методологии — часто не только не достигают поставленных целей, но могут перечеркнуть вообще все вообщем-то хорошие начинания. В нашем случае — слишком сильная зацикленность на time estimation, schedule tracking. Это тоже важно, безусловно. Но опять же, то, как все было организовано — в том числе и из-за недостатка опыта, нехватки времени изучить вопрос и получить этот самый опыт — привело к непониманию среди разработчиков. Процесс (Scrum) в таком виде просто не сработал у нас и бы на время предан забвению даже.
А когда вообще без какого-либо обсуждения пытаются внедрять что то сверху (как видимо в вашем случае) — это не способствует пониманию в команде. Я думаю любая методология следующая каким-угодно state-of-the-art принципам в условиях небольшой компании или команды нуждается в притирке к нуждам этой компании и с учетом человеческого фактора. В каждой компании есть свои устоявшиеся правила (будь то форматирование кода или использование каких-то «тулзов»). Приходит новый менеджер из другой маленькой компании и пытается насадить свой «опыт». Этот опыт не обязательно приживется в вашей компании и не обязательно подходит именно для «вас». Вообщем с такими «разнарядками» я был бы осторожен. Сначала нужно все обсудить и вместе искать нове решения.
+1 К необходимости статейки.
Про Agile — исходя из моего представления, основная их цель заключается в том, чтобы можно было проектировать и одновременно разрабатывать. Т.е. находить ту тонкую грань, где проектировщики успевают вперед разработчиков при одновременном старте.
Про Agile — исходя из моего представления, основная их цель заключается в том, чтобы можно было проектировать и одновременно разрабатывать. Т.е. находить ту тонкую грань, где проектировщики успевают вперед разработчиков при одновременном старте.
как то вы слишком узко понимаете Agile)))
Да-да-да. В этом я никак не поспорю… Но пока что я его понимаю ровно настолько. :) Думаю в будущем я таки продвинусь.
начните с этого. Книга совсем не про методики быстрой разработки но вам это поможет глубже их понять. Потому что во главе угла каждой из этих методик стоит как раз человеческий фактор.
Сейчас я книжки такого плана и читаю. В частности неожиданно для себя наткнулся на сносное описание UP в книжке http://www.ozon.ru/context/detail/id/3105480/
Ну успевать при Agile — это как следствие. Просто методологии нацелены на это. А вообще они для упрощения всего процесса без ущерба для результата.
Насколько я вижу — здесь назвевает конфликт между автором и новым техдиром. Каждый тянет одеяло на себя. Новый техдир хочет организовать так, как ему привычно. Автор противится изменениям.
Если техдир достаточно хорош — конфликта не будет, он соберет замечания, немного исправит свой курс и убедит в своей правоте кардинально несогласных.
Если техдир достаточно хорош — конфликта не будет, он соберет замечания, немного исправит свой курс и убедит в своей правоте кардинально несогласных.
как убедит? Увольнением?)))
конфликт наверное не назревает так как я пока понятия не имею что он задумал. Может в комплексе это и будет выглядеть разумно, или скажем разумность всех остальных действий затмит этот небольшой косячек. Ну и мы потихоньку или тихо забьем, а в общем успехе от остальных действий техдира это как бы потеряется.
Но пока у меня ощущение что техдир нас расценивает как станки с програмным управлением. Заложил программу, и они строкают код. Заложил другую, строкают другой код. Подправил програму немного — строгают быстро.
конфликт наверное не назревает так как я пока понятия не имею что он задумал. Может в комплексе это и будет выглядеть разумно, или скажем разумность всех остальных действий затмит этот небольшой косячек. Ну и мы потихоньку или тихо забьем, а в общем успехе от остальных действий техдира это как бы потеряется.
Но пока у меня ощущение что техдир нас расценивает как станки с програмным управлением. Заложил программу, и они строкают код. Заложил другую, строкают другой код. Подправил програму немного — строгают быстро.
В том числе и увольнением, если директор одобрит чистку рядов. А если техлидер грамотен — он сможет это обосновать :)
Конфликты бвают большие и маленькие. В данном случае конфликт небольшой :)
У меня складывается впечателние — что вам надо сработаться. Вот и все. Возможно ближайший корпоратив вам всем поможет в этом деле :)
Конфликты бвают большие и маленькие. В данном случае конфликт небольшой :)
У меня складывается впечателние — что вам надо сработаться. Вот и все. Возможно ближайший корпоратив вам всем поможет в этом деле :)
1. Вводятся следующие понятия:
sub-task — подзадача,
В Жире уже есть sub-task-и. Их просто надо включить.
imho:
1. JIRA это трэкинговая система, а не полноценная система управления проектами.
2. Работа со временем в ней реализована безбожно.
Точнее не сколько в ней, сколько в MyLyn, который к ней коннектится с Eclipse-а.
Резюмирую свое мнение по топику.
Все заявленные техдиром требования выглядят вполне себе адекватно. Помимо этого, они совершенно не противоречат Agile-подходу к самому процессу, а наоборот, в частном случае (работа с issue-tracking-системой) вводят организованность в процесс.
Однако, здесь есть одно «большое мохнатое но» ©. Техдир. Вот почему возникло ощущение «бюрократии и закручивания гаек». Техдир принял решение сам и преподнес его как априори единственно верное. Нормальный управленец так делать не должен ни в коем случае (есть исключения, но здесь не о них). Нужно постоянно «держать контакт с аудиторией», в нашем случае с командой. И чтобы люди, которые будут работать по этим новым правилам, полностью понимали все предпосылки использования именно такого подхода/формата/стандарта. Поскольку, кому-то ведь действительно это может быть и не очень удобно.
Так что, думаю, выход в том, чтобы обсудить с техдиром все. Если ну никак не получается — эскалировать этот трабл высшему начальству и предпринимать меры (ну это в случае если техдир совсем невменяемый окажется, даже по прошествии времени).
Все заявленные техдиром требования выглядят вполне себе адекватно. Помимо этого, они совершенно не противоречат Agile-подходу к самому процессу, а наоборот, в частном случае (работа с issue-tracking-системой) вводят организованность в процесс.
Однако, здесь есть одно «большое мохнатое но» ©. Техдир. Вот почему возникло ощущение «бюрократии и закручивания гаек». Техдир принял решение сам и преподнес его как априори единственно верное. Нормальный управленец так делать не должен ни в коем случае (есть исключения, но здесь не о них). Нужно постоянно «держать контакт с аудиторией», в нашем случае с командой. И чтобы люди, которые будут работать по этим новым правилам, полностью понимали все предпосылки использования именно такого подхода/формата/стандарта. Поскольку, кому-то ведь действительно это может быть и не очень удобно.
Так что, думаю, выход в том, чтобы обсудить с техдиром все. Если ну никак не получается — эскалировать этот трабл высшему начальству и предпринимать меры (ну это в случае если техдир совсем невменяемый окажется, даже по прошествии времени).
В подтверждение моих слов статья xprogramming.com.ua/takeacard.php
Цитата
Вот об этом, о таких вот артифактах и идет здесь речь. Как раз говорится что «акие искусственно созданные объекты едва заметны». Далее, пряма как по мотивам темы этого топика автор предупреждает о «сваливании требований на разработчиков и информировании о сроке завершения». И называется все это «Старый путь»
То против чего я и выступаю. Безусловно это лучше чем совсем ничего, но есть другие, более эффективные пути.
Цитата
Старый путь
Тяжёлые артефакты
Некоторые подходы требуют от команды производства «артефактов». Такие искусственно созданные объекты едва заметны, и, возможно, они имеют некоторые связи с реальностью. Документы анализа демонстрирует чьи-то размышления о ситуации; документация требований вносит ясность в то, что мы хотим; проекты показывают, что кто-то представил себе как это сделать; отчёты тестирования показывают, что кто-то разработал документ о том, как определить актуальную работоспособность вещей.
Просто делать
Другой распространённый подход заключается в сваливании требований на разработчиков и информировании о сроке завершения. Некоторые более «просвещённые» менеджеры могут потребовть от разработчиков оценить, когда работа будет сделана.
Как это работает для вас?
Вы, вероятно, как и мы, слышали о существовании организаций, которые могут заставить такие подходы работать. Тем не менее, даже если они выполнят свою работу, вы получите прошлогоднее, то есть, что вы искали год назад. Но, как правило, вы получите кучу бумаг, которые ни одному человеку, в том числе и пользователю, непонятны. А программа, полученная слишком поздно и с превышением бюджета, не даст вам того, что на самом деле требуется.
Вот об этом, о таких вот артифактах и идет здесь речь. Как раз говорится что «акие искусственно созданные объекты едва заметны». Далее, пряма как по мотивам темы этого топика автор предупреждает о «сваливании требований на разработчиков и информировании о сроке завершения». И называется все это «Старый путь»
То против чего я и выступаю. Безусловно это лучше чем совсем ничего, но есть другие, более эффективные пути.
НЛО прилетело и опубликовало эту надпись здесь
Проблема в том что даже если люди адекватны, то понимают проблему из них единицы. Остальным, как и большинству здесь все кажется вполне нормальным, а те кто действительно видят проблему, они в меньшинстве. Поэтому демократия тут не поможет. Безусловно высказаться дать надо всем, но решать необходимо не по принципу большинства.
А вообще некоторым вообще пофиг, другим не пофиг но они предпочтут не идти против начальства, третьи и не пойдут и при этом тихо забьют на правила, четвертые и правда будут уверенны что так надо, но когда поймут что это плохо, то тоже забьют. Пятые предпочтут уволится.
А вообще некоторым вообще пофиг, другим не пофиг но они предпочтут не идти против начальства, третьи и не пойдут и при этом тихо забьют на правила, четвертые и правда будут уверенны что так надо, но когда поймут что это плохо, то тоже забьют. Пятые предпочтут уволится.
Плавали, знаем. Задача достоверной оценки сроков завершения проекта, насколько я помню, не решена до сих пор. Существует множество методик, некоторые их с успехом применяют, однако не являются ли эти методики плацебо?
Вот есть проект. Допустим для него четко описан фронт работ, детализированы требования и т.п., прямо хоть сейчас садись и делай. Для такого проекта оценка возможна хотя бы теоретически. Обычно же бывает, что требования не то, что не детализированы, а вообще неясны на этапе планирования, фронт работ — от забора до обеда, есть просто некоторые задумки. Как тут планировать? Да никак.
Если это софтверный проект, то по мере его реализации объем работ очерчивается все четче. Однако кроме реализации функциональных требований должен быть еще этап контроля качества и исправления ошибок. А сколько будет этих ошибок — знает только боженька. Как тут планировать? Исправил здесь — повылазило там. Вышло обновление библиотеки — клиенты требуют, чтобы использовалась она — еще время. И т.п.
Дальше, оценки со стороны исполнителей. Да, со временем набиваешь руку в определении, сколько времени займет эта бага. В виде оценок «от 2 до 8 часов». Как из этого собрать итоговую оценку?
Для чего вообще нужны эти оценки? Чтобы знать дату релиза? Да не надо ее знать, надо ее назначить. Назначили на 1 марта 2009 года и все тут, надо успеть.
Или чтобы знать, на каком этапе находится проект и скоро ли свет в конце тоннеля? А правило Парето: 80% работ делаются за 20% времени?
Вот есть проект. Допустим для него четко описан фронт работ, детализированы требования и т.п., прямо хоть сейчас садись и делай. Для такого проекта оценка возможна хотя бы теоретически. Обычно же бывает, что требования не то, что не детализированы, а вообще неясны на этапе планирования, фронт работ — от забора до обеда, есть просто некоторые задумки. Как тут планировать? Да никак.
Если это софтверный проект, то по мере его реализации объем работ очерчивается все четче. Однако кроме реализации функциональных требований должен быть еще этап контроля качества и исправления ошибок. А сколько будет этих ошибок — знает только боженька. Как тут планировать? Исправил здесь — повылазило там. Вышло обновление библиотеки — клиенты требуют, чтобы использовалась она — еще время. И т.п.
Дальше, оценки со стороны исполнителей. Да, со временем набиваешь руку в определении, сколько времени займет эта бага. В виде оценок «от 2 до 8 часов». Как из этого собрать итоговую оценку?
Для чего вообще нужны эти оценки? Чтобы знать дату релиза? Да не надо ее знать, надо ее назначить. Назначили на 1 марта 2009 года и все тут, надо успеть.
Или чтобы знать, на каком этапе находится проект и скоро ли свет в конце тоннеля? А правило Парето: 80% работ делаются за 20% времени?
Мне кажется, что подзадачи это явно лишнее, а так же пункт 3, когда девелопер устанавливает _календарную дату_ выполнения задачи — зачем лишнее действие, если у задачи есть оцененная трудоемкость?
Если вашего техдира интересует календарный план, расписанный с точностью до задачи, то вы правы — это всего лишь бюрократия и может быть ему просто нужно показать бурную деятельность в компании, раз он у вас «новый».
Насчет облегчения работы с JIRA посмотрите плагин GreenHopper — добавляет очень удобный интерфейс и ускоряет работу в разы.
А вообще, как правильно уже здесь заметили выше — JIRA нифига не инструмент для управления проектом, а просто багтрекинговая система.
Поэтому, если вы не хотите обременять себя лишними сложностями при работе с инструментом для управления проектом, посмотрите на devprom.net.
В нем нет ничего лишнего, работать с ним просто и удобно, а ваш техдир будет видеть все что ему хочется.
Если вашего техдира интересует календарный план, расписанный с точностью до задачи, то вы правы — это всего лишь бюрократия и может быть ему просто нужно показать бурную деятельность в компании, раз он у вас «новый».
Насчет облегчения работы с JIRA посмотрите плагин GreenHopper — добавляет очень удобный интерфейс и ускоряет работу в разы.
А вообще, как правильно уже здесь заметили выше — JIRA нифига не инструмент для управления проектом, а просто багтрекинговая система.
Поэтому, если вы не хотите обременять себя лишними сложностями при работе с инструментом для управления проектом, посмотрите на devprom.net.
В нем нет ничего лишнего, работать с ним просто и удобно, а ваш техдир будет видеть все что ему хочется.
По первому пункту:
Нумерация версий хреновая — обнаружится, когда
— будут выпущены три версии за день
— в октябре срочно понадобится исправить одинокий баг в январской версии ничего в ней не меняя
А вы и правда автомобиль собираете? Нет? А техдир это знает?
Нумерация версий хреновая — обнаружится, когда
— будут выпущены три версии за день
— в октябре срочно понадобится исправить одинокий баг в январской версии ничего в ней не меняя
А вы и правда автомобиль собираете? Нет? А техдир это знает?
Ух, захватывающий топик. Тут часто упоминается вред от ежедневных отчётов, их бесполезность и так далее. Это не совсем так. Я почти пять лет работал с ежедневными отчётами и сам для себя выработал уже описанную тут систему — репорт пишется не в последние 15 минут, а в процессе работы. Пришёл утром, отрыл файл отчёта и начал работать, любое достаточно большое изменение вносится в файл. Сам отчёт в конце рабочего дня отправляется на нужное мыло, отправляется роботом, в заданное время. Система очень полезная, поскольку позволяет самому отслеживать свой собственный прогресс, правда, исключительно на личном уровне.
Со сроками всё значительно сложнее. Чаще всего оценка девелопера/ПМа вообще ничего не значит. Сверху спускается конкретная дата: «релиз 31 декабря!» Другой вариант:
— В какой срок ты оцениваешь работу?
— Три недели.
— Нет, это неверно, придётся всё сделать за две.
Попытки убедить, что за две недели это сделать невозможно, расцениваются практически как саботаж. А когда действительно не успеваем, вся вина перекладывается на девелоперов.
Когда читал уже упомянутые тут книжки (Peopleware, Мифический человекомесяц, Путь камикадзе), я буквально рыдал, настолько описанные ситуации напоминали те, кототорые удалось пережить. И несмотря на то, что книги эти написаны очень давно, подобные ситуации вновь и вновь повторяются.
Пардон, что несколько несвязно, но накипело.
Со сроками всё значительно сложнее. Чаще всего оценка девелопера/ПМа вообще ничего не значит. Сверху спускается конкретная дата: «релиз 31 декабря!» Другой вариант:
— В какой срок ты оцениваешь работу?
— Три недели.
— Нет, это неверно, придётся всё сделать за две.
Попытки убедить, что за две недели это сделать невозможно, расцениваются практически как саботаж. А когда действительно не успеваем, вся вина перекладывается на девелоперов.
Когда читал уже упомянутые тут книжки (Peopleware, Мифический человекомесяц, Путь камикадзе), я буквально рыдал, настолько описанные ситуации напоминали те, кототорые удалось пережить. И несмотря на то, что книги эти написаны очень давно, подобные ситуации вновь и вновь повторяются.
Пардон, что несколько несвязно, но накипело.
А с каким же упоением мы все пустились дискутировать…
Признавайтесь, сколько рабочего времени потрачено на написание постов! :)
Признавайтесь, сколько рабочего времени потрачено на написание постов! :)
Это никакая не методология, а просто способ пользоваться жирой.
У нас тоже примерно так принято, это нетрудно.
У нас тоже примерно так принято, это нетрудно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как назвать такую методологию разработки?