у нас истории пишет продакт-оунер, но это, видимо, в зависимости от клиента-проекта по разному. разработчики просматривают на планнинге, если что-то выглядит сложнее чем нужно, разбивается на несколько. общий настрой на предельно атомарные истории, т.е. лучше переборщить с гранулярностью, чем принять историю с пропущенным требованием и после заводить баги или зависнуть в неопределенном состоянии.
один джира-тикет — одна история, она же юзер-стори.
единственное ограничение, может быть, что любая юзер-стори пишется в форме какую user value она предоставляет. т.е. «as an account manager i want to see the order id field on the form filled from the same place as in the Application», а не в технической форме — «добавить или починить real database adapter implementation», что ограничивает раж рефакторинга и заставляет фокусироваться на пользовательской ценности.
абсолютно, да.
я, персонально, еще впридачу отметил снятие с себя персонального груза рисков и ответственности за дальнейшую разработку. каждый может взять любую историю. каждый может ее завтра бросить. ничего не надо держать в голове, вышел — забыл — с утра снова прочитал. если забыл и не можешь найти где прочитать, то сам допишешь в спецификацию.
пивотал, кажется, были пионерами в этой области, но сейчас их систему буквально копируют (вплоть до покупки парных станций) крупные банки, поэтому наверняка русские аутсорсеры ее тоже через какое-то время опробуют.
нет, стендапы как были так и есть, хотя они становятся проще.
на удаленку нельзя, в этом весь пойнт парного программирования.
и платить за тикеты бессмысленно, программисты будут просто создавать больше тикетов.
оплата тут вообще ортогональна процессу — там есть отдельные recognition-метрики, которые у каждого коллаборанта могут быть свои, потому что, например, это могут быть разные компании-аутсорсеры.
Писать десять-двадцать простых историй — это как раз очень просто. Поле нужно добавить на форму — раз. Поле нужно валидировать — два. Поле нужно скрывать в зависимости от других полей — три. Введенную информацию нужно послать на сервер — четыре. Валидировать на сервере — пять. Трансформировать в поле(поля) для базы — шесть. Сохранить в базу — семь. Добавить стили — восемь. (Это написать и принять одну историю для поля, включающую все вышесказанное, трудно, а так — нет.)
Все остальное — про ankor и TPM и прочее — это вопрос сюда не относящийся. Agile-методология бывает разная и я вообще не ее фанат, например. У нас есть стендапы и ретро, а TPMa нету совсем, ну и что.
Мы не говорим, что TDD решает все проблемы, мы указываем, какие именно проблемы оно решает: качество кода, наличие спеков и collaboration.
Я имел в виду что не программистами. А кто именно представляет юзера — это внутри организации может быть какой угодно процесс
один джира-тикет — одна история, она же юзер-стори.
единственное ограничение, может быть, что любая юзер-стори пишется в форме какую user value она предоставляет. т.е. «as an account manager i want to see the order id field on the form filled from the same place as in the Application», а не в технической форме — «добавить или починить real database adapter implementation», что ограничивает раж рефакторинга и заставляет фокусироваться на пользовательской ценности.
я, персонально, еще впридачу отметил снятие с себя персонального груза рисков и ответственности за дальнейшую разработку. каждый может взять любую историю. каждый может ее завтра бросить. ничего не надо держать в голове, вышел — забыл — с утра снова прочитал. если забыл и не можешь найти где прочитать, то сам допишешь в спецификацию.
это другой мир, на самом деле.
на удаленку нельзя, в этом весь пойнт парного программирования.
и платить за тикеты бессмысленно, программисты будут просто создавать больше тикетов.
оплата тут вообще ортогональна процессу — там есть отдельные recognition-метрики, которые у каждого коллаборанта могут быть свои, потому что, например, это могут быть разные компании-аутсорсеры.
Все остальное — про ankor и TPM и прочее — это вопрос сюда не относящийся. Agile-методология бывает разная и я вообще не ее фанат, например. У нас есть стендапы и ретро, а TPMa нету совсем, ну и что.
Мы не говорим, что TDD решает все проблемы, мы указываем, какие именно проблемы оно решает: качество кода, наличие спеков и collaboration.