Как назвать такую методологию разработки?

    Сегодня пришло письмо от нового техдира. Ему не нравится как мы используем Жиру, поэтому он предлагает следующее:

    По работе с Жирой:

    1. Вводятся следующие понятия:
    sub-task - подзадача,
    versions - версии продукта, привязанные к определенной дате, это наше внутреннее обозначение, номер версии = год+неделя, т.е. 0852 - версия 2008 года, 52-я неделя
    components - компоненты системы, это как колеса, двигатель, кузов у автомобиля
    estimated time - исходная оценка, т.е. предварительная оценка времени на выполнение задачи

    2. До начала работы над задачей - провести предварительную оценку требуемого времени и зафиксировать эту оценку в поле "Estimated time - Исходная оценка" - (в режиме редактирования) - это обязательное требование. Кто: Project Leader или Developer.

    3. Непосредственно перед началом работы над задачей необходимо установить дату предполагаемого окончания работы "Срок исполнения" (в режиме редактирования), с учетом текущей даты и "Исходной оценки" - это обязательное требование. Кто: Developer

    4. Components - фиксируется список компонентов системы, список дополняется/изменяется по необходимости. Кто: Project Leader

    5. Versions -
    Следующие задачи: выполненные, в работе, имеющие предварительную оценку открытые - интегрируются в Версии Продукта. Примерный график выпуска версий - один раз в две недели. Кто: Management+Project Leader - это обязательное требование.

    Хорошего дня,


    Честно говоря мне кажется что это
    1. Излишняя бюрократия
    2. Излишний геморой
    3. Не способствует живому общению
    4. Ничем не обоснованное завинчивание гаек

    Сейчас мы используем JIRA просто для постановки задач и багов. Сделал — перевел в проверку.

    Но я не исключаю что могу чего-то не знать. Может быть кто-то применяет подобное в своей практике, и это все оправдано? А может у этого есть назваие и это часть даже некой методики? Я понял только, что таким методикам как Scrum, XP это точно не нужно.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 263

      +3
      Такая методика называется «Мы делаем всё возможное, чтобы максимально усложнить проекты».
        +1
        Поправлю: усложнить работу программистам(((
          +20
          Позвольте не согласиться.
          На все что тут написано программисту придется потратить не более часа, зато у него появится некая ответственность за сроки (он сам их назвал и подписал), а менеджер сможет нормально контролить работу и реагировать на отставания от графика (сможет попытаться помочь программисту).

          Вообще разработку надо разбивать на итерации. Каждая итерация должна начинаться с шагов представленных в топике и заканчиваться сборкой.

          Это не усложняет работу, а нацеливает на результат.
          • НЛО прилетело и опубликовало эту надпись здесь
              +7
              программист очень часто хочет сделать «лучший» универсальный вариант. а «лучшее» как известно — враг хорошего. в результате срыв сроков.

              если менеджер толковый, то он поможет программисту принять ПРАВИЛЬНОЕ решение об отказе от каких то наворотов, с целью соблюдения сроков. я не говорю о ситуации «сделай, как угодно — лишь бы в срок», это уже крайность.

                +2
                Ну если менеджер может помочь программисту только криками «ооооооо, нам всем песдетц» то гнать такого менеджера в шею!

                А по поводу данных пунктов, менеджер может проконтролировать где были допущены просчеты, что бы не наступить на теже грабли в последующих задачах.
                Оценка времени выполнения самим девелопером очень помогает в будущем знать на какие задачи придется потратить времени больше, на какие меньше, выполнить задачи в срок и не подвести своих колег, так как они могут ожидать окончания вашей задачи.
                  +6
                  Как-то раз шёл снег, и я, переборов своё болезненное состояние, притащился на работу, чтобы собрать нашу шаткую систему воедино – в демонстрационную версию для пользователей. Шерон зашла и обнаружила меня за консолью. Она исчезла и вернулась через несколько минут с миской супа. Когда она влила в меня этот суп, я почувствовал прилив бодрости и спросил, как она умудряется находить время на такие вещи, ведь ей ещё нужно решать столько вопросов, связанных с руководством проектом. Она улыбнулась своей неповторимой улыбкой и сказала: «Том, это и есть руководство».

                  Демарко, Листер «Человеский фактор: успешные проекты и команды»
                    0
                    пять баллов! кстати как раз в третий раз перечитываю это книгу. У меня второй экземпляр, первый потерял, пришлось покупать еще.
              +28
              Нормальный процесс, в серьёзных конторах примерно так и делается. Основная идея, как я думаю, не в том, чтобы затруднить кому-то работу, а чтобы поставить планирование и аналитику на реальные рельсы (оценки трудозатрат на задачи, статистику сбора билдов и т.п).
                +6
                Такой подход применяется не только в разработке, есть множество вариаций для специфичных отраслей.
                Считается одной из самых эффективных моделей проджект менеджмента.
                  +1
                  А можно подробнее как называется такая модель, кем она считается наиболее эффективной, в чем её суть, где можно почитать, для каких отраслей применяется еще?
                  +1
                  Вы не открыли Америку и не изобрели велосипед :) Сам по такой схеме работаю — такой вот у нас workflow.
                    +5
                    Все верно. Единственное, в чем бы я поправил тех.дира, так это в пп.2,3
                    Ответственным за сроки должен быть ПМ, но сроки и реперные точки должны быть согласованы с девелопером (командой).
                      0
                      Согласен с вами, самого на последней работе всегда напрягали постоянные торги «а за сколько сделаешь?», как на базаре. За сколько надо — за столько и сделаю, если зараннее видно что срок недостаточен — это уже можно обсудить.
                        0
                        это нормальный вопрос. правда ответ напрашивается $99.90 — рождественская скидка. Но суть не меняется, разработчик должен представлять объем поставленной задачи. Да, потом указанное число может корректироваться в очень широких пределах, это жизнь :)
                          +2
                          Если разработчик не в состоянии предоставить более-менее реальные сроки, то грош ему цена. Надо четко понимать, что тимлида/ПМа теми же вопросами «донимают» заказчики/техдир. И он ровно так же не может не ответить.
                            0
                            И в чем-же тогда заключается задача тимлида/ПМа? Бегать мальчиком на побегушках между заказчиком и разработчиками? На кой черт тогда он вообще сдался? Если руководитель не понимает суть процесса которым он руководит — то какова ему цена? Тоесть назовет ему разработчик срок в неделю — он будет радостно скакать по офису с воплями «укладываемся», назовет два месяца — скажет «это слишком долго, незнаю почему, но долго», так?
                            Незнаю, может я морально устарел, но руководить группой разработчиков должен тоже разработчик, с огромным стажем, способный определить сроки разработки засчет того что он уже имел опыт разработки таких-же или аналогичных вещей, и имея четкое представление о том какой квалификации у него в подчинении находится персонал — уже расчитывать конкретные сроки. А левый дядя с бубном бегающий между разработчиками с вопросами а-ля «Вася, а за сколько ты сделаешь то?», «Петя, а за сколько это сделает Вася?» — это профанация.
                              +1
                              Руководитель должен быть разработчиков — согласен.
                              Руководитель нужен, чтобы с каждым разработчиком переговорить, утвердить сроки, отследить выполнение задач. Директор этого не может сделать, так как у него зачастую нет знаний «разработчика», но есть деньги, организационные и маркетинговые навыки, а также умение выбирать грамотного руководителя проекта. В идеале так должно быть!
                                0
                                Неделя и два месяца это вообще нереальные сроки для одной задачи. Если задача занимает больше двух дней — она должна быть разбита на подзадачи.

                                В пределах 16-ти рабочих часов вполне реально обойтись без «незнаю почему, но много». Хотя, тут цифра сугубо индивидуальна — для кого-то это 3 часа, а для кого-то — 48. Но суть остается одна.

                                И, кстати, ПМу абсолютно не обязательно быть разработчиком.
                                  +1
                                  Практика показывает что необходимо.
                                    +1
                                    Не путайте «хрошо бы» и «необходимо». У меня есть знакомые неплохие ПМы, которые из программирования знают только то, чего нахватались от программеров, с которыми работают.

                                    Так что практика(моя, да) все-таки показывает, что не обязательно.
                                      0
                                      именно необходимо. всегда есть исключения, но редко. И те кого вы считаете неплохими ПМ-ами не факт что таковыми действительно являются.
                                        0
                                        Почему, обоснуйте? Т.е. ПМ совмещает разработку? Если ПМ был разработчиком 10 лет назад, это хороший ПМ?
                                          +3
                                          Конечно не совмещает. И когда он был разработчиком не важно, важно что бы он не просто писал говнокод а именно перерос кодинг, когда дальше программировать уже неинтересно, все уже написано по сто раз, все паттерны изучены, все рефакторинги проведены. Когда человек стал ПМ-ом не потому что посчитал что это проще а денег больше, а потому что вырос просто из программистов, потому что интересно шакать дальше, интересно развиваться, учится новому, попробовать себя в этой области. Но не находясь долгое время в тесном коллективе программистов, не испытывая на себе влияние других ПМ-ов, сложно понять самое важное, то как каждое действие влияет на программиста. ПМ должен быть таким же технарем как и программер, понимать все особенности работы программиста, говорить с ними на одном языке. Но главное понять что менеджмент это прежде всего вещь социальная, и максимальный эффект получится только если поставить во главу угла человека, а все остальное должно ему помогать.
                                          А люди не поработавшие долгое время в этой индустрии, они расценивают программистов как винтики, а себя как оператора пульта управления. Они думают что если просто дергать за такие вот рычажки механизм будет работать. Они так думают потому что небыли никогда внутри этого механизма.
                                    +2
                                    Почему нереальные, если менеджер доверяет разработчику, а тот готов брать на себя ответственность? Все случаи индивидуальны, я б сказал, что необходимо отсутствие догм у менеджера.
                                      0
                                      Ну, тут все просто — именно потому, что все люди. И в большинстве случаев — ошибаются. Ошибиться с прогнозом на 3 недели ГОРАЗДО(читай — в разы) проще, чем с прогнозом на 2-3-5-10-15 часов. Доверие тут ни при чем — человеку свойственно ошибаться.

                                      Простой пример — программист говорит, что задача займет 3 недели. И ошибается в 2 раза(всякое бывает — не всегда и постоянно, но все же). Эти три недели покрыть нереально и по ушам получает менеджер.

                                      Второй пример — программист говорит, что задача займет день. Ошибается в те же 2 раза. В крайнем случае — поработает на выходных, но сделает. И репутация фирмы не пострадает.
                                        0
                                        ПМ всегда ошибается больше, потому что он меньше понимает собственно что это за работа. При нормальных отношениях программисты готовы работать много, чтобы снивелировать свои ошибки.

                                        Любое разбиение задачи неравномерно, т.к. риски могут появиться на любой стадии. Поэтому оно помогает лишь оценить, работает человек или нет. Не более того.

                                        Я не спорю, что на заводе нужна жесткая дисциплина, предсказуемое производство оно и здесь такое же. Вопрос в другом — как подтолкнуть человека сделать максимум того на что он способен на промышленной основе. К сожалению, очень мало менеджеров этим занимается.

                                        Менеджерам: когда вы последний раз спрашивали разработчиков — все ли их устраивает в работе? или например — не хотели бы они заняться соседней проблемой в том же проекте?
                                          +3
                                          Последнее — на мозоль наступаете. Почему то это такая долгоиграющая болезнь российского софтостроения, когда к разработчику относятся как к производственному материалу. Он производит код, критерии к этому коду с точки зрения отечественного софтопроизводителя — максимально простой, максимально быстро, максимально одноразово.

                                          Это уж разработчик сам старается себе работу облегчить и накопить себе инструментарий. Почему-то (точнее, понятно, почему) самые лучшие фирмы (для разработчика), это те, где менеджмент каким-то образом связан с западом.
                                          0
                                          Это симптом того, что в команде не поставлен процесс разработки, а не потому, что все люди.
                                            0
                                            Что подразумевается под «поставлен процесс разработки»? То, что описано в топике является процессом?
                                              0
                                              То, что описано в топике, это часть процесса, связанная непосредственно с разработкой конечного функционала. Еще взаимодействие с заказчиком, аналитика, и т.п.
                                                0
                                                Все верно, согласен.

                                                Проблема в том, что плохо понятно как процесс может помочь в недооценке задачи. Кто должен оценивать? Должен ли кто-то вообще?
                                                  0
                                                  Зависит от того, каким образом процесс описывает взаимодействие между разработчиками и как он предусматривает разделение обязанностей. Но имхо, как бы я постарался минимизировать временные убытки — задачи бьются на оптимальные для исполнения куски (с точки зрения алгоритмики и взаимодействия программных компонент), разделяются между разработчиками, разработчики выдают примерные сроки (заодно решаем проблемы с имплементацией). Путем скрама лид или ПМ каждый день актуализируют прогресс и опять же направляют в нужное русло. Обязательным условием является техническое превосходство или как минимум равенство лида над другими разработчиками. Жира не нужна, достаточно Microsoft Project.
                                                    0
                                                    То есть это необходимые условия для того, чтобы программист не ошибался в оценке своих задач?
                                                      0
                                                      Нет:) Это условия, при которых программист не будет ставить сроков 3 недели и потом ошибатся в два раза.
                                                        0
                                                        :))) Непонятно в чем тогда Вы со мной несогласны.

                                                        Я про то и говорил — надо изначально установить максимальный срок задачи. Так ошибку легче нивелировать.

                                                        Опять же, мне кажется, что Вам очень везет, если процесс на работе у Вас поставлен так, что вокруг никто не ошибается в сроках ;)
                                                          0
                                                          Простите, я не увидел вашего предложения.

                                                          А про нашу работу — только слезы. У нас нет процесса разработки и нам запрещают его ставить. Поэтому мы делаем такую архитектуру, которая позволяет максимально быстро подстроится под изменяющиеся требования:)
                                                            0
                                                            habrahabr.ru/blogs/development/47022/#comment_1206321

                                                            по поводу условий работы — тоже имеет право на жизнь. Только в маленьких проектах на 1-4 человек. Больше — уже без процесса почти нереально :(
                                                      0
                                                      даже Проджект нужен лишь для красоты. Достаточно простой wiki
                                          +1
                                          В этом случае, когда задачи большие и их несколько сложно разбить (например, пишем здоровенный веб-метод для портала), помогают scrum-митинги. Это так, к слову. Менеджер или лид прибегает, слушает что сделано, помечает прогресс. Заодно можно друг другу помочь трудности обходить.
                                          +2
                                          У нас ПМ такой:) Почему это долго делать? Потому что сложно. Что, сложно одно поле в базу добавить? Вот я когда работал на дельфях в 95-м году… блаблабла.
                                          Или — вот, почему так много ошибок в программе? Почему не тестируете? Потому что требования каждый раз меняются, а если не меняются то приходят новые. Не успеваем. Ну, не понимает человек что такое качество ПО.
                                          Так и живем:) В результате разработчиков выгоняют работать в выходные, потому что управление накосячило. Но с точки зрения управления, все верно, оно думает что это мы такие дебилы:) Бесконечная война.
                                            0
                                            Вот я про это и пишу, вместо того чтобы заниматься программированием — программист должен только и делать что доказывать руководству что он не верблюд, непонятно только кто ради кого работает, конечный продукт-то (как уже тут где-то писали) производится именно программистом.
                                        0
                                        А то что нужно ПМ заказчику сказать когда будет готово (да так, чтобы не через семь лет, да и так, чтобы успеть) вас не напрягает?
                                      +4
                                      Это аналитика, RVK. Так как в 90% случаев, если программист сказал — «неделя», можно смело умножать на три и еще добавлять треть на риски.
                                      А так будет видно — кто факапит, кто очень оптимистичен, а кто просто невменяемый.

                                        +6
                                        Известный факт:
                                        Если спросить у программиста сколько потребуется времени на создание нового справочника, скажем, для редактирования клиентов — он ответит неделя, а уйдет три.
                                        Если спросить его сколько потребуется времени на создание новой формы диалога About — он скажет 2 часа, а справиться за 10 минут.

                                        Большие задачи обычно недооцениваются, а маленькие напротив переоцениваются.

                                        Именно по этому рекомендуют разбивать большие задачи на поменьше, а потом суммировать.
                                        Так реалистичнее можно оценить масштаб трагедии. :)
                                          0
                                          Не ужели для всего этого нужно вводить все эти правила?
                                            –2
                                            к огромному сожалению…
                                              –1
                                              А как без этого обходятся Agile-методики?
                                                –1
                                                В моей практике не было «чистой» Agile разработки.
                                                А то что было похоже, было со стопроцентным пролетанием всех DeadLine'ов.
                                                И, к сожалению, в основном из-за программистов.

                                                В самой Agile-методике, по-моему, конечный срок разработки не провозглашают фактором рабочего процесса вовсе.
                                                  –6
                                                  вот поэтому и пролетали дедлайны потому что не применяли все практики, наверное потому что просто не сумели понять их суть.
                                                    +1
                                                    Agile-методика максимальна индифферентна к заказчику (Этим она вам и нравится)

                                                    В своей же практике, мы спользовали схему, что если программист успел вложится в сроки, которые сам назвал, то +40% к оплате этого куска работы.
                                                      0
                                                      и табличку «ударник программисткого труда»)))
                                                        –3
                                                        Я про табличку не просто так написал. Прочтите книгу «Рабы майкрософт», и посмотрите как нормальные программисты относятся к подобного рода подачкам. За что премия, если программист может сделать что, то то он сделает. Если нет, то нет. Если ему не хочется работать потому что ПМ мудак, то проще сменить ПМ-а, и программист будет больше доволен и ПМ на долго а 40% один раз. Проще всего купить программиста деньгами, чем понять почему он не может работать так же хорошо и без денежной стимуляции. Ведь получается если ему денег не предлагать, он будет халявить? А если нет, то значит за эти 40% он работает на износ, значит будут у него проблемы в семье, недосып, что в итоге приведет к падению мотивации. Но да, проще не думать а дать человеку эти 40%, как в топку уголька подкинуть.
                                                          0
                                                          +40% — это аналог -28% в случае дефолта по времени и качеству.
                                                          А вы, на моё мнение, слишком эгоцентричны. ПМ не менее проффессионал, чем программист. И не факт, что менее нужный.
                                                          Да и если ПМ работает с большинством программистов успешно…
                                                            0
                                                            ну ПМ-а я как пример привел. Мало что может снижать мотивацию программиста. Может у него место рабочее неудобно, или монитор плохой, или кондиционера нет. Это уже ПМ-у разбираться.
                                                              0
                                                              у него очень неудобно руки растут -D
                                                              (простите не удержался))))

                                                              ну, команда пока не устоявшихся, так что приняли решение не тратить на него время в поиске «красивых мониторов»
                                                    +1
                                                    ИМХО, Agile-методики (тот же Скрам) применять есть смысл только в хорошо сработанных командах опытных разработчиков, которые реально представляют себе, сколько они могут сделать за очередной спринт, и не навалят в TODO кучу тасков.
                                                      –3
                                                      поверте у нас в команде не ламеры собраны
                                                        0
                                                        Одна из целей Agile — сделать из коллектива комманду за относительно небольшое время.
                                                          0
                                                          Одна из целей Agile — сделать из коллектива комманду за относительно небольшое время.
                                                            0
                                                            Одна из целей Agile — сделать из коллектива комманду за относительно небольшое время.
                                                              +1
                                                              Товарищи из администрации «Хабры». Я засёк один из случаев дублирования комментов: пишем коммент в браузере «Опера», отправляем, потом нажимаем «Пробел» (я его жму для прокрутки страницы).
                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                  0
                                                                  Не должны, а дублируются.
                                                                    0
                                                                    Не должны, а дублируются.
                                                                      0
                                                                      Только что попробовал. Легко воспроизводится.
                                                                      0
                                                                      Пожалуй, не самое удачное место для обращения к администрации :)
                                                                        +2
                                                                        Да я им куда только не писал.
                                                                  0
                                                                  По крайней мере, в XP есть тоже предварительная оценка задачи и планирование. Причем, в XP как раз есть принцип, что трудоемкость оценивает программист, который делает задачу.

                                                                  xprogramming.com.ua/planning.php
                                                                    0
                                                                    Ага. Только он это делает на в JIRA а во время игры в планирование
                                                                      0
                                                                      То есть если бы вас попросили писать трудоемкость на бумажных карточках, вы бы это приняли?
                                                                        0
                                                                        Я так не раз делал. Очень удобно.
                                                                          0
                                                                          я не очень понимаю в чем проблема: в перечне нововведений я вижу только 2 пункта, которые возлагают на девелопера две обязанности:
                                                                          1. Ввести оценку времени выполнения
                                                                          2. Ввести предполагаемый срок выполнения

                                                                          Почему эти две вещи вызывают такое неприятие по сравнению с написанием их же на карточке?

                                                                          Джира настолько неудобно, что заполнить там два поля очень сложно?
                                                                            0
                                                                            Потому что эти 2 пункта ИСКЛЮЧАЮТ игру в планирование, или скрам-митинги. Это означает, что мы меняем все приемущества практик коллективного планирования, на удобство менеджера, который не вставая с места будет получать сроки по задачам. Дело не в том что мне сложно проставить эти строки, а в том что соглашаясь на это, мы теряем кучу приемуществ практик планирования Scrum и XP
                                                                              0
                                                                              А что у вас уже внедрено, игра в планирование или скрам митинги? Почему занесение в джиру исключает перечисленные игры? Оно не может их дополнять?
                                                                                0
                                                                                У нас этого не внедрено. Было но похерили. Теперь новый техдир пытается внедрить свои методы.
                                                                                Почему исключает объясняю. Дело в том что если есть скрам-митинги то не нужно то что предлагает техдир. В этом просто нет никакого смысла. Так что дополнять оно их не может. Оно может только дублировать.
                                                                                  +1
                                                                                  А что именно было — скрам или XP?
                                                                                  Похерил новый техдир или до него? Почему похерили? Не могли бы вы порекомендовать что-то про планирование в скраме типа книжки «Экстремальное программирование: планирование»?
                                                                                  (Там есть аналог team velocity?)

                                                                                  Новый техдир в курсе, что есть скрам и XP, вы говорили с ним про это?

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

                                                                                    0
                                                                                    1. Было XP. Но не полностью, а то что позволяют мои полномочия. Игра в планирование проводилась без участия заказчика. Но все равно это эффективнее чем обычное последовательное выполнение задач без итераций и контрольных точек.
                                                                                    2. Похерил ПМ. Я распланировал, и уехал в отпуск, передав расписанные планы ему. Когда вернулся увидел что за 5 дней из плана не сделано ничего, а люди занимались рефакторингом. Пришлось за последнюю неделю вкалывать полной что бы успеть к концу итерации сделать хотя бы основные задачи. На мои вопросы почему похерили план ПМ невнятно промычал что итак все нормально. Ну раз нормально, давай работать без плана сравним эффективность. После этого все пошло через жопу.
                                                                                    3. По Скраму не знаю. В принципе XP включает почти все техники скрама, разница в деталях.
                                                                                    4. Можно, ктож против. Вот пусть сам и вносит если это ему надо. Но я бы ему не советовал так как по хорошему план надо бы показывать заказчику и вешать на стену что бы он всегда мог посмотреть, а каждый день обновлять и JIRA и план это двойная работа. Тем более мне непонятно как в JIRA удобно отмечать прогресс по задаче. Но это уже не мои проблемы, если ПМ мазахист, это его проблемы.
                                                                                      0
                                                                                      А где вы накапливали статистику, чтобы скорость команды считать?
                                                                                        0
                                                                                        Эту практику внедрить не успели, пока итераций мало, можно просто вводить поправочный коэфициент для каждого программиста на основе результатов последней итерации. Получилось, кстати, очень интересно. По итогам первой итерации, из 4-х, на тот момент программистов, 2 уложились в сроки, что называется, на флажке, один отстал, и один сделал все быстрее. Это четко было видно по плану. Но так как один человек из команды справился раньше, он помог тому кто не уложился. При анализе стало понятно причины такого расклада. Опоздавший просто последние года два программировал на C++, и подзабыл Java, а тот кто сделал быстрее лучше всех нас знает те фреймворки что мы применяем. Поэтому решил на следующую итерацию не вводить коэфициентов. Тот кто опоздал уже Java вспомнил, значит сделает быстрее. А наш гуру пусть будет как подстраховка, если опять сделает раньше, поможет другим. На следующую итерацию мы все опять успели в сроки к презентации, правда пришлось покоцать задачи из за 5-и дневного рефакторинга непонятно с какого перепугу проведенного.
                                                                                        Потом отдал процесс в руки ПМ-а и все. С тех пор никто не видел ни одного плана.

                                                                                        Но если бы понадобилась точная статистика, а она бы понадобилась со временем, то получить её всегда несложно из старых планов, хранящихся в свн. Так же можно удобно использовать wiki для хранения планов по итерациям и статистики.
                                                                                          +1
                                                                                          я правильно понял, что все было так:
                                                                                          1. вы внедрили частично XP (кстати, какая у вас роль — ведущий программист?)
                                                                                          2. ПМ его похерил
                                                                                          3. Новый техдир пытается наладить хоть какое-то планирование

                                                                                          Новый техдир не знает или не считает XP целесообразным. Вы говорили с ним по этому поводу?
                                                                                            0
                                                                                            Вы поняли правильно. Роль да, ведущий программист, но это название ничего не значит, никаких отличий или полномочий нет.

                                                                                            я не хочу пока общаться с новым техдиром. Я думаю что первая задача техдира познакомится с разработчиками. Каюсь, он раз меня позвал познакомится, точнее для того что бы я объяснил ему архитектуру. Меня и одмина. Я сказхал что не плохо бы было пригласить и других программистов. Пригласили, ребята хотя бы познакомились.
                                                                                            Но что-то он внедрить пытается. Хотя что я понятия не имею. ОН с нами не общается и даже не здоровается пока сам руку не протянешь.
                                                                                              0
                                                                                              а каковы роли техдира и пм'а, почему техдир хочет планирования, а ПМ — нет?
                                                                                              Вообще надо с тездиром говорит или менять техира, если вас принципиален ввод двух чисел в жиру
                                                            –5
                                                            Я то понял для чего все это. Мне непонятно причем тут JIRA. Аналитика нужна и полезна, но почему нельзя руководствоватся данными планов? В начале итерации распределены задачи, оценены. Прогресс смотрим ежидненвно. По итогам итерации анализируем. Мне непонятно зачем в JIRA версии если версии должны определятся по набору запланированных фич в начале итерации и по количеству их реально выполненных вконце. Для чего здесь понятие компонент? Подзадач? Эти вещи вообще каккой имеют практический смысл?
                                                              +9
                                                              почему нельзя руководствоватся данными планов?
                                                              потому что есть планы, а есть реально потраченное время.

                                                              В начале итерации распределены задачи, оценены. Прогресс смотрим ежидненвно. По итогам итерации анализируем.
                                                              А вы уверены, что через месяц вы вспомните подробности итерации? Какие задачи были недооценены, а какие наоборот — переоценены?

                                                              Для чего здесь понятие компонент? Подзадач?
                                                              На это уже ответил выше suglosta

                                                              Эти вещи вообще каккой имеют практический смысл?
                                                              Имхо, да
                                                                –7
                                                                1. Планы ДОЛЖНЫ отражать реальную ситуацию в каждый момент времени.
                                                                2. А какая разница какие задачи сколько времени делались? Главное сколько было потрачено времени на всю итерацию. Этих данных достаточно для оценки эффективности работы программиста. Но в любом случае ПМ или там Тимлид должны ежедневно контроллировать процесс, таким образом у них эта информация все равно будет, так как они корректируют план ежедневно, и если им интересна история, можно например загнать планы в svn
                                                                3. Опять же информация по подзадачам должна быть у тимлида на карте(в екселе где угодно). Программер итак знает как он будет делать задачу, и тимлид просто интересуется каждый день какие из подзадачь в каком состоянии. Так он будет еще и контроллировать, кроме общего хода работ, любые изменения в процессе и влиять на него (часто некоторые подзадачи можно отложить, если не укладываемся в сроки, но делать это надо своевременно).

                                                                Мое мнение что
                                                                1. JIRA не для этого мусора интересного только ПМ-у и тимлиду
                                                                2. Это попытка облегчить себе работу.
                                                                3. Такой подход расслабляет, можно не общаться каждый день с программерами, можно не контроллировать процесс, все есть в JIRA
                                                                4. Это может побудить к перекладыванию некоторой отвественности на плечи программистов
                                                                5. Это использование сложного инструмента взамен простого
                                                                6. Процесс либо будет дублироваться либо будет недоступен для заказчика, который не хочет ничего знать о JIRA и это его право.
                                                                  +6
                                                                  Вы идеалист.

                                                                  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 разработки. Может кое-что перекручено, но нормально. Главное — это заставить рзработчиков-раздолбаев заносить все правильно и в срок.

                                                                  З.Ы. извините за не самую цензурную лексику
                                                                    0
                                                                    Вы не поняли наверное
                                                                    >1 — х*й. планы с реальностью совпадают на очень недолгом промежутке времени.

                                                                    Я не горю что они сами по себе будут совпадать. Их надо поддерживать, и корректировать ежедневно.

                                                                    2. Это время необходимо учитывать. Есть идиальная оценка а есть реальная, которая строится с учетом рисков. Сначало можно просто умножать на 2-3, потом, когда соберется статистика, можно вычислить и более точный коэфициент. Почитайте XP там об этом сказано.
                                                                      0
                                                                      ИМХО — то что вы имеете в виду — это как раз отчет по версии это и будет тем самым планом. Есть estimate, есть n разрабов, есть m незакрытых тасков. Есть estimat'ы на текущие таски.

                                                                      я скорее не догоняю, что не нравится в схеме, я не вижу сильно излишней формализации, кроме может еженедельного релиза версии и 3 пункта.
                                                                        +1
                                                                        Хм. Посмотрите с точки зрения разработчика на 2 и 3ий пункт.
                                                                        Вот к примеру я, разработчик-раздолбай. У меня есть 5 незакрытых задач, по которым мне надо произвести работы. Приходит ПМ, весь такой модненький, говорит — чувак, гляди. У нас есть новая задачка. Сделай ее по workflow. Окей. Я смотрю — ха, ну, задачка то дерьмо, сделаю быстро. Но я ведь хитрый, я не люблю большого брата. Срок поставлю больше, чтобы прикрыть свою задницу и успеть сделать какую-нибудь ту из пяти задач.

                                                                        Я к тому, что разработчики будут врать в свою пользу, какими бы прилежными они не были. Поэтому я согласен, что здесь имеет место быть перевод ответственности с ПМа на разработчиков. Причем, сам же ПМ подставляется. В худшем случае он разработчиков уволит, он и новую работу найдут, потому что они производят код, а ПМ будет с пробитым проектом.
                                                                      –2
                                                                      1. 7 +- 2 если следовать Скраму. Если почитаете Джоэл о программировании то увидите что и там советуют эксель. Если разработчиков больше, стоит подумать о разделении на отделы, как поступают многие крупные компании, в том числе и майкрософт.

                                                                      2. Конечно правильно. Только мне честно плевать на проблемы ПМ-а, и я не готов облегчать ему работу за свой счет. В итоге продукт производим мы.

                                                                      3. Так и будет. Если раньше и без жиры я мог месяц делать вид что работаю и это оставалось незамеченным, потому что даже никто не спрашивал а что я вообще делаю, и сколько времени осталось. А я мог позволить, так как никому никаких сроков не называл. Когда будет все на блюдичке, ПМ вообще из своего угла будет выходить только в туалет.

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

                                                                      5. Нужна, согласен. Хотя я бы использовал бы eTraxis.Но она нежна нам, программистам. И как ПМ будет неуспевать если он даже не начинал. Вот пусть начнет а потом придет и скажет я не успеваю, наймут еще одного. А сейчас он вообще ничего в голове не держит, и даже не пытается.

                                                                      6. Опять вы меня не поняли. Для заказчика должен висеть план на стене, и презентация раз в месяц. Жира ему не нужна. Поэтому если ПМ будет вести все дела в Жире, ему придется переносить всю информацию отдельно в тот же эксель или мс проджект, для того что бы показать заказчику, и поддерживать оба варианта.

                                                                      agile-like разработкой тут и не пахнет. А разработчики — раздолбаи все равно ничего заносить не будут. Я иак и сказал что менять ничего в своей работе с жирой не буду. По крайней мере пока не уижу других, шагов по улучшению процесса.
                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                          –2
                                                                          вот опять виноват программист
                                                                            0
                                                                            вы забыли про отношение к ПМ
                                                                            так что причин больше :)
                                                                    0
                                                                    версия — это та-же итерация. так что все к месту. на версию намечаются некий набор фичей. они реализуются. По релизу версии раздаются люля тем, кто профакапил поставленные задачи, оставшееся переносится на след. итерацию.
                                                                    +14
                                                                    Вот как раз читаю славного дядьку Стива Макконнелла и его руководство по выживанию. Он предупреждал, что формализация процесса разработки будет вызывать сопротивление людей, с ней не сталкивавшихся. Я ему в принципе верил, но теперь вижу воочию.

                                                                    Имхо, классный мужик — этот ваш техдир. И продуктивносьт команды увеличится. Если, конечно, все будет применено на практике так, как описано.
                                                                      +1
                                                                      Я не против формализации, и мало того я каждый день горяю что у нас нет процесса, и первый выступаю за его наладку. Мало того в начале проекта я сам занимался этими вещами, планированием, распределением задач, контролем, и мы четко укладывались в сроки, и процесс был налажен. Потом задачи разработки и уход в отпуск вынудили переложить эту ответственность на неумеху ПМ-а. После этого все пошло крахом. Но опыт наладки процесса у меня есть и я только за формализацию обоими руками.
                                                                      НО формализация ради формализации — зло. А здесь, возникает ощущение что хотят все сделать правильно, но не знают как, или не могут избавится от стереотипов.
                                                                        +2
                                                                        Лично я не вижу тут излишней формализации.
                                                                        Имхо, это просто подход отличный от вашего, о котором вы знаете, что он эффективен. Что и вызывает у вас неприятие. И я вас прекрасно понимаю. Может, стоить обсудить с техдиром? Иди это невозможно?
                                                                          0
                                                                          Обсудим. Сейчас обсудили с ПМ-ом. Он не отрицает что это все нужно лично ему, и типа от программеров не потребуется ничего делать. Но тут же в разговоре выясняется что делать таки придется, «ну этож мелочи» как он говорит. Вообщем, я ему сказал делай с JIRA что хочешь, только, что бы нас это не касалось. Он просто не понимает что пытается подменить Жирой личное общение и не понимает чем это грозит. И есть у меня чувство что хорошим это не кончится. Будут вопросы потом к программистам: почему не отметил время, почему не закрыл подзадачу, почему не отметил изменения в подзадачах и т.д.

                                                                          Пока я ему предложил встречный вариант — ежедневная отчетность. У нас даже есть инструмент для этого, только им никто не пользуется. Он согласен, что отчетность нужна (типа что сегодня делал и сколько времени ушло), но пока недопонимает, что это полностью удовлетворяет его потребностям в аналитике и при этом занимает у программистов максимум 15 мин времени причем в конце дня когда вся работа закончена, не отвлекая. Теперь решение за техдиром.
                                                                            +4
                                                                            осторожнее :) у меня уже есть личный пример нескольких компаний, где введение ежедневной отчетности привело к развалу компании не больше чем через 2 месяца. исключений пока не было
                                                                              0
                                                                              У меня есть пример когда отчетность в которой норма, и компания жива до сих пор)) Это РБК
                                                                                0
                                                                                не упоминая о том, что эта компания имеет сейчас серьезные проблемы с финансами и не упоминая того, что помимо IT холдинг имеет активы в других областях хочется спросить — вы уверены, что ежедневная (!) отчетность внедрена во всем холдинге без исключений?
                                                                                  0
                                                                                  Не во всем. Интернет проекты не отчитываются, например.
                                                                                    0
                                                                                    Как раз интернет проекты отчитываются это точно. Про остальные отделы точно не знаю.
                                                                                      0
                                                                                      я вот как раз насчет интернет-проектов не уверен, тк на собеседовании года два назад мне говорили, что в интернет отделе (одном из?) снижают уровень бюрократии специально чтобы повысить мотивацию. но у меня данные невалидные и только по одному из интернет-направлений
                                                                                        0
                                                                                        точно говорю потому что я там проработал почти 2 года. но вы правы там несколько направлений. я работал в департаменте развлекательных сервисов.
                                                                                    0
                                                                                    сейчас все имеют проблемы с финансами, и не потому что пишут отчеты а потому что кризис
                                                                                      0
                                                                                      все имеют проблемы на уровне банкротства? :)

                                                                                      впрочем я согласен с тем, что отчеты на это не влияют. скорее политика компании влияет и на отчеты и на состояние самой компании…
                                                                                        0
                                                                                        верно я понял что компании требующие отчетов имеют меньше шансов стать банкротом в условиях кризиса?
                                                                                          0
                                                                                          *требующие = не требующие
                                                                                            0
                                                                                            формально — нет конечно :) что с поправкой что нет. я не думаю, что тут есть прямая связь

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

                                                                                            ps естественно, речь идет о минимизации именно бюрократии в плохом смысле слова, а не необходимой документации.
                                                                                              0
                                                                                              то есть надо свернуть так же и бухгалтерскую отчетность, не просить заявлений на отпуск, увольнение, забить на больничные, командировочные талоны? Это ведь тоже бюрократия. Тогда точно шансы выжить в кризис повысятся.
                                                                                                0
                                                                                                я же написал — «кроме необходимой документации»

                                                                                                все бумаги бухгалтерии, а также заявления на увольнение, например, проверяются налоговой

                                                                                                а вот зачем писать бумаги, без которых можно обойтись...?
                                                                                                  0
                                                                                                  я же писал выше что конкретно в РБК эти отчеты нужны для аудита
                                                                                                    0
                                                                                                    расскажите тогда подробнее как и куда уходят и обрабатываются эти отчеты?

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

                                                                                                    и причину почему эти отчеты нельзя собирать из других источников
                                                                                                      0
                                                                                                      да откуда я знаю. нам было сказанно что отчеты нужны для оцкенки капитализации компании которая нужна для аудита. я не экономист и в детали не вникал. аудит не внутренний а внешний.

                                                                                                      я не могу представить других источников кроме как генератора случайных отчетов.
                                                                                                        0
                                                                                                        «Рыночная капитализация (англ. market capitalization) акционерной компании — это стоимость всех её акций, то есть цена, которую необходимо было бы заплатить в случае её покупки (если не учитывать изменение цен акций в процессе их скупки). Вычисляется данная величина как произведение цен акций на количество выпущенных акций.»

                                                                                                        «Аудит (аудиторская проверка) — независимая проверка бухгалтерской отчётности с целью выражения мнения о её достоверности.»

                                                                                                        отчеты программистов тут не при чем, боюсь, что вам ляпнули первое что пришло в голову или что пришло в голову начальству когда менеджеры спросили «а как это людям-то объяснять?». я бы при этом подумал бы что в такой компании работать не стоит.

                                                                                                        источников полно: SVN (коммиты), багтрекер, план работ вместе с отчетами тестировщиков, сводная статистика по покрытию кода, метрики по коду, отчеты о релизах в том числе внутренних, отчеты ночного билда итп…
                                                                                                          0
                                                                                                          отстаньте от меня. я ничего не понимаю в этой кухне. было сказанно что отчеты нужны для аудиторских проверок, я склонен в это верить, но наверное вы лучше знаете.
                                                                                                0
                                                                                                но в принципе я понял, что отчеты если и виноваты в проблемах РБК то это очень малюсенький процент в общих причинах кризиса.
                                                                                                  0
                                                                                                  так я и не говорю, что виноваты :)

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

                                                                                                  было бы странно думать, что в моем изначально высказывании была мысль о том, что именно каждодневные отчеты являются причиной кризиса компании :)
                                                                                        0
                                                                                        Какаяж там отчетность? Там просто мыло для начальства, что ты не прогуливаешь.
                                                                                          0
                                                                                          Нет эта штука используется для оценки капитализации. Мы писали туда нормальные отчеты а не то что «тут был Рома»
                                                                                        0
                                                                                        Ну, я щас живу с ежедневной отчетностью. Но там отчетности список сделанного + время в офисе. Это — нормально, хоть поначалу непривычно и лениво.
                                                                                          –1
                                                                                          большего и не надо
                                                                                            0
                                                                                            чтож, у меня другое мнение и я не считаю это нормальным

                                                                                            мне кажется, что такая отчетность не имеет права на существования в любой организации не только по причине того, что на нее тратится время рядовых и не только сотрудников (можно в каждом случае подсчитать сколько времени и денег уходит на заполнение + «перестройку» на эту задачу, плюс время на обработку в месяц в компании), но и по причине того, что в случае когда менеджеры среднего звена без такой отчетности не знают что творится у них в отделе\проекте — таких менеджеров надо увольнять.

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

                                                                                            зы я конечно не имею ввиду автоматические средства сбора информации типа баг-трекеров если мы говорим об IT. точнее, статистику, на них построенную.
                                                                                              0
                                                                                              просто неп надо впадать в крайности. Отчет должен заполняться минут 15 максимум в максимально свободной форме. Да и нужен он скорее для самоконтроля, и для самоотмазки типа «что я делал все это время? так вот посмотрите»
                                                                                                0
                                                                                                не, крайность — это ежедневный отчет :) еще раз скажу, что вы учитываете в такой формулировке только себя и свое отношение. и это хоть и правильно для вас, но в целом такое решение неэффективно.

                                                                                                поясню:

                                                                                                всю информацию о моей деятельности как программиста можно собрать в трекере и «свн» в конце недели менеджеру в сводном отчете одной кнопкой. а в случае 15и минут для заполнения получается еще скажем 15 минут на «переключение» в среднем, те полчаса в день. для компании из 16и человек, включая всех кто связан с этими отчетами, можно уже нанять еще человека вместо написания отчетов.

                                                                                                это еще не учитывая то, что сбор, обработка и перенос в цифровой вид (если отчет на бумаге) ежедневной (!) информации в свободной форме занимает времени больше 15и минут…

                                                                                                а для самоконтроля лучше подходят тайм-трекеры если очень уж хочется себя контролировать или недельный список задач на бумажке с написанными рукой за 5 минут временными рамками, если контролировать себя надо меньше. и такое решение позволяет всем (!!! а не только тем, кому нравится самоконтроль) сотрудникам не чуствовать себя механизмами, а также позволяет не задумываться о том, что все эти отчеты никто и никогда не читает (дада!) и нужны только для поддержания видимости трудовой дисциплины.

                                                                                                те с моей стороны крайности может быть две — ежедневные отчеты и отсутствие какого-либо контроля вообще. все остальное зависит от кучи факторов, как то: задачи, коллектива, количества людей в команде итп…
                                                                                          +3
                                                                                          Ежедневная отчётность? Нет.
                                                                                          Знаю по себе и тем, кем довелось руководить. Бывает у человека весь день голова болит и он толком ничего не делает, а бывает как на крыльях за день делает то, что требовалось за неделю.

                                                                                          А при ежедневной отчётности неуспевающие стараются создать иллюзию деятельности.

                                                                                          Уж лучше чёткий набор задач на неделю давать.

                                                                                          Что касается проблем с внедрением… да я когда внедрял SVN и Мантису на меня долго все матерились, включая начальство, которому видите ли «некогда создавать там тикеты и вообще проще сказать словами»

                                                                                          Ничего, привыкли.
                                                                                            0
                                                                                            если у вас такой стиль разработки и вы укладываетесь в сроки, то так и пишите «болела голова ничего не делал». Если в итоге вы удовлетворяете всех, то никто и слова не скажет. В отчетах главное честность.
                                                                                              +1
                                                                                              Человек такое существо, скажу я вам, склонное ко всяким нехорошим поступкам. У меня всё проще сделано — SVN логи. По ним всё прекрасно видно, не только комментарии программиста но и список того что он делал.

                                                                                              Сделать срез по отдельному дню проще простого. Хочется правда к этому и веб-интерфейс и багтрекинг, а Trac правда мне как-то не приглянулся, у него всё плохо, когда есть много мелких проектов. Придётся либо искать что-либо готовое, либо писать своё.
                                                                                            +5
                                                                                            Отлично. Просто отлично! Вы выступаете против какой-то там излишней бюрократии, но за какой-то там левый инструмент, которым никто не пользуется (и никто не будет) — вы двумя руками за! Инструмент отчётности лично для менеджера, оторванный от workflow — это и есть большое зло, против которого вы так рьяно тут выступаете.

                                                                                            JIRA же худо-бедно уже встроена в ваш процесс, так я не вижу причин почему бы не расширить её функционал — пускай она выступает инструментом отчётности для менеджера, а не только issue-трекером.

                                                                                            Теперь по пунктам:

                                                                                            1. Версии — это вообще основа основ итерационного метода разработки. Благодаря версии становится понятно, а что же мы такого релизнули в пятницу (тестировщики видят, что тестить). Благодаря версии становится понятно в какой версии тестировщики нашли баг. Благодаря версии менеджер ставит приоритеты — в какой версии, что нужно делать (это нужно срочно, это подождёт пару недель, этим вообще надо заниматься только когда багов не будет). И всё это вы получаете ровно за 1 клик (!) при создании и закрытии тикета.

                                                                                            2. Сабтаски нужны затем, что не всегда менеджер и тестировщик могут определить границы ответственности. Но задача есть и её нужно решить. Разработчик, которому назначен таск, видит несправедливость — в задаче есть пункты, которые вообще не в его компетенции — так он создаёт сабтаск и назначает его на нужного человека.

                                                                                            3. Компоненты нужны для быстрого ориентирования в проблемах. Тестировщик указывает в задаче компонент, в котором он нашёл баг (ровно 1 клик). Программист с одного взгляда на список тикетов понимает про что этот баг, потому что там указан компонент. Менеджер знает приоритеты по компонентам, а также может определить проблемные компоненты (в каком-то слишком много багов — может стоит поручить техлиду сделать ревью, вместо того чтобы программисты делали локальные фиксы? а какой-то компонент может недостаточно широко тестируется (слишком мало заведено тикетов)).

                                                                                            4. Estimated time каждой задачи нужен для общей оценки проекта. Пускай каждый проставит время (пусть и оторванное от реальности) для своих задач, но у менеджера появится инструмент: для отслеживания общего срока проекта, для выбивания больших ресурсов из директора (оперируем в понятных директору человекочасах), для оценки количества работ по компонентам, для оценки количества работ по версиям (ежу понятно, что если на текущую версию требуется 100 человекочасов, у меня 5 человек, а релиз версии — послезавтра, то всё мы не успеем, что-то (что не было обещано заказчику к этой пятнице) надо перенести на следующую версию)

                                                                                            Единственное, что мне не нравится в письме вашего ПМ, так это «Срок исполнения». По-моему, он действительно лишает команду (в том числе и самого ПМ гибкости). Вот я приступил к задаче, проставил срок исполнения, в процессе появились более приоритетные задачи, я отвлёкся на них, соответственно срок исполнения первой задачи съехал, надо исправить. В итоге можно закопаться в этих сроках (при этом особых задач они не решают, к тому же могут ещё и навредить, как менеджеру, так и разработчику)

                                                                                            PS — А инструмент отчётности, про который вы говорите — он лишний. Что я сделал и сколько было потрачено — всё это программист «пишет» автоматически в процессе работы — делая коммиты в SVN, указывая в комментах id тикета в JIRA). Вы научите менеджера «читать» такие отчёты — ему 100% понравится :)
                                                                                              –1
                                                                                              Про свн насамо деле верно, но многие программеры не пишут внятных комментов. Многие комитятся раз в неделю. Это неправильно, но кто должен решать эти вопросы? Я. Хрен там, у меня других задач погорло. ПМ? Да он в этом не разбирается, а любое преложение откладывается в долгий ящик. Может вот техдир таки введет такую практику.
                                                                                              По поводу отчетности. Например в РБК она используется для оценки капитализации компании для аудиторов. Без них никак. Но я совсем не настаиваю на такой системе. Она предложена лишь как некий компромис. Гораздо проще потратить 10-15 мин в конце дня, чем отвлекаться 10 раз за день на минутные вопросы. И чтоб не засерали JIRA.

                                                                                              В целом то что вы написали, это верно и я не спорю. И про версии и про сабтаски. Но все это должно быть не так как. Все это должно автоматически выходить из процесса а не навязываться свыше в отрыве от других практик. И я ппротив что бы этим засерали JIRA
                                                                                                +1
                                                                                                Описываю отлаженный процесс:

                                                                                                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 часов и мысли уже дома на диване поедают китайскую лапшу и смотрят свежескачанный торрент, то на всю эту «непринуждённую» процедуру мысли забьют, а мозгу на вопрос «какого х?» ответят: «да завтра с утра первым делом отпишем, ничё страшного».
                                                                                                  0
                                                                                                  Можно и с утра.
                                                                                                    0
                                                                                                    Можно и с вечера, и с утра, и каждый час, и после обеда, и каждую пятницу. Разумеется, можно. Только зачем?

                                                                                                    Ваша процедура «оформления отчётности» — оторвана от рабочего процесса. В моём варианте — она вшита в процесс.

                                                                                                    Сразу скажу, что процедура «что делал — сколько времени» — есть и в фирме, где я работаю. Но нужна она не ПМ, а бухгалтерам — для расчёта переработок и отгулов (как вы знаете, эта информация влияет на размер заработной платы, а с деньгами никто шутить не будет — поэтому процедура «навязана сверху»). Но «отчёт» выглядит так: «эту неделю я работал 40 часов в проекте X» или «30 часов в проекте X, 5 часов в проекте Y, ещё 5 часов — обучение». Менеджеры проектов кивают бухгалтерам — да действительно столько часов. А бухгалтерам нужно только кол-во часов, какие задачи ты выполнял — им параллельно.
                                                                                                      –2
                                                                                                      Я уже сказал что отчеты не насущная необходимость но варианты с JIRA и SVN ще хуже. В принципе можно легко обойтись и без всех трех, но отчеты это как компромисс, не более.
                                                                                                      JIRA у меня не открыта постоянно, я прекрасно знаю что от меня требуют, потому что всегда обсуждаю задачу с ПМ-ом, читать мне её нет смысла. JIRA только как напоминалка, что бы не забыть список своих задач.
                                                                                                        +2
                                                                                                        Значит вы используете инструмент не по назначению, только и всего.

                                                                                                        Если я всю жизнь забиваю гвозди топором, а потом мне говорят — теперь им ещё и дрова надо рубить, то это вызовет справедливое возмущение с моей стороны (потому что мне покажется, что на меня вешают лишнюю работу).
                                                                                                          0
                                                                                                          А вы MS Office используете на всю катушку?
                                                                                                            +2
                                                                                                            Я использую его по назначению. Оформляю документы (оочень редко) и читаю корпоративную почту.

                                                                                                            Использовать по назначению и использовать на полную катушку — разные вещи, согласитесь.
                                                                                                              0
                                                                                                              Разные, согласен, а я что через JIRA в интернет хожу или почту проверяю? Нет, она используется для постановке задач, как нормальный трекер. То для чего она предназначена как раз. Между прочим думаю со временем мы перейдем на другой трекер, возможно Track или eTraxis и что делать?
                                                                                                                +1
                                                                                                                > JIRA только как напоминалка, что бы не забыть список своих задач.
                                                                                                                это ваши слова.

                                                                                                                > она используется для постановке задач, как нормальный трекер
                                                                                                                Так почему в вашем трекере нельзя отследить версии, компоненты, сабтаски и estimated time? нормальный ли это трекер? нет.
                                                                                                                  0
                                                                                                                  наверное можно. Но в нормальном процессе версия планируется зарание как набор фич которые нужно реализовать в определенную дату. Дата пришла, сделали билд, в свне поставили метку с номером версии. Причем тут JIRA?
                                                                                                                    +4
                                                                                                                    Есть 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
                                                                                                          +2
                                                                                                          Кстати, вот вы написали в исходном посте, что когда фиксите баг, то «переводите его в проверку» JIRA, а значит сейчас говорите неправду, что очень трудно лезть в JIRA и смотреть айдишник.

                                                                                                          И ещё одна заметку походу: правильное использование JIRA избавляет от необходимости обсуждать каждую задачу с ПМ-ом. Экономит кучу времени — проверено. С ПМ-ом надо обсуждать фичи, которые имплементятся задачами, но не сами задачи. А новые фичи возникают в проекте гораздо реже задач.
                                                                                                            0
                                                                                                            конечно же открываю что бы перевести задачу. Но делаю это после комита. Консоль всегда открыта, закомитил, потом потестил, потом открыл JIRA и перевел задачу.

                                                                                                            Да, использование JIRA избавляет от необходимости общения, но именно с этим я и борюсь. Общение необходимо. Все задачи все сроки должны назначаться в ходе личного общения а не через JIRA
                                                                                                              +2
                                                                                                              1) Представьте, что ПМ уехал в заграничную командировку — встречаться с клиентом — работа разработчиков встанет, общаться-то не с кем.

                                                                                                              2) Хороший ПМ ведёт сразу несколько проектов — во всех них общаться по срокам и задачам — да вы что. У него мозг взорвётся от такого общения.

                                                                                                              3) Все эти общения-собрания-совещания — это как раз никому не нужная бюрократия. У вас процесс превратится в общение. За это боретесь?
                                                                                                                –1
                                                                                                                1. Кто его туда отпусти. В любом случае будет заместитель
                                                                                                                2. А надо! Впрочем у нас проект пока один. Видимо мы о раазных маштабах речь ведем. У нас не маштаб сайта визитки когда один ПМ может таких 10 вести.
                                                                                                                3. Ну это ваше мнение. Возможно оно от недостатка знаний и опыта. Не буду вас переубеждать, не получится.
                                                                                                                  0
                                                                                                                  1. Как вы себе представляете — вот приходит заместитель — ему надо войти в курс дела, а у вас в трекере — ноль информации? Общаться будете?

                                                                                                                  2. Я тоже не говорю о сайтах-визитках. Какого масштаба у вас проект? Хотя бы сколько человек в нём трудятся? Вы же понимаете, что чем больше человек, тем труднее менеджеру проговаривать задачи и ставить сроки КАЖДОМУ сотруднику?

                                                                                                                  3. Это у вас недостаток совещаний сейчас. Очень вам хочется пообщаться. Когда всё плохо — «первое желание собраться всем вместе и поговорить». Не спорю, что вашей фирме сейчас совещания необходимы — чтобы наладить процесс (потому что, то что вы сейчас описываете иначе как полной ж* не назовёшь). Но совещания на тему, сколько времени займёт выполнить задачу — это бюрократия, лишняя болтовня. Зачем вообще нужны сроки? По-моему вы так и не поняли из моего первого коммента.
                                                                                                                    –1
                                                                                                                    1. Ведущий программист или техдир, которые в курсе всего полюбому. Потом никто не отрицает что у ПМ-а должна быть своя документация по проекту, например в wiki. А вот в JIRA точно разобраться толком не сможешь. Лучше глянуть в общий план где есть вся нужная информация, кто-что и сколько должен делать и на какой стадии находится.
                                                                                                                    2. Проект уровня ну скажем однокласников. В проекте 9 человек. Но вы наверное опять не поняли. Может вам все таки почитать соответствующую литературу что бы быть в теме, а том мы горим об одном а представляем себе все поразомну. Честное слово такое чувство что вы просто думаете что разбираетесь в вопросе а на самом деле нет. Ничего личного.
                                                                                                                    3. см. выше. Прочтите про Скрам, XP, Agile, и книги «Мифический человеко/месяц», «Человеческий фактор», «Джоел о программировании», Раздел посвященный планированию в книге Роберта Мартина «Быстрая разработка программ» и особенно пример игры в планирование в конце книги. Ну это для начала. Тогда сможем пообщаться более предметно.
                                                                                                                      0
                                                                                                                      1. Я про любую систему могу сказать, что в ней толком разобраться не сможешь. Придёт новый менеджер и скажет: «WIKI — фигня, я буду юзать блокнот. Он меня никогда не подводил». Что ему скажете?

                                                                                                                      2. А вы к чему вообще этот пост написали? Вы спросили — «а зачем всю эту фигню менеджер придумал? кто-нибудть это успешно применяет? не хочет ли он нас всех в кювет отправить?». Я ответил — «да применяем, очень успешно». А теперь вы пытаетесь меня убедить, что я не прав? Я работаю в большом проекте (разработка — больше года), команда — 15 человек. Мы укладываемся в сроки, разработчики довольны менеджером, менеджер доволен командой. У вас — всё в точности наоборот. И теперь вы заявляете, что я ничего не понимаю? )) просто смешно звучит.
                                                                                                                      3. Зачем мне это читать? Вы вот прочли, а проект у вас разваливается. Мало читать — надо ещё делать. Менеджер ваш написал умные вещи (и хотя бы пытается что-то исправить) — вы в ответ: «я вот в книжках читал, это всё фигня, давайте общаться». Что конкретного предложите-то?
                                                                                                                        0
                                                                                                                        >Зачем мне это читать?

                                                                                                                        Ну после такого ответа больше вопросов не имеется)))
                                                                                                                          0
                                                                                                                          Эх, кончились аргументы у вас. А жаль — действительно интересная дискуссия за долгое время на хабре.

                                                                                                                          То что вы прочли эти книги — ещё не значит, что вы не стали умнее человека, который прочёл другие книги.
                                                                                                                            0
                                                                                                                            Дело не в этом. Аргументов полно но для того что бы был хотя бы мизерный шанс что вы их поймете и примете мне придется вам прочитать лекции часов на 10, вводный курс. Если бы аргументами было бы так просто убедить человека в правильности той или иной методики, никто бы книги не писал. Согласны? Так какой смысл мне продолжать дискуссию, если шансов вас убедить у меня нет. Это все равно что повар ресторана будет убеждать человека никогда не ходившего в рестораны в том, что он готовит вкуснее чем повар в его заводской столовой. Пока не попробует убедить невозможно.
                                                                                                                              0
                                                                                                                              Ну так сначала напишите ваши аргументы. Потом разберёмся — пойму или нет. Если что-то зацепит в вашей концепции — то разберусь и почитаю. Пока что у вас сплошное отрицание. А сплошному отрицанию сложно поверить.

                                                                                                                              А смысл есть хотя бы в том — что вам ещё вашего ПМ надо убеждать в своей правоте. И директора. Вы же их не пошлёте книжки читать? Даже если пошлёте — они просто посмеются так, по-доброму. Так что придётся обойтись без лекций на 10 часов.
                                                                                                                                0
                                                                                                                                Ну если техдир не читал книг по этой теме и не разбирается в вопросе то наверное и убеждать не буду. Какого черта он тогда пытается ввести методику, даже не имея понятия о других альтернативах. К сожалению мои аргументы не помогут. ПМ-а тоже убеждать не буду, так как даже если он прочтет книги он ничего не поймет. Аргументы пытался приводить но он не понимает их.
                                                                                                                                Поверьте, я бы с радостью попытался вас убедить, но тема и правда настолько сложная что в одном комменте не охватишь, надо ну хотя бы страничек 10 это что бы описать в крации все практики, и проанализировать все аспекты их применения. Некоторые из них касаются непосредственно психологии разработчиков. Ну никак я в двух слова не расскажу.
                                                                                                                0
                                                                                                                А что такого сакрального происходит между коммитом и открытием JIRA, что нельзя поменять эти две атомарные задачи местами? На пустом месте проблемы выдумываете. Только потому что вы так привыкли — никак не должно заботить менеджера.
                                                                                                                  0
                                                                                                                  Вы как часто делаете комиты? 1 раз в конце задачи? А я за задачу могу сделать их много, и часто даже понятия не имею какой из них является последним по задаче.
                                                                                                                    0
                                                                                                                    1. сабтаски (нелюбимые вами)
                                                                                                                    2. ключевые слова (сделал коммит, но нет резолва тикета — напиши «partial PRJ-1235» (да-да, Jira открыть придётся — иначе как понять, решает ли коммит таск полностью или нет?)
                                                                                                                    3. неимение понятия — это как раз от неверного использования инструментов
                                                                                                                      0
                                                                                                                      1. А я не делю никак. Хочу комичу хочу нет. Даже после реинтегрейта в транк могу еще несколько раз комитить если вдруг есть рефакторинг, или баги нашел.
                                                                                                                      2. Ключевое слово здесь я не хочу думать ни о чем кроме задачи.
                                                                                                                      3. это от того что я и не хочу знать когда задача будет завершена. я комичусть инстинктивно, например перед тем как пойти курить или перед уходом домой или просто потому что мне кажется что давно не комитился. Это просто часть рабочего процесса.
                                                                                                                        0
                                                                                                                        Т.е. то что ваш коммит может поломать транк и пока вы там курите или дома сидите, все должны курить — вас не должно заботить?
                                                                                                                          0
                                                                                                                          может, но если тесты прошли значит шансы поломать небольшие, тем более у меня и своя голова есть, я знаю что можно комитит а что пока не стоит.
                                                                                                                            0
                                                                                                                            Что-то я читаю-читаю… и мне за вашу фирму всё беспокойнее и беспокойнее…
                                                                                                                            Честно скажу, будт я вашим лидом, руки бы оторвал затакие «инстинктивные» коммиты.
                                                                                                                            Просто нет слов на самом деле. Так нельзя.

                                                                                                                            Ну что это за «я и не хочу знать когда задача будет завершена»? Это превращаете SVN в помойкукакую то. Вот 7 человек работают над проектом… и каждый и них делает коммит и идёт отлить. При этом никто апдейт не делает и не видит что уже навалилось в транк. Идут часто все человека по 3, покурить поговорить.
                                                                                                                            За разговором выясняется что работали с одними и теми же файлами и конфликт не избежен. Возвращаются, а там ещё несколько чеовек что-то закоммитили, причём комментариев никто естественно не пишет.
                                                                                                                            Скажите сколько вы будете разрешать коллизии? Неделю? Месяц? Полгода? Отложите на потом.

                                                                                                                            Что в результате? У каждого будет какая-то сборная локальная версия, да, возможно рабочая. Но взять это потом и смержить… 7 веток, причём с кучами мелких ответвлений?
                                                                                                                              0
                                                                                                                              Не переживайте. Апдейтится тожа надо часто, а кто не апдейтится сам дурак. У нас все нормально, и такой стиль разработки работает отлично, конфликты редкость, и проблемы не создают. Комменты я пишу, а за другими следить не моя задача. Хотя конечно стараюсь внушение делать. За ветки тоже не волнуйтесь. Всем объяснено что мержить себе в ветку надо почаще, а кто опять таки не мержит тот сам дурак.
                                                                                                                                0
                                                                                                                                Да у вас всё просто отлично. Сроки сорваны правда к чертям.
                                                                                                                                  0
                                                                                                                                  причем тут svn, можно подробнее?
                                                                                                                                    0
                                                                                                                                    Неправильное использование инструментов, отсутствие понимания того что вообще происходит с проектом. Каждый из вас судя по всему живёт в своей «ветке» и нифига не хочет думать об остальных
                                                                                                                                      0
                                                                                                                                      речь вроде об одном инструменте — svn. Уточните как конкретно неправильное по вашему мнению использование этого конкретного инструмента влияет на сроки.
                                                                                                                                      Насчет догадок вы не правы. У нас ветки создаются на большие задачи длительностью более 1 дня и удаляются сразу по завершении. На данный момент в хеаде две ветки.
                                                                                                                                        0
                                                                                                                                        Больше коммитов, больше апдейтов, отсутствует контроль за версиями, не понимание что сделано и что надо делать, что сделано за неделю и кем.
                                                                                                                                        Всего этого вам не хватает и вы хотите «общаться». В результате этого постоянного общения и пролетаете по срокам.
                                                                                                                                          –1
                                                                                                                                          Если вы не знает то есть такой принцип работы с svn при котором комитятся и апдейтятся часто. Это позволяет как раз таки избегать конфликтов. Это очень распространенная а не мной придуманная практика. Если вы о ней не знаете, то учитесь лучше, потому что ваше замечание выглядит очень странно. Все что ниже я не понял как относится к svn
                                                                                                                                            –1
                                                                                                                                            уважаемый, вы наркоман штоле?
                                                                                                                                              –1
                                                                                                                                              как это относится к нашей дисскуссии?
                                                                                                                                                0
                                                                                                                                                Безответственность перед собой и окружающими объединяет таких людей как вы и наркоманов… и часто превращает первых во вторых, к сожалению.
                                                                                                                                                  0
                                                                                                                                                  вы просто ничего не поняли. обьясняю вам подробно. если есть желание понять, то подумайте над этим. если нет, то дальше не читайте, все равно не поймете.

                                                                                                                                                  Итак. В чем приемущество частых апдэйтов и комитов. В том что локальные копии остаются примерно одинаковыми и далеко не расходятся. Таким образом шанс конфликтов снижается. И конфликты разруливать гораздо проще.
                                                                                                                                                  Кстати, если вы не знаете то конфликт, это не ошибка, это нормальное явление для svn. Потому что svn это система основанная на конфликтах, и конфликт это то что является неотемлимой частью свн.
                                                                                                                                                  Но если локальные версии слишком сильно разойдутся, то часто конфликты разрулить будет сложно а иногда практически невозможно. Поэтому для того что бы не создавать проблем другим, комитя результаты недельной работы, комитить нужно чаще, несколько раз в день, что бы они вовремя могли получить ваши изменения.

                                                                                                                                                  Простой пример:
                                                                                                                                                  Вася и Петя работают над одним проектом. Допутим они комитятся редко. Итак Вася правит некий файл, но не комитит. Петя апдейтится, но не получает правок Васи. На следующий день Петя правит тот же файл в том же месте. Теперь можно принимать ставки кто из них получит конфликт. В любом случае тот кто первый проапдейтится.

                                                                                                                                                  А теперь допустим что они комитятся часто. Вася правит файл и сразу его комитит. Петя апдейтится часто, поэтому сразу получает изменения Васи. На следующий день он правит тот же файл и тут же его комитит. Никто конфликт не получит.

                                                                                                                                                  Конечно не надо доводить до фанатизма, и не комитить каждые 5 минут. Нормально комитить более или мение завершенные части системы, конечно если это не нарушает работоспособности кода. Обычно комититится нужно 2-5 раз за день в зависимости от задачи. Это на порядок снижает вероятность конфликтов. У нас они редкость.

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

                                                                                                                                                    Про Петю и Васю напрасно вы, я прекрасно понимаю какие преимущества вам это даёт, уже не говоря о том, что я понимаю и что такое конфликт.

                                                                                                                                                    На вашу историю имею ответ следующего содержания:
                                                                                                                                                    Ребята из Вилларибо апдейтятся каждые полчаса, и коммитятся когда организм не выдержит, а ребята из Виллабаджо грамотно распределяют файлы по версиям и трогают только свою часть транка и ветки, используя svn как систему контроля за версиями, а не как файлообменник.
                                                                                                                                                      0
                                                                                                                                                      и флаг вам в руки.
                                                                                                                        0
                                                                                                                        но не стоит принимать мои слова как полное неприятие этой практики. надо с этим подробнее разобраться. мне просто кажется что при политике частых комитов это применть сложно, в отличии от случаев когда в транк попадают только проверенные вещи, и есть человек за всем этим следящий. как в различных опенсорс проектах. Воопщем допускаю что я не прав, но пока не убежден, хотя заинтересован. Я, будет время, проанализирую преимущества такой практики.
                                                                                                                    0
                                                                                                                    «Консоль всегда открыта, закомитил, потом потестил»
                                                                                                                    А что разрешается непротестированный код комитить???! Как же команда работает? Кто-то комитнул кривой код, другие апдейтнулись и начали дружно кричать матом с утричка=)
                                                                                                                      0
                                                                                                                      Если это новый класс или новый раздел сервиса, то почему бы и нет? Я комичу на основе тестов. Сработали, значит все ок и можно комитить. Что в этом такого плохого?
                                                                                                                        0
                                                                                                                        забаная ситуация, подавлющее число людей вам говорят ваши ошибки, а вы все пытаетесь отмазаться. дело ваше.
                                                                                                                          0
                                                                                                                          только что была ситуация. вроде бы проверил, работает. закомитил код. выгрузили на тестовый сервер, ошибка. Посмотрел логи, нашел ошибку, исправил, проверил что исправлено — закомитил. Нашел еще одну, пришлось менять логику, добавлять поле в БД… И теперь вопрос, как же так я такой падлец комитил 3 раза нерабочий код! Не надо было?
                                                                                                                            0
                                                                                                                            Ну, либо у вас недостаточно отлажено абстрагирование от окружения, либо тесты пишутся от балды. Первое — ппц средней тяжести, второе — имхо хуже, чем если бы тестов не было вообще. Если вы их вообще запускали перед тем коммитом.
                                                                                                                              0
                                                                                                                              а третьего не дано?
                                                                                                                              наверное сообщение стоило бы построить немного подругому, с использованием слова «может» вместо «либо»
                                                                                                                              можно вопрос, вы тесты пишете?
                                                                                                                                0
                                                                                                                                а третьего не дано?
                                                                                                                                Если дано — отлично, я за вас только рад.
                                                                                                                                можно вопрос, вы тесты пишете?
                                                                                                                                Пишу. Правда, после реализации. Это связано и с тем, что не получается спроектировать так как надо сразу. Shame on me, да. TDD внедрить среди себя хочу, но пока не внедрил. Работа над собой веду.
                                                                                                                                наверное сообщение стоило бы построить немного подругому
                                                                                                                                Ну я же исхожу из собственного и известного мне опыта, так? Сходу я вижу две таких причины. Я привёл их выше. Размышлять более подробно на этот счёт не имею ни времени, ни желания. Однако буду рад услышать третью причину, по которой вы три раза коммитили покрытый тестами код, который не работал на staging'е. И поучиться на чужих ошибках.
                                                                                                                                  0
                                                                                                                                  Не в обиду но если вы оправдываете то что не пишете тесты ДО кода потому что не удается спроектировать то вы не понимаете для чего нужны тесты. Полное покрытие это только 1 причина из трех основных.

                                                                                                                                  А баги возникать могут еще по причине
                                                                                                                                  1. Недопонял задачу
                                                                                                                                  2. Тестовая структура БД отличается от реальной
                                                                                                                                  3. Ошибка в интерфейсе
                                                                                                                                  4. Ошибка в функциональной логике а не программной
                                                                                                                                  5. Не полное покрытие тестами
                                                                                                                                  6. Несоответствие реального окружения тестовому

                                                                                                                                  В моем случае была банальная невнимательность, неверно сформированный URL, что относится к причине #3, а второй раз из за того что тесты невзаимосвязанны (это так и должно быть), поэтому ошибка не всплыла, Я просто случайно записывал данные в поле, необходимое для другого. Мой код херил данные другого модуля.
                                                                                                                                    +1
                                                                                                                                    вы не понимаете для чего нужны тесты
                                                                                                                                    Нет, скорее «не умею их готовить».
                                                                                                                                    Мой код херил данные другого модуля.
                                                                                                                                    Неоднозначненько, да. Пожалуй, вы и правда сделали всё, что могли. Хотя в идеале модули также должны быть максимально изолированы друг от друга, воплотить это получается не всегда. Хороший повод написать тест «Working together» :)
                                                                                                                                      0
                                                                                                                                      ну изолировать то модули можно а вот как изолировать от них базу? все таки БД это общий ресурс, и любому классу позволенно юзать любую таблицу. вот и получилось по невнимательности, что я писал в поле, которое предназначенно для другого. но это все рабочие моменты, ничего страшного.
                                                                                                                                      кстати подобных ошибок помогают избежать функциональные тесты, которые по хорошему должны писаться тестерами или заказчиком. но у нас даже тестеров нет какие уж тут тесты.
                                                                                                                                        0
                                                                                                                                        как изолировать от них базу?
                                                                                                                                        Ну, у нас тестовая БД пересоздаётся с нуля и в неё заливаются фикстуры, после чего пускаются собсно юниттесты. Всё это делается одной командой.
                                                                                                                                        Что до функциональных тестов — у нас они есть, но примитивные — на уровне «грузим страницу — смотрим, не упало ли». Но это пока.
                                                                                                                                          0
                                                                                                                                          у нас конечно же тоже отдельная база
                                                                                                        –1
                                                                                                        Пр свн немного не согласен. Никто не будет проставлять ID тикета в комменте. Это еще одно навязывание лишнего артефакта, лишней мелочной обязанности.
                                                                                                          +1
                                                                                                            0
                                                                                                            Ну указывайте в тикете ID ревизии.
                                                                                                              –1
                                                                                                              Зачем?
                                                                                                                0
                                                                                                                Вам — не за чем. Вы не понимаете просто что важно знать какие файлы кем, когда и зачем изменены, вы считаете что сами лучше всех всё знаете.

                                                                                                                Это всё растёт из не умения программировать. Кодить, получать работоспособный какой-то продукт — это одно.
                                                                                                                А программировать — совсем другое. Если у вас общий стиль в именовании переменных? Написание комментариев, документации? Если нет — то вам и СВН особо не нужен.
                                                                                                                  –1
                                                                                                                  сударь, вы меня обидеть хотите?)))
                                                                                                                  я знаю команду svn log и svn blame. Я могу увидеть кто когда и что менял. Зачем меняли — указанно в комменте. Они не настолько подробны насколько хотелось но во всех ситуациях когда я хотел узнать зачем и кто менял код я это выяснял.
                                                                                                                  Насчет именования переменных, это вы тут зачем приплели? Но если интересно отвечу. Да. И не только переменных но и классов и функций. Как и вообщем есть и стандарты кодирования.
                                                                                                                  Документация тоже есть, но основная документация это наши тесты, и имена классов, методов и переменных.
                                                                                                                  Еще вопросы есть?
                                                                                                                    0
                                                                                                                    Нет, вопросов нет, если вы себе противоречите, какие могут быть вопросы.
                                                                                                                      –1
                                                                                                                      каким образом я себе противоречу?
                                                                                                                        0
                                                                                                                        Вот вы говорите:
                                                                                                                        «у нас очень сложная и непонятная ситуация. ведь просрочки были как раз из-за отсутвия процесса, поэтому страдать должны те кто этот процесс должен был налаживать. ведь так?»

                                                                                                                        А мне говорите, мол нет, у нас процесс самый зашибательский, это такие есть методы работы, а вы просто глупы и ничего не понимаете.

                                                                                                                        Виноваты те, которые не смогл организовать процесс, а программисты, не при чём. Пришёл новый человек, увидел это всё, офонарел и попытался хоть как то всё исправить.

                                                                                                                        А вы говорите, мол нет, фигня все ваши методы, мы привыкли без всякой ответственности тут хер знает что делать заниматься высокотехнологичной разработкой своими супер методами.
                                                                                                                          –1
                                                                                                                          просто вы путаете организацию планирования, которыми занимаются менеджеры, и организацию разработки, которой занимаются программисты. так вот в организации разработки у нас все нормально. у нас собраны грамотные программисты которые могут сами для себя выбрать эффективные методы разработки такие как разработка через тестирование, рефакторинг. применить нужные паттерны проектирования, разработать архитектуру, выбрать правильные эффективные инструменты. если у вас этого нет, я вам сочувствую. А вот организовать грамотное планирование не в наших силах, тут нужна