Category: it

tri_lj

В завершение 2017го - про подведение итогов и недосказаные темы

2017й продолжается еще два дня. Я воспринимаю эти календарные дни скорее больше именно с практической точки зрения: мой новый рабочий проект не завершается, а спокойно продолжается 2го января. 2го января - полноценный рабочий день. Сегодня - я тоже немного работала. Завтра - заплыв на 10км, и небольшое путешествие. Нет вот этого выпадания из реальности на 10 дней.

До конца 2017го остается:

  1. Подвести итоги: написать список того, за что я была благодарна в 2017м.

  2. Написать список того, что я не хочу "брать с собой" в 2018, то, что нужно "отпустить".

  3. Написать список из 4х целей или пожеланий на 2018й.

Но осталось в 2017м еще несколько тем, которые хотелось оставить здесь, в жж , на память, записать, но пока так и не удалось:

  • О моих 6ти консультациях с лайфкоучем.

  • О том, как мы попрощались с моим тренером по триатлону и в чем будет разница в 2018м в само-тренировках теперь, с учетом полученых знаний.

  • О том, как важно понятие "Психи́ческое здоро́вье (душевное, иногда — мента́льное здоровье) " , и чем оно отличается от понятия отсутствия болезней.  Что такое психологическое взросление, психологическая взрослость. Как это влияет на развитие и чем развитие отличается от времяпрепровождения. хотела перевести 6 признаков эмоциональной взрослости;

  • О книгах  :


  1. Spinster: Making a Life of One's Own автора Kate Bolick" - "Незамужняя: создание собственной жизни." ,

  2. "Swimming in the Sink: An Episode of the Heart "Плавание в раковине: о движениях сердца" автора Lynne Cox спортсменки Lynne Coxспециализирующейся на плавании в холодной воде .

  3. The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win. - Проект "Феникс". Роман о том, как DevOps меняет бизнес к лучшему Ким Д., Бер К., Спаффорд Д.

Мы можем немного поболтать на эти темы в коментах - на случай, если руки не дойдут до полноценных записей =)

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

trails1
Maverick

Пятничное-рабочее: про RE-WORK, ресурсы, требования заказчика и ASAP

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


Collapse )

Тут хочется выслать в ответ
pamyatka


И так - каждый день изменяется Scope проектов так 10-15ти параллельно.
И это даже не называется умным словом Agile - просто потому, что махина у нас здоровенная, agile-ом не назовешь

Со всем этим я пытаюсь справляться по мере поступления требований и в рамках выданных ресурсов
  • Тыкаю в KANBAN board - доска с наклейками, например, вот такая: LEANKIT

  • про ресурсы картинку держу в уме

    (спасибо за наводку salt_on_my_skin )


    Но иногда этот rip current перемен, откатов требований, просто накрывает и переворачивает.

    И тогда я обращаюсь к
  • Don't Sweat the Small Stuff at Work
  • ZENHABITS at work
  • Re-work - как раз авторства Jason Fried, TED-выступление которого мы как-то обсуждали по тегу work с точки зрения преимуществ и недостатков работы в офисе или дома

    Книга как таковая мне не понравилась: ни о чем. Но некоторые цитаты стоят того, чтобы их запомнить

    “Workaholics aren't heroes. They don't save the day, they just use it up. The real hero is home because she figured out a faster way”

    “There are four-letter words you should never use in business. They're not ....
    They're need, must, can't, easy, just, only and fast. These words gets in the way of healthy communication”

  • Статья на английском про то, что к подчиненным нужно относиться как ко взрослым людям, а не как к детям

    P.S. Вчера коллеги вытягивали из меня полчаса, чем это я еду заниматься в выходные к океану. Спрашивали классические вопросы:
    - Сколько-сколько часов?
    - И что, даже не переодеваясь?
    - И ты за это платишь? Сколько-сколько платишь????
    - А что тебе выдают в результате за эту сумму?
    - А как же есть и в туалет?

    =)))))))
    Если вы думаете, что 10-15-20 часов триатлоно-тренировок в неделю - это сложно, так я вам вот, что скажу: это - мой отдых для головы. Куда проще забраться на велик и пропилить 3 часа или 3 часа бегать, чем 3 часа работать головой в режиме ЯДЪ ASAP =)
  • tri_lj

    До лучших времен

    Пока не починят жж (а теперь объясните мне, почему именно на прочистку
    БД ПОСЛЕ DDoS столько времени надо???) Со вчерашнего дня, когда,
    аллилуйя, вроде как остановили DDoS, пользоваться жж все еще
    невозможно. У них там 1 человек что-ли этим всем занимается?

    Так вот, пока жж не починят, буду ждать, хотя очень хочется поделиться
    с френдами:
    - фотографиями из "евопейской" булочной Alon's
    - очередной записью о беге
    - и вообще всем, что в голову взбредет

    Будем ждать

    P.S. Пардон , аж 3 записи про Wishlist получилось =)
    коментить лучше к последней, предыдущие сотру, как только появится
    возможность апдейтить свой жж

    UPD: Всего каких-то 12 часов и очереди в БД разгребли =)
    me_pixels

    Рабочее: 7 кругов тестирования

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

    Всем непричастным к IT - извините, накипело, высказаться - некому, ибо руководству говорить - себе дороже, коллегам - ну зачем их еще нервировать.
    И не думайте, что у нас в компании всегда так: не всегда, все зависит от конкретных людей в проекте. Просто у нас - очередная версия ставится. А я как-то уже писала о том, что каждая версия - это мини-война , и каждый раз - со своей спецификой.

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

    Collapse )

    Collapse )

    Collapse )

    Collapse )

    Collapse )

    Collapse )

    Круг 7. Разбор полетов. Lessons Learned.

    А мораль сей басни такова:
    - Не надо доверять документу, в котором написано общими словами "Да будет свет" - и нет детализации того, что было пофиксено и как это соотносится с требовании Заказчика - с таким описанием не может функциональность приниматься к тестированию!
    80% ошибок происходит из-за кривой документации и соответствующего дизайна!
    Программисты, Авторы Документов - нарисуйте это себе на лбу!

    - Надо доверять, блин, тестировщикам, когда они говорят: "Хьюстон, у нас проблема!" Ибо скорее всего замеченная проблема - верхушка айсберга.

    - Не надо стирать код, написанный ранее коллегами только из гордости, мол, я лучше сделаю: не дураки писали, особенно - если код уже был протестирован. Велика вероятность того, что снесено будет не только то, что не работало, но и то, что работало - тоже.

    - Не надо ставить фиксы в последний момент, как бы соблазнительным не казалась мечта о светлом будущем и вера в то, что фикс фиксит вообще всё. Есть такая вещь: дата заморозки кода, и она тоже не дураками была придумана, а именно для того, чтобы избежать вот такого ге мучения. Все, кто не успел - тот опоздал. Все, что не было пофиксено - айда в следующий релиз.

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

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